On Thu, 2010-01-21 at 11:40 +0000, Simon McVittie wrote: > On Wed, 20 Jan 2010 at 11:39:44 -0800, Eitan Isaacson wrote: > > On Wed, 2010-01-20 at 17:59 +0000, Will Thompson wrote: > > > Sjoerd and Simon think we want different channel types for verifying > > > servers' certs and for verifying contacts', with a common interface, > > > rather like how (modern) tubes are > [...] > > I think I like this idea, but just to see I understand: > > > > Channel.Type.CertificateVerification will have one property, "Resource". > > The only paths that utilize this channel type are Connections. > > No, something like: > > Channel.Type.ServerVerification > readable property Server: s > TargetHandleType = NONE > requires interface Channel.Interface.CertificateVerification > > Channel.Type.ContactVerification > TargetHandleType = CONTACT > requires interface Channel.Interface.CertificateVerification
Much clearer, thanks. > Is Simon the local Telepathy user or the remote XMPP user in this diagram? > > It seems you're using the same channel to authenticate Simon's identity to > Joe, and to authenticate Joe's identity to Simon. If that's the case, then > it's important that the spec text (and examples) make it completely clear > who's being asked to trust what. > So the gap here is just documentation? I could improve on that. > > > So we actually just want the channel to have an > > > array of PEM fingerprints, an Accept() method, and Reject( reason goes > > > here? ) method, and not have separate objects for each certificate. > > > > I had no idea this scenario could exist. You could identify with > > multiple certificates simultaneously? > > No reason you couldn't... > I couldn't find this in any spec[1][2][3], that is why I asked. > > Anyway, if this is really the case, I think a good way to deal with it > > is in a linear fashion, while keeping SSLCertVerification singular. For > > example: > > 1. Receive CACert signed cert from peer, channel state is > > AcceptCertificate. > > 2. Reject certificate with 'untrusted' reason. > > 3. StateChanged is fired. > > 4. Receive Collabora CA signed cert. > > 5. Reject/Accept > > 6. goto 3 > > Do we really want to force prompting the user n times as a matter of API? > > It seems to me that the actual question being asked is "I have these two forms > of identity, are they sufficient for you to believe that I'm me?". If this > is the case, then you might as well present all available certificates > in parallel. > > (There is another possible trust level: perhaps Mikhail doesn't trust either > CAcert or Collabora individually, but is willing to believe that if both > CAcert and Collabora say I'm me, then they're right :-) > > > But apropo certificate lists, I chose to send a single PEM encoded > > certificate, while it seems that many TLS APIs provide a list of > > certificates that represents the signature chain. I chose not to include > > those for the reasons below. > > What are those reasons? > > If the CM has the signature chain, it might as well tell the client; at worst, > the client ignores it. > > In particular, if the certification model is more complex than the CA model > of "blindly trust a set of designated CAs to sign anything, don't trust anyone > else at all" (think XMPP end-to-end encryption here, rather than > authenticating servers), you might well need the whole certificate chain. > Yeah, I'll add that. > > About cert properties: We should probably add fingerprint as a property, > > as for other properties, it may get tricky since we are not relying on a > > specific type of certificate, so it may be an openpgp x509, or whatever > > which have different fields(?). Although there might be a few common > > ones, didn't actually look at this. > > Why can't the UI just receive all the "source information" the CM has, and > make its decision based on that? (For instance, if the UI wants to show the > user a fingerprint, it can compute it from the cert.) > That is currently what's expected. The client receives a raw PEM it could parse any way it wishes. > > > We want to avoid clients relying on the CMs doing preliminary > > > verification on certs, so maybe Certificate_Status should go away. > > > (Sjœrd may already have said this in an email.) A CM should present > > > certs without comment, and the client should say yes, no or meh; only in > > > the meh (legacy) case should the CM make its own judgements. > > > > This makes the most straightforward use-case a bit more complex - > > present the user with a dialog when verification fails, and let them > > decide to ignore the failure. > > I'm not convinced that "Here is a popup you do not understand because it's > full of scary words like SSL, certificate and fingerprint. Do you want to keep > talking to someone who looks superficially like your friend Joe?" is good > UI to be treating as a baseline in any case - everyone will just click "yes" > and carry on with their unencrypted lives :-) It is a wonderful way of life :) I misunderstood the basic aim of this API. I thought we were mostly making it easy for clients to deal with verification exceptions, not move verification entirely to the client. With that in mind, a lot of your points make more sense. > > > In the current draft, the client just needs to read the > > CertificateStatus property, and present a human readable notification to > > the user with accept/reject buttons. > > How do you produce a human-readable notification without understanding the > certificate? > > This certificate is issued to a name that differs from the name we > want. I'm not actually going to tell you either of those names or > let you look at the contents of the certificate, so even if you're > a cryptographic ninja, you can't make an informed decision. Do you want > to continue? > > [ Connect anyway ] [ Cancel ] > > :-) If Empathy and friends will ever join the family of networked applications, they need vague, arse-covering, security dialogs :) > > > If the property goes away, the client will be forced to utilize a TLS > > library to do it's own verification magic. > > I don't think requiring a UI for TLS certificate verification to use a TLS > library is necessarily very onerous :-) > The reason I was hesitant is mostly because it dictates a substantial amount of duplicated effort where the CM and UI both implement similar verification. There seems to be effort put in on a few levels to abstract TLS libraries, Wocky has both an openssl and a gnutls path, and gio will be library agnostic as well. If the UI will use a TLS library directly, it seems like it would defeat the purpose. It will need to abstract the TLS functions as well, which is another headache. Not saying they shouldn't, but I didn't think they should be required in order to use this API. In any case, I understand now that this API will ultimately transition verification to the UI, so there really is no way of avoiding having the UI do TLS ops. > > Also, how certain is the client of the remote server's hostname? It > > seems like there is no definitive way of knowing, there is only a > > well-known RequestConnection 'server' parameter, maybe I missed it? In > > the XMPP case, a CM might do some additional DNS voodoo, like SRV and > > reverse lookup, a protocol-agnostic client won't be able to reliably do > > this. > > Yes, the CM needs to tell the UI what server name the UI should be verifying > (e.g. via the Server property on the channel). > > In some protocols we might need to give the UI a list of hostnames any of > which would be acceptable, I suppose? That is a good idea! Back to work, Eitan. 1. http://tools.ietf.org/html/rfc5246 2. http://tools.ietf.org/html/rfc5081 3. http://xmpp.org/internet-drafts/draft-meyer-xmpp-e2e-encryption-02.html
signature.asc
Description: This is a digitally signed message part
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
