On 12/30/05, David Schwartz <[EMAIL PROTECTED]> wrote: > > If you think disclosing public keys is an information leakage issue, > you > don't trust the encryption you are using. I'd be extremely suspect about the > depth of your understanding of what actually goes on in an authentication. > > DS
It's not an issue of the public key, nor the signature from the CA on the public key. In order to understand what the problem is, let's look at the role of a CA: A Certifying Authority certifies that a public key belongs to a person with the identity certified by its signature. (In the PGP 'web-of-trust' model, any individual can be a certifying authority, and it's up to the people who know that individual to determine what level of trust to put in that individual's certifications. In the X.509 'trusted root' model, only specially marked certificates can certify other keys' identities, and it is an error for a user to create a certificate for another identity.) Now, let's look at what the CA does: A Certifying Authority takes a CSR, validates it, and (if the validation passes) then issues a certificate. The certificate contains a lot of information -- all the information that it verified -- in the clear. The ONLY thing that is encrypted is the hash of the data thus certified, and that is encrypted by the CA's private key. Now. In a typical SSL/TLS exchange, at least one of the certificates is exchanged before the "change cipher suite" message. This means that anyone who is eavesdropping on the connection can obtain the clear-text information in the certificate. I do not want an eavesdropper to see the certificate exchange, and thus obtain the clear-text information. So, I want to create an unauthenticated-but-encrypted channel before exchanging the certificates. Now, I am aware that a "man-in-the-middle" attack exists, whereby a malicious third party (Mallory) could accept a connection and negotiate an unauthenticated-but-encrypted channel, and receive the certificate information that I don't want to be eavesdroppable. However, accepting a connection and negotiating a UbE channel require action on Mallory's part, and that means an active attempt to fraudulently obtain information that the protocol is attempting to protect. Where technology cannot enforce secrecy, policy (or 'law') can provide penalties for those who attempt to subvert the technology. (This is, among other things, what the DMCA is an attempt to do.) So, to recap: It's not the public key that I'm worried about being disclosed. It's the identity information that is bound to it via the certificate. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
