On Wed, Mar 07, 2007 at 04:24:34AM +0100, Vladislav Marinov wrote:
> As my security experience is not very broad I think that as you properly
> pointed I was confused by the security model. From your words I see
> that only client X can present a certificate that belongs to client X.
Client certificates are only accepted by servers as part of a transaction
that is signed by the client's private key. The certificate itself is public
information, the private key is the real credential, but it is not sent
over the wire, it is used to sign appropriate messages that estabish the
client's possession of the private key without disclosing it. The certificate
ties an identity to the corresponding public key.
> Why? X.509 certificate simply ties an identity (DNS name for ex.) to a
> public key. What will happen if client Z presents the certificate that
> belongs to client X to the server Y.
It can't without also having X's private key.
> 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?
Thisi is built-in to the TLS protocol. Client's are assured that the
server's public key is associated with a private key that only the server
should know, and conversely when client credentials are presented, the
server is sure that the client's public key is that client's alone. Tying
the public key to an identity is where PKI certificates muddy the water,
the semantics of X.509 certs are not relevant here, if you are prepared
to accept certs, you will not find a cert presented by the "wrong" client
(wrong == not in posession of the private key).
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
