[Telepathy] telepathy-spec vs. XTLS: round 2

[Cosimo Cecchi]

On Fri, 2010-05-28 at 16:44 +0200, Cosimo Cecchi wrote:
        
> *** Notes ***
> 
> This proposal still lacks TLS certificate validation, which is also a
> required step for XTLS.
> I will send another proposal for it, and for the integration with these
> interfaces next week, but the basic idea would be:
> 
>         - add another state to XTLSAuthentication, which would happen
>         after the negotiation steps are successfully completed, and
>         would indicate that we're waiting on the verification of a TLS
>         certificate.
>         - add another property/signal to XTLSAuthentication, which would
>         act like the AuthenticationProposals/NewProposals couple, which
>         contain a path to the certificate exchange channel.
>         - add another channel type for TLS certificate exchange.
>         - add another transient object under 'Authentication',
>         representing the bulk TLS Certificate.

I went ahead and implemented this idea on top of the XTLSAuthentication
interface I already wrote about.
The telepathy-spec git branch can be found here [1]; there's also an
HTML version available here [2].

I added two objects on top of my last proposal, one that takes care of
exchanging TLS certificates between two clients, and another that is the
bulk TLS certificate + some properties and methods.

org.freedesktop.Telepathy.Channel.Type.TLSCertificateExchange
-------------------------------------------------------------

The idea of this channel is to allow two clients to exchange their TLS
certificates, and offer a path for their verification. This can happen
both when we use end-to-end security and when we connect to the server
at startup, though in the latter case the certificate exchange is not
bi-directional.
The channel works basically as a state machine, where the first state we
have could be 'Not_Started' (when doing E2E) or
'Remote_Certificate_Received' already (when connecting to a server). In
both cases, clients are required to take a look at the TLS certificate
transient object that is created for them, and to approve or reject it.

Methods
        Send_Certificate_Chain (s: Certificate) → o: Certificate_Object.
        
Signals
        CertificateRecieved (o: Remote_Certificate)
        StateChanged (u: State, u: Reason)

Properties
        RemoteCertificate — o (Read only)
        LocalCertificate — o (Read only)
        RequestedIdentity — s (Read only)
        State — u (Certificate_Exchange_State) (Read only)
                    * Not_Started (0)
                    * Local_Certificate_Sent (1)
                    * Remote_Certificate_Received (2)
                    * Remote_Certificate_Accepted (3)
                    * Success (4)
                    * Failed (5)
                
org.freedesktop.Authentication.TLSCertificate
---------------------------------------------

This object, which lives together with the XTLS 'Proposal' object in the
'Authentication' namespace, contains a bulk TLS certificate, with some
quite straight-forward properties and some methods to accept/reject it.

Methods
        Accept () → nothing
        Reject (u: Reason) → nothing
        
Signals
        StateChanged (u: State, u: Reason)
        
Properties
        Remote — b (Read only)
        State — u (TLS_Certificate_State) (Read only)
        RejectReason — u (TLS_Certificate_Reject_Reason) (Read only)
        Fingerprint — s (Read only)
        CertificateType — s (Read only)
        
------------------------------------

** Notes **

I also added some integration bits in the XTLSAuthentication channel I
proposed in my last mail to allow integration with these new interfaces.

At this point, questions, feedback and comments are really
appreciated :)

[1]
http://git.collabora.co.uk/?p=user/cosimoc/telepathy-spec.git;a=shortlog;h=refs/heads/xtls-proposal
[2] http://people.collabora.co.uk/~cosimoc/xtls-proposal-spec/

Cheers,

Cosimo