
How to build your own public key infrastructure - jgrahamc
https://blog.cloudflare.com/how-to-build-your-own-public-key-infrastructure/
======
rubiquity
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.

~~~
sneak
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...

~~~
rubiquity
Haha that's a fair statement to make.

------
tocf
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?)

~~~
schoen
There are a lot of ideas in this direction and some of them will probably
eventually pan out.

A few things to look at (not exhaustive):

[https://okturtles.com/](https://okturtles.com/)

[http://www.coniks.org/](http://www.coniks.org/)

[http://www.certificate-transparency.org/](http://www.certificate-
transparency.org/)

An important early formulation of this possibility was Aaron Swartz's, in
"Squaring Zooko's Triangle":

[http://www.aaronsw.com/weblog/squarezooko](http://www.aaronsw.com/weblog/squarezooko)

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_.

~~~
Kalium
Blockchains, to put it mildly, do not even resemble a viable solution in this
space.

~~~
schoen
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.

~~~
Kalium
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?

------
abbot2
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.

~~~
sneak
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.

------
helper
Anyone have any strategies for running online CAs (relatively) securely
without an HSM?

~~~
rdl
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.

~~~
welterde
Option e) appears to be what CACert is currently going with:
[http://wiki.cacert.org/SystemAdministration/Systems/Signer](http://wiki.cacert.org/SystemAdministration/Systems/Signer)

------
hellbanner
Is anyone familiar with the DarkMail key management architecture?

re
[https://www.youtube.com/watch?v=TWzvXaxR6us](https://www.youtube.com/watch?v=TWzvXaxR6us)

