In 2011, Google added public key pinning to Chrome. They white-listed the certification authority public keys that could be used to secure Google domains. The intent was to mitigate man-in-the-middle attacks that were performed by using a fraudulent SSL certificate. The approach was not scalable for all websites, but Google did offer to pin other large, high-security websites.

The approach was useful as it helped to identify the DigiNotar attack and the recent CA certificate mis-issuance by TURKTRUST.

To address the scalability issues, a new approach to public key pinning is being proposed and is documented in a yet-to-be-published RFC. The goal will have website operators define their public key pins through an HTTP header. The browsers would respect these headers and produce an error when the pin has been violated.

The public key pin will be identified by the SHA-1 or SHA-256 algorithm of the key. The public key can be the website certificate, an intermediate CA or the root CA. The methodology pins public keys, rather than entire certificates, to enable operators to generate new certificates containing old public keys.

The public key pin will also have directives to define the maximum age of the pin (in seconds), whether it supports subdomains, the URI where to report errors, and the strictness of the pinning. An example pin would look as follows:

Public-Key-Pins: pin-sha1=”qvTGHdzF6KLavt4PO0gs2a6pQ00=”; pin-sha256=”LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=”; max-age=2592000; includeSubDomains

Based on the effectiveness of the current public key pins, I believe the RFC will be finalized and will be supported by all the mainstream browsers. Will provide more updates as the RFC gets finalized.

Update May 1 2015: Public Key Pinning Extension for HTTP is RFC 7469.

Entrust Datacard