Re: Namecoin as Root-CA for .bit-domains/identities
Posted: Wed Sep 23, 2015 11:01 am
So I was thinking about this some more. Here's a potentially dangerous and probably stupid idea.
Root private key is global knowledge, constant for all .bit.
Intermediate pubkey is public, in blockchain.
Website operator procedure:
1. Generate intermediate CA private key.
2. Generate intermediate CA public key from (1).
3. Generate intermediate CA cert from (2), signed with root CA private key. Name constraint of end-entity name. Valid +/- 10 minutes of current time.
4. Generate end-entity private key.
5. Generate end-entity public key from (4).
6. Generate end-entity cert from (5), signed with (1).
7. Publish (2) in blockchain.
8. Deploy (4) and (6) on website.
Browser plugin procedure:
9. Download (7).
10. Generate (3) from (7) and root CA private key.
11. Import (10) into trust store.
12. Generate hash of (9).
13. Set HPKP pin of (12).
Security properties: (11) can only sign for that .bit name (for 10 minutes after the .bit name is requested), and is only controlled by that .bit name's owner. (13) prevents other CA's from signing for that .bit name.
The obvious crazy thing is that the root private key is public knowledge (and the same for all .bit names). This allows us to not store it in the blockchain. I cannot think of any attacks that this enables (we're not trusting that key for anything), but that doesn't mean there aren't any. An ECDSA public key for the intermediate CA is something like 212 base64 characters according to my quick test with openssl.
Note that the HPKP pin is only needed to protect the user from malicious ICANN CA's. If a malicious ICANN CA is not in the threat model (that's a stupid idea, though), then this should work with anything that allows CA certs to be imported programmatically. The import could be performed by the local DNS server when a .bit domain name is resolved, assuming that running programs accept imports to their trust store while they're running.
If Ryan thinks this is safe, I can probably try to throw together a proof of concept of this. (I'm not convinced that it's safe.)
Root private key is global knowledge, constant for all .bit.
Intermediate pubkey is public, in blockchain.
Website operator procedure:
1. Generate intermediate CA private key.
2. Generate intermediate CA public key from (1).
3. Generate intermediate CA cert from (2), signed with root CA private key. Name constraint of end-entity name. Valid +/- 10 minutes of current time.
4. Generate end-entity private key.
5. Generate end-entity public key from (4).
6. Generate end-entity cert from (5), signed with (1).
7. Publish (2) in blockchain.
8. Deploy (4) and (6) on website.
Browser plugin procedure:
9. Download (7).
10. Generate (3) from (7) and root CA private key.
11. Import (10) into trust store.
12. Generate hash of (9).
13. Set HPKP pin of (12).
Security properties: (11) can only sign for that .bit name (for 10 minutes after the .bit name is requested), and is only controlled by that .bit name's owner. (13) prevents other CA's from signing for that .bit name.
The obvious crazy thing is that the root private key is public knowledge (and the same for all .bit names). This allows us to not store it in the blockchain. I cannot think of any attacks that this enables (we're not trusting that key for anything), but that doesn't mean there aren't any. An ECDSA public key for the intermediate CA is something like 212 base64 characters according to my quick test with openssl.
Note that the HPKP pin is only needed to protect the user from malicious ICANN CA's. If a malicious ICANN CA is not in the threat model (that's a stupid idea, though), then this should work with anything that allows CA certs to be imported programmatically. The import could be performed by the local DNS server when a .bit domain name is resolved, assuming that running programs accept imports to their trust store while they're running.
If Ryan thinks this is safe, I can probably try to throw together a proof of concept of this. (I'm not convinced that it's safe.)