Certificate authorities for a PKI

As discussed on the original version on stackoverflow:

It all comes down to who you trust. Some organisations will trust government, while some definitely won't. Some will trust a bank in this role, but would a competitor trust them? I have seen many banks set up their own PKIs or use a PKI vendor - and the physical security requirements around root CA generation and storage are very James Bond!

For your specific situation, look at your needs, trust requirements and risk. What PKI provider is most likely to match your needs? How is their disaster recovery and business coninuity plan structured - does this match your requirements? How do they prevent compromise of the root CA?

The root certification authority is from where trust comes. What trust ? The whole point of the PKI is to bind public keys to identities. The important point here is the kind of identity we are talking about, and also who will do the trusting part.

So a root CA should be operated by en entity which:

• the verifier can trust
• has adequate procedures for verifying identities before issuing certificates

Scenario 1: imagine that you want to submit your annual tax declaration through the Internet, and that the fiscal administration of your country wishes to authenticate tax payers through certificates (that's how it works in France). The notion of identity is here what vital records are about: name, date of birth, and so on. Both vital record maintenance and tax recovery are State prerogatives. So, in that setup, it makes a lot of sense that the State manages the root CA: the State already has procedures for keeping track of physical identities, and is also the certificate consumer in that scenario: the State (tax recovery service) is the entity which will verify certificates. Offloading the CA to an external private entity looks like a needless complication here.

Scenario 2: you are a big company which wants to issue certificates to their employees, so that they may encrypt and sign their emails. The identity is not the legal name, but the function of the key holder: you do not send an encrypted email to Bob (the VP of sales), you send an encrypted email to the VP of sales (currently Bob). If (when) Bob becomes "unavailable" (he gets fired), past emails should be readable by Dave (the new VP of sales). The notion of identity used in that scenario is then fully under the control of the company (the company defines its own hierarchical structure) and the link with physical key holders is also defined by the company. There is no reason whatsoever to implicate any government here; the natural root CA in that scenario is one operated by the company itself.

Scenario 3: a variation on scenario 2. Now there are several big companies, each with its own CA. They want to be able to do encrypted emails with each other. There are several ways to achieve this; one of them is bridging (each CA issues intermediate certificates for the root CA of other companies), which keeps the whole thing under the same model than in scenario 2. Or you could imagine an external root, which will issue intermediate CA certificates for the company CA. That external root is then trusted by everybody; it could be government-operated (as a public service) or privately-managed (a provider of "trust services", bound by contracts with each of the participating companies): this makes no scientific difference (you will prefer one over the other depending on whether you vote Democrat or Republican).

Scenario 4: the Internet, HTTPS Web sites, a Web browser with a set of default root CAs embedded in it. This is where things become tricky. Technically, the Web user is using the CA as basis for his trust. But the root CAs were included in the browser (or operating system) based on a contract between the browser vendor and the CA operator; neither of them has the defense of the customer interests as primary goals, and the contract details, embodied by the "certification policy statement" published by the CA, usually looks like: "whatever happens, it is not our fault" (but expressed over 200 pages of lawyer-compatible jargon). It is not very clear who should issue certificates for HTTPS Web sites. The identity of a Web site owner is often a company name, which is defined by whichever State the company was registered with. There are 193 UN-member States and a dozen or so of other State-like entities, not counting federal States who will want to be seen as several entities. That's quite a lot of potential CAs there. This is unsatisfying. But we want to identify companies because we want police forces to be able to track and punish usurpers -- and law enforcement is also a State prerogative.

So right now, we are doing HTTPS with whatever root CAs Microsoft found fit to include, and we all pray that attacks through fake certificates will remain a rare nuisance.

So, to sum up, the question of who should be a root CA really depends on the notion of identity you want to use. Usually, whoever defines that identity is in a good position to be the root CA, because it is already, by definition, trusted.

I think the answer here is subjective. Who you should trust depends on your purpose as well as your belief in what entity will manage the data and the process in an appropriate manner.

Just like I wouldn't trust that the guy in the dark alley is selling me a Rolex watch, I wouldn't trust "Ma and Pa's House of Certificates" unless I'd actually visited Ma and Pa's shop and figured out that Ma and Pa had Fort Knox in their basement and had a strong grasp of the procedures necessary to verify identity, ensure CA data integrity and deliver timely information about certificate status.

Also - I think it depends on your mission - I'm more than willing to get a certificate issued by a government for the purpose of identification within that government's jurisdiction - just like we tend to use driver's licenses in the US as both proof of ID and of age. But I'd be less happy about using my government issued identity if I was representing a multi-national corporation and needed to present credentials in foreign countries - in those circumstances, I'd expect to be issued a work-certificate, the same way I'm issued a corporate ID badge today.