Confirmed users
717
edits
No edit summary |
No edit summary |
||
| Line 14: | Line 14: | ||
|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 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 dependencies=HSTS. | |Feature dependencies=HSTS. | ||
|Feature requirements= | |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.) | ||
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.) | |Feature non-goals=* Replacing the existing x.509 PKI infrastructure. (This is a refinement.) | ||
* Enabling pinning without also requiring HTTPS (see section 6.5 of spec) | * Enabling pinning without also requiring HTTPS (see section 6.5 of spec) | ||