[Bug 14003] Chan.T.ServerAuthentication, Chan.I. SASLAuthentication — authenticate with server interactively

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=14003

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://git.collabora.co.uk/
                   |                            |?p=user/smcv/telepathy-spec
                   |                            |-smcv.git;a=shortlog;h=refs
                   |                            |/heads/sasl
           Keywords|                            |patch

--- Comment #31 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-11-15 10:17:30 PST ---
Fixes prompted by re-reading this branch:

ExtraContext should be SASLContext.

Accept, Abort and StatusChanged should be AcceptSASL, AbortSASL and
SASLStatusChanged, unless we turn the interface into an independent object.

I think Respond and the properties (other than Secure and ExtraContext) are
jargon'y enough to keep as-is without conflicts, and NewChallenge is probably
OK too?

Secure should be split into Encrypted (strong encryption is active) and
Verified (man-in-the-middle protection is active, e.g. a certificate has been
accepted either by the user or the system cert store).

Chan.T.ServerAuthentication.AuthenticationInformation should just go away, I
think; I'm reasonably sure it makes more sense in Chan.I.SASLAuthentication.

Chan.T.ServerAuthentication.AuthenticationMethod should be a D-Bus interface
name rather than an enum member?

--------------------------------

Not fixed yet:

Collision-avoidance would mean renaming Encrypted and Verified to
SASLTransportEncrypted and SASLTransportVerified or something, but they're not
really part of this interface at all... in a way, I think we really want the
Encryptable interface from Bug #29904, but with a split between Encrypted and
Verified (which it currently conflates).

I'm not sure that Verified is useful without Encrypted for SASL, but it's a
possibility in XTLS-like mechanisms. Verified and !Encrypted is analogous to a
PGP-signed email conversation - I know I'm talking to Fred, but other people
might be reading our email too.

Perhaps this?

Chan.I.Securable

    property Encrypted: b, immutable=sometimes
        If true, eavesdropping is prevented, but you might
        not be talking to who you think you are.

        Immutable on ServerAuthentication channels.

    property Verified: b, immutable=sometimes
        If true, tampering is prevented and you are
        talking to who you think you are.

        Immutable on ServerAuthentication channels.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.