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 _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
