<.
The philosophy behind CAs is to create principals called *certificate
authorities* (CAs) whose purpose is to issue certificates.
Everyone has the CA's own self-signed certificate Cert(CA; CA)
pre-installed on their system. When machine S wants a certificate for
itself, binding id_S to K_S, then S contacts the CA, enrolls, and the
CA issues certificate Cert(S; CA) to S. When A wants to authenticate S,
then S must present its certificate Cert(S; CA) to A.
Immediately we have two problems: (i) no one trusts a single CA anywhere
in the world, and even if they did, (ii) the CA would be a single point
of failure. So in reality there are many CAs: somewhere around 1500
have been observed on the public internet in recent years. Your
university/company/bank could be a CA for its
students/employees/customers. And there are commercial CAs that will
issue certificates if you pay them enough—for example, Verisign.
Your browser and/or your OS actually come with the certificates for
those commercial CAs preinstalled. Sometimes if you pay the CA more,
they do better verification of attributes at enrollment, and you get an
*enhanced* certificate that causes the browser to display their name
more prominently.
CAs as implemented in practice are hierarchical: a master CA will
certify a subordinate CA as Cert(Sub; Master), then the subordinate will
issue certificates itself. And subordinates could themselves have sub's,
etc. So we have certificate chains again—for example,
Cert(Sub1; Master), Cert(Sub2; Sub1), Cert(Alice; Sub2).
### Revocation
Regardless of the distribution philosophy, certificates have a
substantial problem when it comes to *revocation*: what happens when a
certificate needs to be withdrawn. Revocation might happen periodically
as a key's cryptoperiod expires, hence old certificates need to be
replaced by new. Revocation might be necessary because the subject's
private key was compromised and is no longer trustworthy, or maybe
because the issuer's was.
Here are three strategies for implementing revocation:
- **Certificate revocation lists (CRL):** the CA publishes lists of of
revoked certificates. Machines download and check that list every
time they need to verify a certificate. Downloading the list is
expensive, so implementors will naturally cache, leading to TOCTOU
attacks.
- **Online certificate validation:** the CA stands up *validation
servers* that accept certificates as input and determine whether
they have been revoked. Machines contact one of these servers every
time they need to verify a certificate. The validation servers now
become a potential point of attack, and DOS against them leads to
the inability to authenticate.
- **Fast expiration:** the CA issues certificates only with short
validity, e.g., 10 min to 24 hrs. CAs now have to issue certificates
with much greater frequency, and machines frequently need to acquire
new certificates.
Revocation is a serious practical problem. Consider, for example, what
happens when an issuer's key is compromised. A large such breach
occurred in March 2011. CA Comodo had nine rogue certificates issued
through it for Gmail, Hotmail, Google, Yahoo, Skype, Firefox, etc.
Whoever got those certificates could impersonate those businesses to
anyone who doesn't know they're revoked. Browsers, OSs had to push out
updates to revoke the certificates. So we're placing a lot of trust in
CAs. Trust is an assumption, and assumptions are vulnerabilities...
]]>