Hey, Yesterday Simon, Will, Cosicmo, Eitan and myself had a telepathy spec meeting about the Encryption and SSL verification spec as proposed by respectively Cosicmo and Eitan. Brief notes are below :)
The two interfaces discussed are available at: * http://people.collabora.co.uk/~cosimoc/encryption-spec/spec/org.freedesktop.Telepathy.Channel.Interface.Encryption.DRAFT.html * http://people.collabora.co.uk/~cosimoc/encryption-spec/spec/org.freedesktop.Telepathy.Verification.RemoteCertificate.html We had the following notes on the encryption spec: * Encryption spec needs to tell the client which information it should provide (what kind of certificates, which identity etc).. * Wjt mentions that this interface requires both the channel handler and the verification handler needs the certificates. Which seems unnecesarily complex and would require interaction between them (accessing the same certificate store etc). * Smcv suggest splitting the intention and the process. Which would mean that the encryption interface on the channel would just indicate the encryption state/level and the verification interface would handle fingerprints/passwords/certificates as needed. This means that if a clients wants to have an encrypted channel it's not required to reimplement a lot of the verification. * There is an open question about what kind of information should be available from the Encryption channel. A handler for a channel should be able to show the user how its channel is secured and why (used certificate X to verify identity Y etc). Given that with the split this is now part of the verification channel this isn't entirely obvious. Current concensus seems to be that we could have an EncryptionDetails property with contains this kind of information. * Open Question is what to do while still verifying/encrypting.. IOTW should the channel delay message delivery, not start an FT etc while the channel is still insecure. General consensus seems to be that we should be able to request a channel to be secure in which case it should indeed queue/fail/whatever anything before the channel is secured. If we're doing oppurtunistic encryption it's up to the CM to decide what to do, in general given that it's oppurtunistic it shouldn't be required to encryption everything as possible (there are no guarantees for the user in the oppurtunistic case, but they should still be able to know when encryption got turned on) On the SSL certificate validation * Question what to do when verifying a certificate at connect time and the handler disappears (crashes or whatever). A very rough proposal is to clarify things with the following ration. => If the SSL certificate channel gets closed unexpectedly (before either Accept or Reject is called) then the CM should treat it as a Reject if and only if the ContactCapabilities of clients show that there was in theory a handler for certificate verification. If there was no such handler in the ContactCapabilities then for backwards compatibility the CM should treat closing the channel as an Accept and fall back to its current behaviour wrt. certificates. This ensures that we're both backwards compatible and that we have a way of telling the CM that it should threat the verification channel as completely authoritive and thus closing the loophole where a certificate can cause itself to be accepted by causing the handler to crash. Sjoerd -- You can never tell which way the train went by looking at the tracks. _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
