> As my security experience is not very broad I think that as you properly > pointed I was confused by the security model.
If this is a real-world application, you really need to stop *immediately* and get someone with much more security experience to review what you're doing. If we fix all the problems that happen to come up in this discussion, it's extremely unlikely that this will be all the security problems. > From your words I see > that only client X can present a certificate that belongs to client X. > Why? X.509 certificate simply ties an identity (DNS name for ex.) to a > public key. Exactly. It ties the identity to a *key*. It says, "whosoever has this key, I claim has this identity". > What will happen if client Z presents the certificate that > belongs to client X to the server Y. That certificate will carry the > public key and the identity of X. How will the server Y understand that > it is not X but Y that he is speaking to and therefore it should not > provide data to Y? Because client Z won't have the private key corresponding to that public key. So the server will know, by the certificate, that client Z is *NOT* client X. (Since the certificate associated the public key with client X, and client Z doesn't have the corresponding private key, it must *NOT* be client X.) > Basically is it enough to only check that a certificate is valid, i.e if > the identity of X is sitting in the Common Name field of an X.509 > certificate does this guarantee that it is exactly X sitting on the > other side of the connection? Yes. That's exactly the purpose of the certificate. It associated a public key with an identity, so that all who see that certificate know that the owner of that identity has the corresponding private key. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
