[Telepathy] API sketches for encrypted channels, and OTR

[Eitan Isaacson]

Hello!

I have been thinking about how we could best expose SSL verification
over Telepathy to allow client interactivity. Cosimo's proposal is a
good preliminary sketch of what it would look like, I hope to expand on
it below, and ultimately land something in the spec.

I see client interaction in two main cases:
1. Accepting/rejecting a given certificate from a server or E2E session.
2. Providing a certificate for an E2E session.

I think it would be nice if the API was simple, and would not require
clients to deal with server verification if they didn't wish to (ie.
verification would stay non-interactive on the CM). Since we are only
really dealing with certificate exchanges, I think it is best to hide
all other handshake details and such in the CM, and only notify the
client when we are ready to accept or send a certificate.

org.freedesktop.Telepathy.Channel.Type.Verification
===================================================
This is an anonymous channel when dealing with server verification. It
would have a contact handle (or list id?), when dealing with E2E
sessions.

If the channel is closed at any pre-verified state, the behavior returns
to the legacy non-interactive CM verification. When a ChannelDispatcher
is arbitrating, and no known handlers exist, it will close this channel,
and thus current clients would function properly.

Methods
-------
GetCertificate (): This would return a
org.freedesktop.Telepathy.SSLCertVerification object if it is available.
Will return a null object path if not.

SendCertificate (s: Cert): This method takes a PEM encoded certificate
for E2E verification. Are there cases where a server would require a
client certificate? This would be useful for that too.

Properties
----------
State: Verification_State(u): Indicates what stage of the verification
we are in.

Signals
-------
StateChanged (u: State): The state of the channel has changed, a good
path for accepting a remote certificate or sending one.

Types
-----
Verification_State: 
	(0) None: Awaiting remote certificate or response.
	(1) AcceptCertificate: Waiting for client to accept remote certificate.
	(2) CertificateRequested: Waiting for client to send client
certificate.
	(3) Verified: Verification is complete.
	(4) Failed: Failed to verify.

org.freedesktop.Telepathy.SSLCertVerification
=============================================
This type contains certificate information as well as methods for
accepting/rejecting the given certificate. Typically a client could use
these objects for creating and storing certificate exceptions, for
example, accepting a self-signed certificate and storing it for future
sessions.

Methods
-------
Accept (): Self explanatory, accept the certificate.
Reject (): Reject the certificate. If this is a server certificate We
will subsequently get a StatusChanged signal from the Connection with
the a status of Disconnected, and a proper Cert_* reason.

Properties
----------
Status: u(Certificate_Status): This property is pre-populated with a
status that the CM provides. The CM is responsible for a preliminary
verification using such standard CAs such
as /etc/ssl/certs/ca-certificates.crt and
$XDG_CONFIG_HOME/telepathy/certs. This property is writable and can be
changed to any status the client deems. If a certificate is rejected,
this property is used as the reason.

Certificate: s: This is the full PEM encoded certificate.

Types
-----
Certificate_Status:
	(0) None
	(1) Untrusted
	(2) Expired
	(3) Not_Activated
	(4) Hostname_Mismatch
	(5) Self_Signed
	(6) Revoked
	(7) Insecure_Algorithm
	(8) Other


How does all that look?

All the best,
  Eitan.


On Tue, 2009-12-29 at 15:01 +0100, Cosimo Cecchi wrote: 
> Verification interface:
> 
>       * channels of this kind pop up once an encryption request is
>         fired.
>       * ideally we want a single verification path, which serves both
>         for validating login server certs and E2E XTLS certs; this
>         doesn't play too nicely with the XTLS spec. During your server
>         login phase you get the whole SSL certificate from the server,
>         while in XTLS there are additional handshake steps: the
>         initiator sends his cert fingerprint over jingle (in-band), the
>         responder either does the same or she picks an interactive
>         verification protocol, like SRP (or just decide to trust the
>         fingerprint). Only after the handshake, the actual SSL certs are
>         exchanged over the E2E link, ready to be verified.
>       * we thought of splitting the SSL verification into an own
>         transient object, e.g. SSLCertVerification, which would contain
>         the cert in a property. The object would have Accept() and
>         Reject() methods and the policy to call them would be up to the
>         clients.
>       * the other part of interactive verification is done in the
>         Verification channel, which takes care of setting up and
>         handshaking the connection up to the point we have a
>         certificate. For example, in case we're doing E2E security, the
>         SSLCertVerification object would pop up only after we told the
>         Verification channel our fingerprint and that we're going to
>         accept an SSL cert matching the fingerprint provided the other
>         side of the communication.
> 
> This is basically all. Feel free to contact me if something is not clear
> enough (but I'm happy things are getting clearer for me since my
> previous mail :-) ).
> 
> Cheers,
> 
> Cosimo
> 
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy