SNOWMAN PKI

From FnordWiki
Revision as of 14:14, 20 July 2015 by Adj (talk | contribs) (→‎Certificate authority hierarchy)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Wherein Aaron buys in to the long strings of bits cartel...

What's the idea of a public key infrastructure?

Alice wants to talk to Bob. Alice doesn't really know Bob, but her message is for Bob alone. How does she do this without meeting Bob in a dark alley somewhere and doing DNA swabs? One way is to have someone Alice trusts vouch for Bob. We'll call this vouching entity a certificate authority or CA.

With a public key infrastructure in place, Alice will a list of certificate authorities. When Alice contacts Bob, Bob presents some credentials that were issued by one of the CAs Alice trusts. Alice thus gains some assurance that she actually is talking to Bob. (There are a number of ways this trust can be subverted, though. Someone may have stolen the keys Bob uses as identification. Or someone may have tricked the certificate authority into issuing credentials that say "Bob" even though they are not Bob.) Bob can also ask Alice for some credentials issued by a certificate authority that he trusts. We wind up with all parties trusting the certificate authority's vouches instead of needing a sort out another way of verifying identity.

Certificate authority hierarchy

We'll be using the OpenSSL suite of tools. We'll actually have a number of certificate authorities: One root CA, which issues certificates for its intermediate certificate authorities, and maintains a certificate revocation list in case an subordinate's keys are compromised. Two subordinate CAs, the first will issue certificates and the second is a standby, in case the first is compromised. Subordinate 1 will issue certificates to CAs dedicated to certificates for specific purposes: IPSEC, backup, internal web based services, and so on.

Root CA key generation

Our root CA's key will be quite large by 2015 standards. We make it like so:

$ openssl genrsa -aes256 -out SNOWMAN-root-CA.pem 8192
Generating RSA private key, 8192 bit long modulus
........................................................................................................................
................................................++
........................................................................................................................
........................................................................................................................
........................................................................................................................
...................................................................++
e is 65537 (0x10001)
Enter pass phrase for SNOWMAN-root-CA.pem: a very secure passphrase goes here
Verifying - Enter pass phrase for SNOWMAN-root-CA.pem: a very secure passphrase goes here (again)
$

So, we now have an encrypted version of an 8192 bit long RSA private key in a file called SNOWMAN-root-CA.pem. Do not lose the passphrase, or the whole CA hierarchy will be lost. Next up, we'll make a certificate from that key

Root CA certificate