> On 15 May 2016, at 10:54 PM, Yaron Sheffer <[email protected]> wrote: > >>> On 15/05/16 10:22, Yoav Nir wrote: >>>> That’s interesting. With HPKP you can pin keys from existing certificates, >>>> or keys that are not (yet) in certificates. >>>> >>>> One of the early deployment scenarios (which got de-emphasized later on) >>>> was that you include two pins: your current production key and a spare key >>>> that you will certify if something bad happens to the production key (like >>>> the private key leaking out). >>>> >>>> >>> Hi Yoav, >>> >>> I had assumed this *is* the main deployment scenario. If it was >>> de-emphasized, what do you consider as the "classic" HPKP usage scenario? >> >> Current certificate plus some CA certificate that you are likely to use to >> certify your next certificate. >> >> Yoav >> > > But this too means that you're guessing how the CA will behave in the future. > If your current cert is expiring in a month and you generate the new one, you > can be surprised by the CA using a new intermediate cert. > > And of course, some people would never pin to a CA cert. To me, the whole > idea of certificate pinning is to reduce the need to trust the PKI industry, > and that includes my own friendly CA.
I agree. Appendix B of RFC 7469 recommends to have the backup pin signed by a different CA and ready to use. That solves the issue of not knowing how a CA might encode the SPKI. It used to be a costly solution, but these days a certificate is pretty much free, so you really can have a backup certificate ready to use. Yoav _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
