CNNIC just released a "declaration" concerning Google's recent update:
http://www1.cnnic.cn/AU/MediaC/Announcement/201504/t20150402_52049.htm "1. The decision that Google has made is unacceptable and unintelligible to CNNIC, and meanwhile CNNIC sincerely urge that Google would take users’ rights and interests into full consideration. 2. For the users that CNNIC has already issued the certificates to, we guarantee that your lawful rights and interests will not be affected. China Internet Network Information Center（CNNIC） April 2nd, 2015" On Wed, Apr 1, 2015 at 7:19 PM, Richard Barnes <rbar...@mozilla.com> wrote: > On Wed, Apr 1, 2015 at 6:44 PM, Matt Palmer <mpal...@hezmatt.org> 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 > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
