8

A server certificate would have its domain name at its subject field. A personal certificate would have your name as the subject field. How can you be sure that there are no two certificates with the same name?

Eg:- Assume you need to send some encrypted data to userA. How can you be sure that its userA and not some other person? Just by verifying the name on the certificate would not remove the risk of man in the middle attack I suppose.

Improve this question

3 Answers 3

Reset to default
9

The purpose of a certificate is to bind a public key with an entity and this is the responsibility of the PKI's Registration Authority to ensure that the entity identity in the certificate matches the key holder entity (e.g. for SSL certificate an entity can be a server, the identity is the domain name).

The procedures describing how this match is performed by the RA can be found in a public document published by PKI and named the Certificate Policy.

This is the responsability of the user of a certificate (for encryption of signature validation) to read the CP and decide how trustworthy the Certification Authority which issued this certificate is. Of course you do not put the same confidence in some PKI which declares that only the key holder's email is verified and a PKI which delivers the certificate on a smartcard, directly in the hands of the key holder, with an offical ID check. But sometimes verifying the email may be sufficient.

Actually the most important questions to ask are:

  • which data in the certificate have been checked by the RA?
  • did these data collected in a trustworthy way?
  • according to your needs (email signing, electronic signature of a contract...) can you trust the certificate?
Improve this answer
2
  • 1
    yeah digital certificates binds public key with a entity. With what can we bind a public key in a personal certificate ? There is no domain name for a user ?
    – user1157
    Jan 24, 2011 at 15:24
  • As Jcs says, it depends on your needs. In many cases the goal is actually just to trust that the person logging in to their account on your site this time is the same person who set it up (with a certificate) when they registered on your site. A certificate would help significantly (though still not fail-safe) with that, and provide two-factor authn to boot.
    – nealmcb
    Jan 25, 2011 at 3:44
2

How about using the user's email address as an identifier?

Improve this answer
1
  • 1
    Sure you could do that, but it's still a question of whether the CA trusts the user enough.
    – Steve
    Jan 24, 2011 at 20:31
2

If you need a unique identifier, use the certificate's serial number combined with the issuer DN. This is how OCSP does it, and it's guaranteed to be unique. As nealmcb says - the descriptive information in the certificate (Subject DN, Subject alt name, etc) is verified by the RA, and isn't required to be unique, unless your CA has a business practice of managing uniqueness. Some groups do - they may include employee id in the subject DN for example, and check it against a company database as part of the enrollment process. But to implement something like that, you have to be sure that you are sticking with a PKI system that provides this.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .