Security/Features/CA pinning functionality: Difference between revisions

|Feature overview=Now they can require HTTPS connections (via HSTS), sites may want to also restrict the CAs who can issue certificates for their domain to a small number (> 1) that they trust. This can be accomplished via providing a list of certificate fingerprints, at least one of which must be present in any chain considered valid for the domain. This is rather like what Chrome has done [http://www.imperialviolet.org/2011/05/04/pinning.html] except we would not be managing a static list of anchors.

|Feature users and use cases=CA Foo is compromised and grants a certificate for example.com to an attacker.  The owners of example.com have their site pinned to certificates from CAs Bar and Baz, so when the attacker attempts to use the certificate from CA Foo, he fails to satisfy the pinning requirement. Any users presented with his certificate will not have access to the fraudulent connection (hard fail).

|Feature requirements=Google has had CA pinning for a while; we should talk to them about their experience and any risks/problems with current proposals. (We need to separate issues with having a hard-coded list, which we aren't planning to do, from issues with the idea of pinning itself.)

|Feature non-goals=* Replacing the existing x.509 PKI infrastructure. (This is a refinement.)