Status
| Cert Blocklist via Update Ping | |
| Stage | On hold |
| Status | In progress |
| Release target | ` |
| Health | OK |
| Status note | ` |
{{#set:Feature name=Cert Blocklist via Update Ping
|Feature stage=On hold |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
The general blocklisting mechanism currently in Firefox is potentially being redesigned. As the simplest way to implement this feature is to piggyback on the blocklist, any changes to that mechanism will have to be taken into consideration. See https://etherpad.mozilla.org/BlocklistWishlist.
Stage 1: Definition
1. Feature overview
This feature is a subscription-based blocklisting of certs via update ping. It allows Mozilla to push out rapid blocklist of certificates when something bad happens in the PKI infrastructure. This prevents us from having to ship an update to disable a root or block a certificate.
2. Users & use cases
There are currently three use cases this feature addresses:
- A CA is no longer trusted (in its entirety)
- A CA's intermediate certificate is no longer trusted
- The key of an end-entity certificate belonging to a high-profile entity is compromised (e.g. a bank, government, etc.)
Instead of spinning up and releasing a binary update, we simply add entries as appropriate to the blocklist. Next time the user's browser pings us for updates, we ship them the new blocklist and the changes instantly take effect.
3. Dependencies
`
4. Requirements
- The ability to block root certificates, intermediate certificates, and end-entity certificates
- The ability to block certificates using specific keys
- 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. In theory, once that feature is realized, only end-entity entries will be put on the blocklist and CA intermediate or root certs can simply be removed from the white-list.
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
`
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=The general blocklisting mechanism currently in Firefox is potentially being redesigned. As the simplest way to implement this feature is to piggyback on the blocklist, any changes to that mechanism will have to be taken into consideration. See https://etherpad.mozilla.org/BlocklistWishlist. |Feature overview=This feature is a subscription-based blocklisting of certs via update ping. It allows Mozilla to push out rapid blocklist of certificates when something bad happens in the PKI infrastructure. This prevents us from having to ship an update to disable a root or block a certificate. |Feature users and use cases=There are currently three use cases this feature addresses:
- A CA is no longer trusted (in its entirety)
- A CA's intermediate certificate is no longer trusted
- The key of an end-entity certificate belonging to a high-profile entity is compromised (e.g. a bank, government, etc.)
Instead of spinning up and releasing a binary update, we simply add entries as appropriate to the blocklist. Next time the user's browser pings us for updates, we ship them the new blocklist and the changes instantly take effect. |Feature dependencies=` |Feature requirements=* The ability to block root certificates, intermediate certificates, and end-entity certificates
- The ability to block certificates using specific keys
- 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. In theory, once that feature is realized, only end-entity entries will be put on the blocklist and CA intermediate or root certs can simply be removed from the white-list.
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=` |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=` }}