This is a really great intro to the how and why of TLS PKI as well as showing how to use CloudFare's really awesome looking CFSSL tool.
I'm a big fan of DigitalOcean but they don't offer VPCs like AWS does so I always have to create a PKI in order to communicate securely between my droplets. I've always done this with some crappy scripts but I'll definitely give CFSSL a shot for automating this next time.
EDIT: One beef I have with cfssl is the csr_ca.json file. Making the keys in the "names" object less obscure would do wonders for readability.
Sure, but if one doesn't have a grasp of the (admittedly user-hostile and obscure) underlying x509 structure you probably shouldn't be running a CA in the first place...
One of the issues with PKI is ensuring that the public key you're using to communicate with the person is actually the right public key, and that someone hasn't replaced it with their own.
I'm curious if you used something like the blockchain (but not bitcoin necessarily) to have a public ledger of published public keys (identities) would that problem be essentially solved? (IE if the keys and any signing for a web of trust be on a distributed public ledger, then you could be reasonably sure that you're dealing with the person really behind that public key?)
Everyone has different ideas about how most efficiently and safely to make public records append-only and achieve distributed consensus, and also what kind of records to put in to the system and what rules to use for validating updates. One way in which proposals have diverged is whether to use blockchain-like distributed consensus for storing and distributing keys, or just for adding transparency to trusted authorities' behavior.
It would be helpful if you could explain why not, and whether your criticism applies just to proof-of-work mechanisms or to other approaches to consensus as well.
Consensus is not a suitable mechanism for authority. Consensus has many uses, but for use-cases where authority is a hard requirement - such as this one - consensus is simply not suitable. Authority needs to remain authority even if a bunch of other people would like it to be otherwise.
If the NSA can throw enough computing power at it and seize control of consensus to determine which keys are authoritative, then your whole PKI is useless.
I repeat: consensus is not a suitable mechanism for authority. Consensus has many other uses. Would you use a watermelon to lock a door?
The most hard part of PKI is omitted completely in the article: how to deal with revocations (CRLs, OCSP and such). Hope that's not because they "forgot" to do that in their actual infrastructure.
With an online certificate issuance service like the one they describe, certificate expiration times can probably be in the 1-24 hour range, reducing the importance of revocation.
1) HSMs are certified, and are relatively robust against individual employees (if configured that way). With anything else, administrators of the system are likely to be able to get access to key material. But a pain to work with, and expensive.
2) Offline key management -- e.g. a laptop in a safe -- was the low end solution for a long time. However, there are a lot of reasons why you want an online CA now
3) Just keeping a key in memory on a machine (doing nothing special) obviously exposes you to several risks:
a) Administrator (can be remote; incl compromise of laptop of admin)
b) Anyone who gains root on the box
c) Application-level security issues (ranging from key leakage to just compromising the application.
d) Physical-access cold boot (which can be more exciting in a virtualized environment)
There are a bunch of ways to improve #3, although it will remain worse than #1 or #2.
a) Simply run the keys in a different process; this protects you against some minimal things, and if you use a PKCS 11 interface, makes upgrading to an HSM later easier.
b) Different user, with a defined interface
c) Different VM
d) Physically separate machines communicating over a bidirectional link (you could do this as two ethernet connections)
e) Two one-way links bound to specific programs (e.g. serial); much harder to compromise both this way. You'd need to compromise the "send commands" program, and "receive commands" program, and the "send response" program. They can be very limited in what they do.
Limiting admin access to physical-presence, or at the very least via a secure pathway which isn't direct to the machine (e.g. a console server which logs) goes a long way, too.
I'm a big fan of DigitalOcean but they don't offer VPCs like AWS does so I always have to create a PKI in order to communicate securely between my droplets. I've always done this with some crappy scripts but I'll definitely give CFSSL a shot for automating this next time.
EDIT: One beef I have with cfssl is the csr_ca.json file. Making the keys in the "names" object less obscure would do wonders for readability.