Changes

Public Key Pinning is a mechanism for sites to specify which certificate authorities have issued valid certs for that site, and for user-agents to reject TLS connections to those sites if the certificate is not issued by a known-good CA. The benefit of certificate Public key pinning is that users cannot be mitm'ed because of a prevents man-in-the-middle attacks due to rogue CA CAs not on the site's list (see the Diginotar attack which Chrome detected and we did not: https://blog.mozilla.org/security/2011/08/29/fraudulent-google-com-certificate/).

The feature binds a set of hashes public keys to a domain name such that when connecting to a site using TLS the browser ensures that there is an intersection between the public keys in the computed trust chain and the set of fingerprints associated with that domain. This check is done during the certificate verification phase of the connection, before any data is sent or processed by the browser. In particular we are pinning the sha256 digest of the der encoded subject public key info. In order to reduce rejections, firefox will compute Firefox computes all potential trust chains before deciding that are no valid pins.

== Built -in Pins ==

==Pinning Service ==

== HPKP Header Public Key Pinning Extension for HTTP ==

The final state where we parse headers sent by HTTP Public Key Pinning (HPKP) [http://tools.ietf.org/html/draft-ietf-websec-key-pinning-12] is an HTTP header that allows sites to populate the pinning serviceannounce their pinset. It relies on "clean load" in order to provide a similar level of assurance as built-in pins. Tracking bug: {{bug|787133}}