Confirmed users
76
edits
Security/Features/CA pinning functionality: Difference between revisions
Security/Features/CA pinning functionality (view source)
Revision as of 16:36, 8 August 2012
, 8 August 2012no edit summary
No edit summary |
No edit summary |
||
| Line 24: | Line 24: | ||
|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) | ||
|Feature functional spec=See https://tools.ietf.org/html/draft-evans-palmer-key-pinning . | |Feature functional spec=It will be deployed in two pushes: | ||
1. Do built in pins. | |||
2. Allow website pin data as the ietf draft | |||
See https://tools.ietf.org/html/draft-evans-palmer-key-pinning . | |||
However we need to get clarification on several issues including: | However we need to get clarification on several issues including: | ||
1. What do do when muliple headers are found (?) | 1. What do do when muliple headers are found (?) | ||
2. What is the benefit for the requirement that the backup key must NOT be in the chain? | 2. What is the benefit for the requirement that the backup key must NOT be in the chain? | ||
To allow for self MIM the pinning feature will provide three enforcement levels (it will always be calculated) | |||
0: Ignore pinning, ie allow connectionw with failed pin data. (calculate but store result somewhere internally) Hopefully we can put some UX to reflect failed pins, but this is outside of the current scope. | |||
1. (the default) Ignore Pinning IF the trust anchor is not a built in CA. | |||
2. Strict enforcement. | |||
|Feature ux design=The draft recommends that users have ways of querying which domains are pinned. We need to consider whether we think this is necessary and, if so, how to do it. (Perhaps integrated with the history view?) | |Feature ux design=The draft recommends that users have ways of querying which domains are pinned. We need to consider whether we think this is necessary and, if so, how to do it. (Perhaps integrated with the history view?) | ||
No UI will be provided to change the enforcement level. | |||
If site access is denied, we will need a screen explaining why. (There will be no override, as per spec.) | If site access is denied, we will need a screen explaining why. (There will be no override, as per spec.) | ||
| Line 44: | Line 55: | ||
2. Ability to "Note" a pinning when presented over an error free TLS connection | 2. Ability to "Note" a pinning when presented over an error free TLS connection | ||
3. Ability to use the permission manager at chain building time to ensure a valid (from the pinning perspective planner exists). | 3. Ability to use the permission manager at chain building time to ensure a valid (from the pinning perspective planner exists). | ||
|Feature qa review=This will require a lot of QA, in particular due to the built-in roots. Will need non trivial collaboration with QA. | |||
|Feature implementation notes=So we have two bugs created now: | |Feature implementation notes=So we have two bugs created now: | ||
https://bugzilla.mozilla.org/show_bug.cgi?id=744212 (this one is waiting for review) | https://bugzilla.mozilla.org/show_bug.cgi?id=744212 (this one is waiting for review) | ||