Other (with the subject associated) views on the usability of TLS: http://www.openoces.org/pipermail/developer/2004-December/000582.html
I think they may be on to something here. ================================================== We seem to need another browser-based PKI client-auth mechanism. =================================================== The Danish scheme has in fact become (in an endless set of variants) more or less a standard in Scandinavia. Used by millions of users. Anders ----- Original Message ----- From: "Kyle Hamilton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <dev-tech-crypto@lists.mozilla.org> Cc: "Rolf Oppliger" <[EMAIL PROTECTED]> Sent: Monday, March 20, 2006 10:09 Subject: Re: Accessing the handshake messages hashes of the TLS "Finished"message from a plugin (I'm going to send this reply back to the dev-tech-crypto list, as it is a situation which is sorely misunderstood by many people. Please pardon my alarm, but the fact that a member of the ACM misunderstood the situation suggests to me that it's a wider problem in understanding than most people within the field realize.) On 3/19/06, Ralf Hauser <[EMAIL PROTECTED]> wrote: > Hi Kyle, > > Thanks for your detailed comment. > Ok, if within a transactional context such as an "online banking session", > new session keys are renegotiated from scratch, how does this work in with > client certificate authentication? Under the assumption I do not permanently > unlock my client private key, how can I be avoided being prompted to unlock > my private key upon each CerificateVerify message > (http://rfc.net/rfc2246.html#s7.4.8.)? In order to describe the current situation (and believe me, I do have reservations about how it currently works), I'm going to have to define several different uses of the word 'session'. 1) SSL Session: This is the actual context of the underlying SSL/TLS connection, the one that your proposal is attempting to use as the 'proof'. 2) Transactional Session: This is the logical interaction between the client (usually but not always browser) and a specific server, which may span several SSL sessions. (This transactional session usually follows a finite state diagram, with a definite starting point, any number of intermediate and possibly back-referencing steps, and a definite ending point.) 3) User Session: This is the interaction between the (usually but not always) human user and the client software, for whom the transactional session is generated and who navigates the state diagram. As it currently stands, the private key is (generally) unlocked for the lifetime of the requesting process. (This is the case for MS Internet Explorer, for example -- once it has a handle to the underlying CryptoAPI context object, that handle [to my knowledge, which may be incomplete or incorrect] never expires.) I do not know how Mozilla/Firefox currently treat their private key store -- however, I believe that this viewpoint is much more security-friendly than the MS CryptoAPI viewpoint, in any case. (If only because context information can be passed to the store for management purposes.) The ideal, in my view, would be this: All public-key cryptography is done by and within the security boundary of the cryptographic module, which is unlocked only for a specific context (in this case, a specific website identified by a specific key), and only for a specific period of time. Any SSL session renegotiations (and associated CertificateVerify messages) should, within a given user session, for that site only, and only for the amount of time allowed by the unlock token, be silent to the user. (A means of enforcing this would be to include the server's public key along with any request to use that token, thus enforcing that the authorized server's public key is used to encrypt the response of the client's private key, along with the ability to assert that a given token is only used with a specific server's public key.) For any other site, or after the unlock token expires, the user is prompted to unlock the token once again. I am going to have to reread the SSL and TLS specifications to ensure that this would be workable (I seem to recall that the CertificateVerify messages are always encrypted with the peer's asserted public key); however, if it does mesh with reality, it would make a lot more sense than "unlocked for the lifetime of the process", which is where MSIE currently stands. (Again, I don't know about Mozilla NSS-based software, as I have never had occasion to test its behavior.) > Ralf Cheers, -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
