Security/Features/Browser CRL

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

Status

Browser CRL
Stage	Draft
Status	In progress
Release target	`
Health	OK
Status note	`

{{#set:Feature name=Browser CRL

|Feature stage=Draft |Feature status=In progress |Feature version=` |Feature health=OK |Feature status note=` }}

Team

Product manager	SId Stamm
Directly Responsible Individual	David Keeler
Lead engineer	David Keeler
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=SId Stamm

|Feature feature manager=David Keeler |Feature lead engineer=David Keeler |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

Implement a revocation list push mechanism in Firefox, which will push revocation lists of certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This will improve security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker.

We should be able to use this revocation push mechanism to quickly revoke (distrust) root certificates, intermediate certificates, and end-entity certificates.

Every time we have to distrust a certificate for any reason (such as a security compromise or an instance of MITM) we either have to create an emergency update or quickly get it into an upcoming release (when the timing works in our favor and allows us to do so). We need to make it less costly, easier, and faster to distrust certificates.

When a CA revokes an intermediate certificate due to a security concern, Mozilla should give an Untrusted Connection error for websites with certs signed by the revoked intermediate certificate. https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates

When a CA revokes an end-entity certificate due to a security concern, Mozilla should give an Untrusted Connection error for websites with that SSL certs. https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Certain_End-Entity_Certificates

2. Users & use cases

There are currently three use cases this feature addresses:

1. A CA is no longer trusted (in its entirety), so needs to be treated as revoked.
2. A CA's intermediate certificate is no longer trusted, so needs to be treated as revoked.
3. The key of an end-entity certificate belonging to a high-profile entity is compromised (e.g. a bank, government, etc.), so needs to be treated as revoked.

Instead of spinning up and releasing a binary update, we simply add entries as appropriate to the Browser CRL. Next time the user's browser pings us for updates, we ship them the new Browser CRL and the changes instantly take effect.

3. Dependencies

`

4. Requirements

1. The ability to revoke (and treat as revoked) root certificates, intermediate certificates, and end-entity certificates.
2. The ability to use specific keys to identify which certificates to treat as revoked.
3. The ability to undo a block should one be applied erroneously

Non-goals

This will not serve the same purpose as shipping a white-list of all intermediate certificates, which is another proposal under discussion.

This does not solve revocation in general. We will not add Joe Schmoe's compromised server certificate to the blocklist.

Stage 2: Design

5. Functional specification

`

6. User experience design

There should not be any UX changes.

Stage 3: Planning

7. Implementation plan

Previously this feature request was called "Cert BLocklist via Update Ping" https://wiki.mozilla.org/Security/Features/Cert_Blocklist_via_Update_Ping

It was originally thought that the easiest way to implement this feature would be to piggyback on the blocklist. Whoever works on creating this Browser CRL feature should consider that, as well as other implementation strategies.

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=Implement a revocation list push mechanism in Firefox, which will push revocation lists of certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This will improve security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker.

We should be able to use this revocation push mechanism to quickly revoke (distrust) root certificates, intermediate certificates, and end-entity certificates.

Every time we have to distrust a certificate for any reason (such as a security compromise or an instance of MITM) we either have to create an emergency update or quickly get it into an upcoming release (when the timing works in our favor and allows us to do so). We need to make it less costly, easier, and faster to distrust certificates.

When a CA revokes an intermediate certificate due to a security concern, Mozilla should give an Untrusted Connection error for websites with certs signed by the revoked intermediate certificate. https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates

When a CA revokes an end-entity certificate due to a security concern, Mozilla should give an Untrusted Connection error for websites with that SSL certs. https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Certain_End-Entity_Certificates |Feature users and use cases=There are currently three use cases this feature addresses:

1. A CA is no longer trusted (in its entirety), so needs to be treated as revoked.
2. A CA's intermediate certificate is no longer trusted, so needs to be treated as revoked.
3. The key of an end-entity certificate belonging to a high-profile entity is compromised (e.g. a bank, government, etc.), so needs to be treated as revoked.

Instead of spinning up and releasing a binary update, we simply add entries as appropriate to the Browser CRL. Next time the user's browser pings us for updates, we ship them the new Browser CRL and the changes instantly take effect. |Feature dependencies=` |Feature requirements=# The ability to revoke (and treat as revoked) root certificates, intermediate certificates, and end-entity certificates.

1. The ability to use specific keys to identify which certificates to treat as revoked.
2. The ability to undo a block should one be applied erroneously

|Feature non-goals=This will not serve the same purpose as shipping a white-list of all intermediate certificates, which is another proposal under discussion.

This does not solve revocation in general. We will not add Joe Schmoe's compromised server certificate to the blocklist. |Feature functional spec=` |Feature ux design=There should not be any UX changes. |Feature implementation plan=Previously this feature request was called "Cert BLocklist via Update Ping" https://wiki.mozilla.org/Security/Features/Cert_Blocklist_via_Update_Ping

It was originally thought that the easiest way to implement this feature would be to piggyback on the blocklist. Whoever works on creating this Browser CRL feature should consider that, as well as other implementation strategies. |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	P2
Rank	999
Theme / Goal	Product Hardening
Roadmap	Security
Secondary roadmap	Platform
Feature list	`
Project	`
Engineering team	Security

{{#set:Feature priority=P2

|Feature rank=999 |Feature theme=Product Hardening |Feature roadmap=Security |Feature secondary roadmap=Platform |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=` }}