Security/Features/CA pinning functionality: Difference between revisions
No edit summary |
No edit summary |
||
| Line 16: | Line 16: | ||
}} | }} | ||
{{FeatureInfo | {{FeatureInfo | ||
|Feature priority= | |Feature priority=P1 | ||
|Feature theme=Security Leadership | |Feature theme=Security Leadership | ||
|Feature roadmap=Security | |Feature roadmap=Security | ||
}} | }} | ||
{{FeatureTeamStatus}} | {{FeatureTeamStatus}} | ||
Revision as of 19:43, 10 February 2012
Status
| CA Pinning | |
| Stage | Draft |
| Status | ` |
| Release target | ` |
| Health | OK |
| Status note | ` |
{{#set:Feature name=CA Pinning
|Feature stage=Draft |Feature status=` |Feature version=` |Feature health=OK |Feature status note=` }}
Team
| Product manager | Lucas Adamski |
| Directly Responsible Individual | ` |
| Lead engineer | ` |
| Security lead | Curtis Koenig |
| Privacy lead | Sid Stamm |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=Lucas Adamski
|Feature feature manager=` |Feature lead engineer=` |Feature security lead=Curtis Koenig |Feature privacy lead=Sid Stamm |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
As they can require HTTPS connections (via HSTS), sites may want to also restrict the CAs who can issue certificates for their domain to one or a few that they trust. This can be accomplished via a list of certificate fingerprints that are exclusively allowed to act as trust anchors for a given domain. This is like what chrome has done [1] except we would not be managing a static list of anchors.
2. Users & use cases
CA x is compromised and grants a certificate for example.com to an attacker. The owners of example.com have their site pinned to the certificate for CA y, so when the attacker attempts to use the certificate from x, he fails to satisfy the pinning requirement and thus any users presented with his certificate will not have access to the fraudulent connection.
3. Dependencies
`
4. Requirements
See https://tools.ietf.org/html/draft-evans-palmer-hsts-pinning
Non-goals
- This is not a replacement for the existing x.509 PKI infrastructure. It is a refinement.
Stage 2: Design
5. Functional specification
`
6. User experience design
`
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
` {{#set:Feature open issues and risks=` |Feature overview=As they can require HTTPS connections (via HSTS), sites may want to also restrict the CAs who can issue certificates for their domain to one or a few that they trust. This can be accomplished via a list of certificate fingerprints that are exclusively allowed to act as trust anchors for a given domain. This is like what chrome has done [2] except we would not be managing a static list of anchors. |Feature users and use cases=CA x is compromised and grants a certificate for example.com to an attacker. The owners of example.com have their site pinned to the certificate for CA y, so when the attacker attempts to use the certificate from x, he fails to satisfy the pinning requirement and thus any users presented with his certificate will not have access to the fraudulent connection. |Feature dependencies=` |Feature requirements=See https://tools.ietf.org/html/draft-evans-palmer-hsts-pinning |Feature non-goals=* This is not a replacement for the existing x.509 PKI infrastructure. It is a refinement. |Feature functional spec=` |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}
Feature details
| Priority | P1 |
| Rank | 999 |
| Theme / Goal | Security Leadership |
| Roadmap | Security |
| Secondary roadmap | ` |
| Feature list | ` |
| Project | ` |
| Engineering team | ` |
{{#set:Feature priority=P1
|Feature rank=999 |Feature theme=Security Leadership |Feature roadmap=Security |Feature secondary roadmap=` |Feature list=` |Feature project=` |Feature engineering team=` }}
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}