I also don't think removing these roots is a good solution because: * To Ryan's point, it's too late to actually get them removed on Mozilla's current release cycle. * Again echoing Ryan's comments, there are a lot of consumers of NSS and abruptly yanking these roots to work around the ballot SC12 requirement could be very disruptive, even if it doesn't affect Firefox. We might not approve the request, or at least not quickly enough to meet the goal. * As I understand it, this workaround wouldn't help all DigiCert customers who are having trouble meeting the SC12 deadline. While the numbers would be smaller, DigiCert would still be dealing with an incident (I disagree with Ryan's comments in another thread that each customer for whom revocation is delayed constitutes a separate incident).
- Wayne On Thu, Dec 13, 2018 at 4:16 PM Ryan Sleevi <r...@sleevi.com> wrote: > 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 < > dev-security-policy@lists.mozilla.org> 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 <dev-security-policy-boun...@lists.mozilla.org> >> On >> Behalf Of Wayne Thayer via dev-security-policy >> Sent: Thursday, December 13, 2018 3:11 PM >> To: mozilla-dev-security-policy >> <mozilla-dev-security-pol...@lists.mozilla.org> >> 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 < >> dev-security-policy@lists.mozilla.org> 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 >> 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
