Return to Answer

Closed organisations like enterprises and government bodies are a special class of cases - whenever you enter the organization, you get your PC, your accounts, and alongside you get your key pair and the public key of the organization root CA (more precisely, this is typically stored in the Windows Active Directory, where the AD architecture with its protocols like Kerberos provide the secure channel).

CA trustworthyness

Device trustworthyness

To be honest, nobody knows. Bruce Schneier and others have written a lot about that. But as far as I know (I am not closely watching, though) the whole construction was never thoroughly contested in the courts. Until then it hold what I said earlier: The existing architecture somehow works, despite the many leaps of faith you have to make, and alternatives that are widely accepted are not in sight.

Closed organizations like enterprises and government bodies are a special class of cases - whenever you enter the organization, you get your PC, your accounts, and alongside you get your key pair and the public key of the organization root CA (more precisely, this is typically stored in the Windows Active Directory, where the AD architecture with its protocols like Kerberos provide the secure channel).

CA trustworthiness

The humorous application of "Honest Ahmad" for a root certificate sheds some light on the weaknesses of the whole construction.

Device trustworthiness

To be honest, nobody knows. Bruce Schneier and others have written a lot about that. But as far as I know (I am not closely watching, though) the whole construction was never thoroughly contested in the courts. Until then it holds what I said earlier: The existing architecture somehow works, despite the many leaps of faith you have to make, and alternatives that are widely accepted are not in sight.

Now, in principle, a public-key certificate works like any other kind of certificate, including the ones in the real world.

1. If some authority A asserts some property p(X) for some X
2. If A publishes the assertion in a kind-of unforgeable way
3. If some entity Y trusts A

then Y has virtually no choice but to believe that p(X) is true.

For public-keys in a X.509-style PKI that means, A is a CA, p(X) is a claim along the lines of "the Key K herein belongs to entity X" and the unforgeable way is via secure digital signatures with adequate key-lengths (for simplicity, I assume that all relevant algorithms are implemented flawlessly...).

Public-key certificates have the purpose to authenticate an assertion, namely that you are communicating with the entity that you intend to communicate with. Specifically, guarding against a Man-in-the-Middle attack (MitM) is done by authenticating the key material that is used.

Your issue is the following. Say A and B want to establish a secure channel using their public keys $K^\mathsf{pub}_A$ and $K^\mathsf{pub}_B$. If they haven't yet established a secure key exchange, a plain exchange is prone to a MitM. So you utilize a trusted entity (CA in PKI, KDC in Kerberos) that vouches for authenticity of the exchanged public keys by way of certificates (see below). Asymmetric crypto has the great advantage that a certificate, once issued, can be reused many times for many communication peers. Compare that to the symmetric case where you cannot reuse Kerberos tickets - that's one of the reasons why certificates have a much longer life time than Kerberos tickets. The only problem that remains is how to establish a secure channel between A and CA and B and CA. This cannot happen ad-hoc in a trustworthy way, which is the central point of your question.

So it seems that by utilizing a CA you have just moved the problem around without any progress (even worse, you introduced a new critical dependency), but there is one important difference: You need to establish a secure channel only with one trust anchor - which makes the problem feasible in the first place.

You need to take a special route to establish trust between you and a trust anchor. This can be by meeting in person or other suitable out-of-band mechanisms. In Windows Active Directory environments this is you being authenticated on a computer joined to a domain using your credentials. The trick here is to design the process such that it scales well. However, there are still many leaps of faith to make:

In principle, a public-key certificate works like any other kind of certificate, including the ones in the real world.

1. If some authority A asserts some property $\mathsf{Property}(X)$ for some $X$
2. If A publishes the assertion in a kind-of unforgeable way
3. If some entity Y trusts A

then Y has virtually no choice but to believe that $\mathsf{Property}(X)$ is true.

For public-keys in a X.509-style PKI that means, A is a CA, $\mathsf{Property}(X)$ is a claim along the lines of "the key $K^\mathsf{pub}_X$ herein belongs to entity $X$" and the unforgeable way is via secure digital signatures with adequate key-lengths (for simplicity, I assume that all relevant algorithms are implemented flawlessly...).

Moreover, the following conditions are crucial:

4. Y needs to have a genuine copy of CA's public key.
5. CA must be trustworthy, which means, the know what they do, they are not corrupt or being corrupted themselves.
6. All devices involved are trustworthy (i.e. not infested by trojans, backdoors and such)

Each of those are quite tricky and hard to achieve - if at all.

Running a root CA properly is not easy, especially since they are a very attractive attack target. You need detailed procedures, background checks of the staff, regular training, suitable rooms, etc. etc. etc. And yes, there are audits by the browser forum and possibly other bodies, but the famous glitches of Commodo and DigiNotar show how hard it is to run a CA properly.

Moreover, each of the following conditions are crucial:

4. Y needs to have a genuine copy of CA's public key.
5. CA must be trustworthy, which means, they know what they do and they are not corrupt or being corrupted themselves.
6. All devices involved are trustworthy (i.e. not infested by trojans, backdoors and such)

Each of those is quite tricky and hard to achieve - if at all.

Running a root CA properly is not easy, especially since they are very attractive attack targets. You need detailed procedures, background checks of the staff, regular training, suitable rooms, etc. etc. etc. And yes, there are audits by the browser forum and possibly other bodies, but the famous glitches of Commodo and DigiNotar show how hard it is to run a CA properly.