Cert pinning

[Matthew Selsky]

On Thu, Mar 28, 2019 at 04:06:05PM -0700, Gary E. Miller via devel wrote:

> > I think public key (as opposed to certificate) pinning is the common
> > approach these days. The application simply requires that one of the
> > public keys in the chain match the pinned public key. The user can
> > decide if they want to pin the server public key, the intermediate CA,
> > or the root CA.
> 
> Tell that to Matt Selsky.  He changed the ntpsec.org pinning to
> be that if the signing cert.  Updating the pins every 90 days
> was a PITA.

In the LE cert via GitLab Pages case, yes, cert pinning to the leaf was too
much trouble, so I created TLSA records for the LE root certificate. But I can
see a case where longer lifetimes are used, or the certs are self-signed, then
having the flexibility to match anything in the chain would be quite useful as
Richard was describing.

> > That said, we need to think carefully about the intended interactions
> > between pinning and validation (or lack thereof with noval).
> 
> Not need to think about it.  Lot's of prior art.  Just use that.
> The DANE is well thought out.

So we want to support the equivalent of DANE's 311 and 211 modes?

> > I think that you in particular are using pinning to avoid adding the
> > server operator's private root certificate that you don't trust.
> 
> Today, yes.  And no way I'll ever add a provate root cert I don't
> have enourmous trust in.

You probably wouldn't add a private root cert to your system trust store, but
you might allow it for a specific NTS server entry.


Thanks,
-Matt