[cryptography] Public Key Pinning Extension for HTTP (draft-ietf-websec-key-pinning-01)
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
> 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?
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