On Wed, Apr 1, 2015 at 6:44 PM, Matt Palmer <[email protected]> wrote:
> On Wed, Apr 01, 2015 at 01:35:25PM -0400, Richard Barnes wrote: > > Alright, one more pass at this. After more feedback from this list > > (thanks, all!) and some more conversation, I would like to propose > > something stronger than my last proposal: > > > > * Do not remove the CNNIC root, but > > * Reject certificates chaining to CNNIC with a notBefore date after a > > threshold date*.* > > * Request that CNNIC provide a list of currently valid certificates, and > > publish that list so that the community can recognize any back-dated > certs > > * Allow CNNIC to re-apply for full inclusion, with some additional > > requirements (to be discussed on this list) > > * If CNNIC's re-application is unsuccessful, then their root > certificates w > > ill be removed > > > > This corresponds roughly to option (E) that Peter Bowen raised, and > > combines the E1 and E2 options noted by Ryan. I do not anticipate that > we > > would make software changes to enforce a whitelist, but instead would > rely > > on CNNIC not back-dating certificates, with the published list usable as > > a check for any certificates that the community finds (in the spirit of > > CT). > > I have no objections to this plan as such, and if all goes according to > plan, I believe it will remove CNNIC from the trust store without > inconveniencing those end entities who relied on CNNIC. > > I'd like to see discussion of what happens if things *don't* go according > to > plan, though. The plan relies quite a bit on CNNIC's cooperation, both to > provide the list of existing certificates, as well as making (and abiding > by) the undertaking not to issue further certificates chaining to their > existing trusted roots. I think it would be beneficial to have a solid > idea > of what should be done if CNNIC doesn't cooperate: > > 1) If they refuse to provide a list of currently issued certificates; > > 2) If they refuse to cease issuing certificates chained to the existing > trusted roots; > > 3) If they contravene the undertaking to cease issuing certificates chained > to the existing trusted roots. > Given what's in Google's blog post (thanks, Reed), there will apparently be a public whitelist of certificates whether CNNIC cooperates with Mozilla or not. So (1) is not an issue. (2) and (3) are only an issue if they issue certificates that are back-dated to before the threshold date. That seems like an active misrepresentation, which would likely be considered sufficient grounds for removal anyway. I would suggest that we focus on agreeing on the principle that existing certificates will continue to be accepted. We can look at a couple of alternatives for implementing this policy. It may be that a whitelist approach will be feasible to implement, which has none of the issues you note. --Richard > My "off the top of my head" reaction to any or all of these events would be > immediate removal of the roots from the trust store, but if that is a > suitable response to CNNIC's inability to abide by Mozilla's additional > rules, I have to wonder why it isn't a suitable response to CNNIC's > inability to abide by Mozilla's *original* set of rules. > > A slightly adjusted plan, that doesn't require any actual cooperation from > CNNIC, could be as follows: > > * Do not remove the CNNIC root, but > * Reject certificates chaining to CNNIC with a notBefore date after a > threshold date > * Publish a list of all known CNNIC end-entity and intermediate > certificates > (based on CT log and TLS census data) > * Invite CNNIC to enumerate any other certificates which they would like to > add to the list > * Advise CNNIC that if any *other* certificates are discovered, the CNNIC > root certificates will be *immediately* removed from NSS, without any > further discussion or appeal > * Allow CNNIC to re-apply for inclusion, etc etc > > The advantage of this plan is that it doesn't require CNNIC's cooperation > at > any point, and it leaves no room for doubt about what the consequences are > for deviation from the plan. On the other hand, others may disagree with > the consequences I've enumerated, or feel that it is too heavy handed -- > which I can appreciate, and would be happy to discuss. > > - Matt > > -- > "You could wire up a dead rat to a DIMM socket and the PC BIOS memory test > would pass it just fine." > -- Ethan Benson > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
