Confirmed users
308
edits
Security/Features/Cert Blocklist via Update Ping: Difference between revisions
Jump to navigation
Jump to search
Security/Features/Cert Blocklist via Update Ping (view source)
Revision as of 23:36, 14 August 2012
, 14 August 2012no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{FeatureStatus | {{FeatureStatus | ||
|Feature name=Cert Blocklist via Update Ping | |Feature name=Cert Blocklist via Update Ping | ||
|Feature stage= | |Feature stage=Design | ||
|Feature status=In progress | |||
|Feature health=OK | |Feature health=OK | ||
}} | }} | ||
| Line 12: | Line 13: | ||
}} | }} | ||
{{FeaturePageBody | {{FeaturePageBody | ||
|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 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=CA | |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 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 ux design=There should not be any UX changes. | |||
}} | }} | ||
{{FeatureInfo | {{FeatureInfo | ||
| Line 20: | Line 35: | ||
|Feature roadmap=Security | |Feature roadmap=Security | ||
|Feature secondary roadmap=Platform | |Feature secondary roadmap=Platform | ||
|Feature engineering team= | |Feature engineering team=Security | ||
}} | }} | ||
{{FeatureTeamStatus}} | {{FeatureTeamStatus}} | ||