Hello,
I am currently programming a Certification Authority for a uni class, I am currently struggling with the concept of creating the certificates.
How does a CA usually decide if it should give a Certificate to an entity , is it enough to prove that the entity is the owner of a public key by signing a certificate-request with their private key?
If not how does a CA usually decide if the entity is trustworthy?
thanks,
Determination of an entity's identification is pretty subjective to the type of entity being certified. In my experience, when requesting a certificate for a domain name, e.g. www.stackoverflow.com, the CA will typically contact the technical contact mentioned in whois.
Alternatively, the CA may provide a PKCS #9 passphrase to a trusted entity to provide in the CSR. The CA can then inspect the passphrase against a list, and decide if the requested entity is legal for that entity.
There are different levels of trust associated with different types of certificate.
Basic SSL Certificates:
A basic SSL certificate for a website, for example, is often an automated process - which validates by sending a unique time-expired URL (or code that must be entered in an online form) an email addresses associated with the domains WHOIS record.
For Extended Validation:
For stronger verification (such as in the case of SSL 'Extended Validation', where you see a green address bar in modern browsers), it is common practice to establish the legitimacy of the owner by correlating multiple sources of information, such as a requesting a utility bill/certificate of incorporation/registered corporation details (e.g. Dun and Bradstreet/Companies House Registration (UK) or equivalent) and a domains whois information to make sure they all exactly match up with the same addresses and company name.
In the case of certificates for an individual a photocopy of drivers licence with a photograph or passport is often required.
It is common practice to also call back via an identified phone to confirm the order is legitimate. The legitimacy of the phone number is typically based on one in WHOIS information, or the number listed on a phone bill provided by a utility company.
The process for Extended Validation certificates is typically very similar if not identical to the process for Code Signing certificates (where the domain used as the email contact for the record is often taken as a domain you must be in control of the WHOIS information for).
It varies slightly from Registrar to Registrar and it can be a bit informal and ad-hoc sometimes (because some things that are easy for a small company to provide are difficult to get hold of in a large corporation, and vice versa so their tend to be multiple alternative methods accepted).
A CA is a business. It makes money by selling certifications. The more certs it sells the more money it will make. If a CA is not validating the entities judiciously, it will loose it's reputation and no one will be willing to pay to be certified by it.
Generally the CAs are operating within the tension of these two opposing forces
IMHO, the most important things in practice are that the subscribers of a CA (i.e. those that are verifying certificates) understand what the CA is doing so they can put appropriate trust in the certificates, and that the certificate never re-issues the same identity to two different entities.
Vetting the user's identity is important if the name in certificate is objective. For example, web server certificate that should contain a specific domain/host name (e.g. www.example.com), one should be sure the owner of the certificate owns the domain name.
I'm worried that your question suggests a serious misunderstanding.
is it enough to prove that the entity is the owner of a public key by signing a certificate-request with their private key?
It is certainly not sufficient to have the entity sign something with a private key. How would the CA know which public key to use to verify the signature? It has to trust the entity to provide it. So anyone can contact a CA and say:
"I'm microsoft.com, and here, I've signed this with my private key. You can even check it with my public key. Now, could you certify that this public key belongs to microsoft.com, please? I'll pay you $1000!"
(In fact, this step is necessary, just not sufficient. If I didn't sign something with the private key, then I could send any public key - even Microsoft's - to the CA and ask them to certify it as mine. Then I can claim that something signed by Microsoft (maybe a patent application) was actually signed by me! So the CA will certainly check that I have the corresponding private key before it certifies the public key in the certificate.)
So the question is, what can a CA do to verify the identity of the person requesting the certificate? Nobody at the CA has ever heard of this entity before!
A simple option, that can be entirely automated at the CA end, is for the entity to provide an email address. The CA will send a challenge (such as a special URL on the CA web site with a long random number in it) to that email address. If anyone makes a request to the server with that URL, then it is presumably the person who owns or has access to that email address.
You can try this yourself, if you go to Verisign and request a free trial SSL certificate.
The limitation is that the only relationship that this certificate can attest is between a public key and an email address. That might be enough for some people, but it's not enough for everyone.
If I want to be confident that a particular certificate (or the public key in it) belongs to say, XYZ Inc of Elbonia, because I'm about to send some sensitive business details to them, I want more than just an email address. I want to be sure that the CA has done some serious probing. The CA should receive the request on letterhead. They should contact the company using a phone number from the telephone directory. (An imposter will have to fool the telephone people as well.) The CA should check with the business name registration office to check that XYZ Inc is registered at this address. They should post a document (with a long random number in it) to the registered address. (That means that an impostor would have to intercept the mail as well.) The CA may physically attend the registered office of the business of the organisation to confirm that the request has been made.
All of these identity checks are time consuming and expensive. A CA will charge the entity for such a service. But, if the entity wants to provide its clients with a high level of confidence that this public key really belongs to XYZ Inc, then that's what has to be done.
As Iain Collins suggested, CAs can provide cheap services for those who only need a small degree of identity verification, and expensive services for others. The certificate that the CA offers will contain an indication of the level of identity verification that has taken place. A person considering a transaction using the certificate can look at the CA's Certification Practice Statement to understand what this level means, and the types of identity checks that have been carried out.
Finally, the CA is not making any assertions about the entity's trustworthiness. Remember that a certificate is a link between a public key and an identity. The checks that a CA does simply ensure that the public key really is related to that particular entity, not someone impersonating that entity. The entity could be quite evil!
In summary, you can't use public key cryptography to determine someone's identity until after the certificate has been issued. The certificate says that the CA has used some other form of identity check, and allows other people to rely on that check.