[cryptography] Public Key Pinning Extension for HTTP (draft-ietf-websec-key-pinning-01)

Ryan Sleevi ryan+cryptography at sleevi.com
Fri Nov 2 06:23:22 EDT 2012

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.

More information about the cryptography mailing list