Support for managing revoked certs

[stensonb]

Authentication via x509 certs are great...until one of the certs is compromised, needs to be revoked, or is no longer required.

CRL offers a way to this by distributing a blacklist.
OCSP offers a way to verify each request's authenticity cert against a service, denying validity for certs which have been "revoked".

ETCD should support either CRL, OCSP, or both to ensure that SSL keys can be guaranteed "valid", despite being signed with a common CA.

[stensonb]

Maybe this is desired approach: https://en.wikipedia.org/wiki/OCSP_stapling

[xiang90]

/cc @gtank

[gtank]

@stensonb Are you talking about revoking client certificates, or clients being able to check an etcd peer's certificate?

[stensonb]

The case I had in mind was the revoking client certificates...

[philips]

This is related on TLS authentication for the servers: #4022

[gtank]

I think dependency on an OCSP server (or being an OCSP server) is out of scope for etcd. However it would be completely reasonable for peers to check a CRL if the admin supplies one. Go provides functions for handling CRLs already, we will just need to build the logic around them.

[philips]

So, the idea would be a periodic polling routine that checks the CRL URL? What happens if the CRL URL is unreachable? What is the normal policy for that?

[gtank]

I was thinking about a static/out-of-band CRL for emergency revocations. "Normal" policy for online revocation of all kinds is soft fail, which is dubiously useful (chronicled by various agl pieces, such as https://www.imperialviolet.org/2014/04/19/revchecking.html). Though it might be better in this case since we're mainly concerned about stolen client credentials and not attackers targeting the etcd peers.