Security/Features/CA pinning functionality

Please use "Edit with form" above to edit this page.

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	Camilo Viecco
Lead engineer	Camilo Viecco
Security lead	Curtis Koenig
Privacy lead	Sid Stamm
Localization lead	`
Accessibility lead	`
QA lead	`
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	Gervase Markham

{{#set:Feature product manager=Lucas Adamski

|Feature feature manager=Camilo Viecco |Feature lead engineer=Camilo Viecco |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=Gervase Markham }}

Open issues/risks

`

Stage 1: Definition

1. Feature overview

Now they can require HTTPS connections (via HSTS), sites may want to also restrict the CAs who can issue certificates for their domain to a small number (> 1) that they trust. This can be accomplished via providing a list of certificate fingerprints, at least one of which must be present in any chain considered valid for the domain. This is rather like what Chrome has done [1] except we would not be managing a static list of anchors.

2. Users & 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).

The spec does not necesaily ping the CA, it pins a subset of keys so that at least one of the keys pinned must be in the CA list of the certificate.

3. Dependencies

HSTS. This feature should not be tied to HSTS, but the two technologies should work together.

4. 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.)

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)

Stage 2: Design

5. Functional specification

See https://tools.ietf.org/html/draft-evans-palmer-key-pinning .

6. User experience 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?)

If site access is denied, we will need a screen explaining why. (There will be no override, as per spec.)

We should already have mechanisms for clearing stored HSTS information when the user clears their history; pin information should go with it.

Stage 3: Planning

7. Implementation plan

The pinning data will be stored as a site pref. And it will be implemented in a way similar to STS. The first stage would be to enhance the preferences to be able to store blobs or strings.

Shall this be included in the STS .idl file? Dont know yet.

We shall notice that this is an HTTP extension. Not an TLS/SSL extension.

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

So we have two bugs created now: https://bugzilla.mozilla.org/show_bug.cgi?id=744212 and https://bugzilla.mozilla.org/show_bug.cgi?id=744204

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |Feature overview=Now they can require HTTPS connections (via HSTS), sites may want to also restrict the CAs who can issue certificates for their domain to a small number (> 1) that they trust. This can be accomplished via providing a list of certificate fingerprints, at least one of which must be present in any chain considered valid for the domain. This is rather like what Chrome has done [2] except we would not be managing a static list of anchors. |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).

The spec does not necesaily ping the CA, it pins a subset of keys so that at least one of the keys pinned must be in the CA list of the certificate. |Feature dependencies=HSTS. This feature should not be tied to HSTS, but the two technologies should work together. |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.) |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)

|Feature functional spec=See https://tools.ietf.org/html/draft-evans-palmer-key-pinning . |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?)

If site access is denied, we will need a screen explaining why. (There will be no override, as per spec.)

We should already have mechanisms for clearing stored HSTS information when the user clears their history; pin information should go with it. |Feature implementation plan=The pinning data will be stored as a site pref. And it will be implemented in a way similar to STS. The first stage would be to enhance the preferences to be able to store blobs or strings.

Shall this be included in the STS .idl file? Dont know yet.

We shall notice that this is an HTTP extension. Not an TLS/SSL extension. |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=So we have two bugs created now: https://bugzilla.mozilla.org/show_bug.cgi?id=744212 and https://bugzilla.mozilla.org/show_bug.cgi?id=744204 |Feature landing criteria=` }}

Feature details

Priority	P1
Rank	999
Theme / Goal	Security Leadership
Roadmap	Security
Secondary roadmap	`
Feature list	`
Project	`
Engineering team	Security

{{#set:Feature priority=P1

|Feature rank=999 |Feature theme=Security Leadership |Feature roadmap=Security |Feature secondary roadmap=` |Feature list=` |Feature project=` |Feature engineering team=Security }}

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=` }}