Namecoin as Root-CA for .bit-domains/identities

biolizard89
Posts: 1932
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Namecoin as Root-CA for .bit-domains/identities

Post by biolizard89 » 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.)
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

ryanc
Posts: 147
Joined: Wed Dec 18, 2013 8:10 pm
os: linux

Re: Namecoin as Root-CA for .bit-domains/identities

Post by ryanc » Thu Sep 24, 2015 10:22 pm

If a particular structure and set of options were enforced on them, it would be possible to "compress" an ECDSA certificate down to specify only the start/end dates, compressed public key, and signature. This breaks down to:

* 33 bytes for the compressed public key

* 32 bytes for r

* 32 bytes for s

* 3 bytes for a reduced resolution notBefore time (five minute intervals since Jan 1st 2010 or something)

* 3 bytes for a reduced resolution notAfter time

This adds up to 103 bytes - add in a version byte to bring it up to 104 bytes. Since we're doing highly custom shit anyway, we can encode it in base91 (printable characters excluding \, ", $ and space) and end up with 128 printable characters.

Post Reply