Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
add comment

3 Answers

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.

share|improve this answer
add comment

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?
share|improve this answer
    
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 '11 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 '11 at 3:44
add comment

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

share|improve this answer
1  
Sure you could do that, but it's still a question of whether the CA trusts the user enough. –  SteveS Jan 24 '11 at 20:31
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.