On Jan 30, 2008 9:04 PM, Philipp Gühring <[EMAIL PROTECTED]> wrote: > Hi, > > > Huh? What are you claiming the problem with sending client certificates > > in plaintext is > > * It´s a privacy problem > * It´s a security problem for people with a security policy that requires > the > their identities to be kept secret, and only to be used to authenticate to > the particular server they need > * It´s an availability problem for people that need high-security > authentication mechanisms, combined with high-privacy demands > * It´s a identity theft problem in case the certificate contains personal > data > that can be used for identity theft
I totally disagree that this is a material problem that is in any meaningful way impeding the use of SSL client certificates (there are totally different reasons that client certs aren't being widely adopted, but that's beside the point). However, TLS supports what you want right now: just do the initial handshake without client auth, then renegotiate after the session encryption starts. The renegotiation will happen under the encrypted, identity-protected and server-authenticated session, and client authentication can be requested in the renegotiation; the client cert will then be confidential. The reason nobody actually bothers to do this is because there's no customer demand (see paragraph 1). - Tim --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]