[stanleydrew]

There is a debate about which public key to pin, and I'm not sure it's settled. It depends on your priorities and the relative probabilities you put on various failure modes.

If you pin your public key, it's easy to switch CAs if the one you currently use goes under. This does happen.[1] But you are in trouble if you lose your key somehow.

If you pin your CA's public key, it's easy to recover from losing your key but you can't switch CAs until your pin expires. You could use the required second HPKP pin to add a fallback CA though.

I will note that this decision is not actually the hard part of deploying HPKP.

[1] https://blog.mozilla.org/security/2016/10/24/distrusting-new...

[the8472]

> You could use the required second HPKP pin to add a fallback CA though.

Or pin current CA + current pubkey? That way you can either change certificate within the current CA or use the current certificate to move to any new CA.

[pfg]

You should add one additional (CA|end-entity) pin regardless. If your key is compromised, there's a non-zero chance that you'll realize that your CA has stopped issuing certificates under the CA key you pinned at the same time. Most CAs aren't very transparent with regards to their root/intermediate lifecycles.

[hdhzy]

Well actually HPKP will not work if there is only one pin present. The browser will reject the entire header.

[pfg]

I had to double-check the RFC on this. The OP suggested pinning to "current CA + current pubkey", which would technically count as two pins and satisfy a simple "you'll need at least two pins" requirement. Luckily, the RFC authors realized that someone would try this and wrote it as "The given set of Pins contains at least one Pin that does NOT refer to an SPKI in the certificate chain.", meaning this pin would get rejected.

[hdhzy]

Yes, although they cannot make people backup the inactive pinned key they at least get them to think what they are doing.