I’ve talked about this to numerous groups, going back to 1999, but seems I’ve never done so publicly.
Certificate Authorities are completely unnecessary.
“OH MY GOD HOW DO WE MAINTAIN THE WEB OF TRUST?!” you scream. Easy, the same way we do In Real Life, with a little twist.
Posit 1: Your browser starts with a completely empty CA database. Yup. No CAs, no Certs, no CRLs. It has a concept of “levels of trust”, just like PGP/GPG: you explicitly trust certain people/companies/etc. different than others.
Posit 2: CAs only sign for their domain, and all Certs in a domain must be signed by the domain CA.
Posit 3: Domain CAs can also sign other domain CAs that they sufficiently trust. This signature has no functional impact on the system.
Scenario 1: High-Trust, offline relationship. You are a Bank of M@ customer. You visit a Bank of M@ branch and open an account, signing up for online banking. You’re given a read-only USB stick that has the Bank of M@ Certificate Authority Public Key on it. You go home, plug it in, and your browser and other software now knows that all ‘bom@.com’ addresses (email addresses, web RLs, etc.) signed by that key are legit.
Scenario 2: Opportunistic Trust, online relationship. A friend sends you a link to a pair of gloves you’ve been looking for. The link is to a site you’ve never been to, Glamazon.com (that I just made up). You add the item to your shopping cart, click the ‘checkout’ button, and the site redirects you to their SSL site to complete the transaction. Your browser has no data for Glamazon.com. How does it get it? Well, how did it get to Glamazon.com to begin with? A DNS request. It makes a similar DNS request asking for the KEY, which is either a URL pointing to the CA Public Key, or the Public Key block itself. In either case, the browser can load the CA for Glamazon.com, implicitly trust other Glamazon.com Certs and keys signed by it, and you have a new pair of gloves on the way.
Scenario 2a: Treason Uncloaked! You receive an e-mail, purportedly from Glamazon.com, but signed with a different CA, or links to a site purporting to be Glamazon.com but is signed with a different CA. Your e-mail client, which has the CA Key for Glamazon.com loaded warns you visibly of this discrepancy. The content of the e-mail, however, says “We needed to change our CA key, please use this one instead”.
- The CA Key enclosed was not signed with the previous CA Key for Glamazon.com
- The previous CA Key for Glamazon.com isn’t on the published CRL for Glamazon.com
- The CA Key enclosed is not the CA Key obtainable via DNS.
The software, and thus the user, can be pretty certain this is bogus. This is not the Glamazon.com you’re looking for.
Scenario 2b: Subversive Treason Uncloaked! Someone hijacks your DNS. Perhaps the government, perhaps malware, perhaps your jealous life partner. They know your penchant for Glamazon.com and decide to forge their own CA key, and make it so that your browser will download that key, but login through a Man-In-The-Middler server they have set up. Nefarious!
- Your browser indeed downloads the forged key.
- The forged key is not signed by the CA Key you have.
- The CA Key you have is not on a CRL for Glamazon.com
- Or the CA Key you have is on a forged CRL for Glamazon.com, that is not signed with the CA Key you have.
The software, and thus the user, can be pretty certain this is bogus. This is not the Glamazon.com you’re looking for.
Scenario 2c: Real certificate/key/CA change. Glamazon.com’s CA is going to expire soon, so they generate a new one. They sign it with the old CA Key. They add the fingerprint of the old CA Key to their public CRL. They sign the CRL with both the old and new CA Keys.
- New/first-time Glamazon.com customers are oblivious to the switch.
- Existing customers download the new CA Key and the CRL.
- They authenticate the CRL as it is signed by both the old (that they trust) and new (that they’re skeptical of) CA Keys.
- They authenticate the new CA Key as it is signed by the old CA Key.
The software, and thus the user, can be pretty certain this is legitimate. This is the Glamazon.com you’re looking for.
Conclusion: This is a very simple, inexhaustive exercise. More questions remain, but they’re all solvable. There is no reason why every domain can’t be a CA for itself. There is no reason why being a Certificate Authority is a billion-dollar business. There is no reason why we have to put up with an anachronistic monopoly on “trust”. There is no reason why this cannot be free and open, and a domain can generate infinite certificates/keys/etc. for their own domain.
In Verisign We Trust, My Ass.