Confirmed users
717
edits
No edit summary |
No edit summary |
||
| Line 19: | Line 19: | ||
|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- | |Feature functional spec=See https://tools.ietf.org/html/draft-evans-palmer-key-pinning . | ||
As the draft suggests (but does not require) in 6.1, we should require 2 or more pins, 1 of which is not used in the currently-served chain. This reduces the ability of people to shoot themselves in the foot and will preserve the good reputation of the technology. | As the draft suggests (but does not require) in 6.1, we should require 2 or more pins, 1 of which is not used in the currently-served chain. This reduces the ability of people to shoot themselves in the foot and will preserve the good reputation of the technology. | ||
We should also consider _requiring_ a breakv code, and talk to the authors about making that a spec requirement. | We should also consider _requiring_ a breakv code, and talk to the authors about making that a spec requirement. | ||
|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?) | ||