On Thu, November 1, 2012 2:22 pm, Jeffrey Walton wrote: > Hi All, > > I was reading through Public Key Pinning Extension for HTTP > (draft-ietf-websec-key-pinning-01, > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01). > > Section 3.1. Backup Pins, specifies that a backup should be available > in case something goes awry with the current pinset. The backup pinset > is a hash of undisclosed certificates or keys. Appendix A. Fingerprint > Generation, then offers a program to hash a PEM encoded certificate. > > My question: Google (and likely others) rotate their certificates > regularly, while the underlying public key is fixed (from observations > over the last 2 years or so). Does that mean those complying with the > specification will need to send an out of band update with the newest > hashed backup certificate (about every 30 or 60 days)? Would it be > better to retain a hash of the public key instead since the public key > rarely changes? > > Jeff
Thanks Jeff, Note that this is being discussed in the IETF, which may be a better place to bring concerns/suggestions. The point you raise is more an editorial note - backup pins behave just like normal pins (eg: Section 2.2), which means that they're the hash of the SPKI. This is because there is no discussion of how hashing certificates works in the spec. I fear you may have misread Appendix A - it is *not* about generating a hash of a PEM certificate, but about how to take a PEM-encoded certificate and generate a hash of the SPKI. So yes, pins are of SPKIs, regardless of certificate or naming. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
