To expand: You would like to request removal and then it be treated as if you’re already removed, correct?
I think for the reasons Wayne outlined, that would be detrimental to the ecosystem as a whole. For example, the request for removal might actually be denied (!!!) because of the outsize impact it could have on Mozilla Firefox/NSS users. 1) Mozilla blocks the roots via OneCRL, disrupting all existing whitelisted certificates. I’m sure Apple would be very displeased by this. 2) Mozilla removes the roots in a future update. This takes time to develop, release, and distribute - and during that time, clients with the ongoing trust (including ESR versions) would be impacted. It also suffers the Apple problem (for impact), which would need to be addressed. 3) Mozilla acknowledges the request but doesn’t take steps to remove - this has all the current downsides, but without any expectations of DigiCert abiding by the program requirements. For that reason, the best answer would seem to be that if DigiCert were to make that request, Mozilla would deny it, so that DigiCert would be clear as to the continued expectation to abide by the program requirements, until such a time as a workable solution was identified, reviewed, developed and implemented, and shipped. Of course, that no doubt sounds a bit odd, so if denying wasn’t an option - that is, if it had to be treated like a compromised root with an emergency update of some form - then it seems the answer should also be to treat the organization as one that can’t control their root, and treat it like an emergency update. These are all example responses to your specific request, and a light exploration about some of the consequences. I have no doubt that, as a CA, it’d be preferable to know exactly what would or could happen in these root removal requests. I don’t believe the SHA-1 process for those was at all beneficial for the community, and it had seemed like CAs had recognized that and would be unlikely to do it again. If we think this is something to formalize, then approaches like Microsoft’s - which contractually forbid it, add timelines for processing, and set expectations for ongoing audits for years after the “removal” in order to protect users, is a better model. In the context of Mozilla, which lacks such a contractual lever in its policy, I would suggest an approach that treats such requests as: 1) Best effort to remove individual roots, with an expectation that audits will continue until it is “safe” to stop and all policy obligations met 2) If the above is breached/violated, then treat it as removing all of that organizations and affiliates roots (that is, treating it like organization compromise) Hopefully, given the reasons above, that seems like an eminently reasonable policy position to take. Deliberately introducing issues like that merely externalizes the risks, and so there needs to be appropriate balances - whether contractual, financial, or political - to offset those externalized costs. Similarly, allowing such actions makes the inclusion of a root that much more dangerous, and thus gives further incentive to deny organizations that have demonstrated such patterns future roots, given the risks. On Thu, Dec 13, 2018 at 5:15 PM Jeremy Rowley via dev-security-policy < [email protected]> wrote: > Can we request removal of these roots now? This seems very similar to the > SHA1 situation where CAs requested root removal and then treated the root > as > private, regardless of the trust in older platforms. > > -----Original Message----- > From: dev-security-policy <[email protected]> > On > Behalf Of Wayne Thayer via dev-security-policy > Sent: Thursday, December 13, 2018 3:11 PM > To: mozilla-dev-security-policy > <[email protected]> > Subject: Re: Underscore characters and DigiCert > > There are currently no program requirements for roots that have had their > websites trust bit turned off or been removed from NSS, but this is an open > area of concern [1]. When a root is disabled or removed, there is no > protection for Firefox users who haven't updated to a current version, nor > for any of the other consumers of our root store until they update. > > However, that doesn't apply here. These roots are still in the Mozilla root > store and trusted for TLS, and some of them will be for quite a while due > to > the whitelisted Apple & Google intermediates [2]. It is clear that Mozilla > policy, and in-turn the BRs, still apply to these roots. > > Should DigiCert decide not to revoke certificates containing underscores by > the 15-Jan deadline in SC12, including those chaining to distrusted > Symantec > roots, I plan to treat it as an incident. As with any incident, full > disclosure is the expectation. > > - Wayne > > [1] https://github.com/mozilla/pkipolicy/issues/124 > [2] https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec > > On Wed, Dec 12, 2018 at 5:54 PM Jeremy Rowley via dev-security-policy < > [email protected]> wrote: > > > Hey all, > > > > We're working towards revoking certs with underscore characters in the > > domain name, per SC12, but I had a question about legacy Symantec > > systems and Mozilla. These particular roots are no longer trusted for > > TLS certs in Google or Mozilla, which means the applicability of the > > BRs is dubious. The roots are shortly being removed from Microsoft and > > Apple, although that's more of an FYI rather than something with > > direct bearing on the Mozilla community. If the roots are no longer > > trusted for TLS in Mozilla, is there any requirement to revoke the certs > issued under those roots? > > > > > > > > My initial thought is no as this is similar to what Comodo did with > > their request to remove a SHA1 root (and what DigiCert did with one of > > the Verizon roots). Note these are still flagged by zlint because they > > are trusted in older systems. Because the situation is slightly > > different with the way distrust was technically implemented, I wanted > > to see if there were any concerns with the community about treating > > these as private going forward, similar to the SHA1 roots. Thoughts? > > > > > > > > Jeremy > > > > > _______________________________________________ > 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 > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
