Security/Features/CA pinning functionality: Difference between revisions

Jump to navigation Jump to search
no edit summary
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-hsts-pinning-00 .
|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?)


Confirmed users
717

edits

Navigation menu