[Telepathy] API sketches for encrypted channels, and OTR
eitan.isaacson at collabora.co.uk
Mon Jan 4 14:51:59 PST 2010
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.
This is an anonymous channel when dealing with server verification. It
would have a contact handle (or list id?), when dealing with E2E
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.
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.
State: Verification_State(u): Indicates what stage of the verification
we are in.
StateChanged (u: State): The state of the channel has changed, a good
path for accepting a remote certificate or sending one.
(0) None: Awaiting remote certificate or response.
(1) AcceptCertificate: Waiting for client to accept remote certificate.
(2) CertificateRequested: Waiting for client to send client
(3) Verified: Verification is complete.
(4) Failed: Failed to verify.
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
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.
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.
How does all that look?
All the best,
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
> * 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
> * 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 :-) ).
> telepathy mailing list
> telepathy at lists.freedesktop.org
More information about the telepathy