Public Key Pinning was great idea at first. Google used static public keys to protect their websites. In doing so, the keys were embedded in Chrome and were useful in helping users find the DigiNotar attack in 2011, and in a mistaken certification authority (CA) certificate issued by TURKTRUST in 2012.
Rolling out static HTTP Public Key Pinning, or HPKP in this manner, was not scalable, but Adam Langley of Google made this offer:
“If you run a large, high security site and want Chrome to include pins, let me know. For everyone else we hope to expose pinning via HSTS, although the details have yet to be worked out. You can experiment with pinning via the HSTS debug UI (chrome://net-internals/#hsts) if you have a new enough version of Chrome.”
RFC 7469 introduced by IETF allowed website administrators to provide a server header with one or more public keys creating a memorable cryptographic identity that prevented man-in-the-middle attacks. This HTTP header brought dynamic HPKP to the masses. The header would be stored for a period of time by the browser and displayed an error if the key did not match. In fact, a site could be blocked for that user if there was a public key change.
So what public key should the website administrator use for HPKP?
The problem with public keys is that further down the chain there is a greater likelihood that the key will change. Higher up the chain there is an increased chance that trust will be spread where it should not be.
The server pubic key should change when an SSL/TLS certificate is renewed. This goes for scheduled renewals as well as forced renewals. Events that trigger a forced renewal include the policy change to move from SHA-1 to SHA-256 signed certificates or in the event of a vulnerability. For example, the Heartbleed attack that occurred during the period of development of HPKP requiring the server public key to change. Don’t forget, you can also lose the key or it could be compromised in which cases you would also need to change it.
The issuing CA public key is controlled by the CA. Some scenarios to be aware of is that the CA might have more than one issuing CA or the issuing CA’s public key could change. It might be best to use this key as long as the administrator is in contact with the CA, and can add in multiple public keys to help anticipate any changes.
In summary, it is very difficult to select a public key or a set of public keys that can be trusted for a long period of time. If the wrong public key is used, a website can be bricked until the server header expires. The wrong key could be provided accidentally or by an attacker. As in many cases, a site can be bricked where the administrator knows nothing about HPKP, or it’s been redirected by an attack.
Other industry experts have also given up on HPKP:
Deployment of HPKP is not recommended. Instead it is recommended organizations use Certification Authority Authorization (CAA) to prevent attacks and website monitory using the Certificate Transparency (CT) logs. Both CAA and CT are relatively risk free.