Ben, I can totally appreciate the viewpoint of "The language was confusing", but I don't think that's an appropriate or wholesome response to DigiCert here, given the surrounding evidence. That is, as captured in [Issue 147](https://github.com/mozilla/pkipolicy/issues/147), this started off as an attempt to clarify existing requirement and expectation. In general, these clarifications are done because they reflect long-standing practice and expectation, but for new CAs, without a history of following activity in the Forum or Mozilla, they might be confused. However, I don't think that generous interpretation applies to DigiCert. In this case, DigiCert's interpretation of policy appears to stretch belief, and is best akin to when Trustwave issued a MITM certificate, and Mozilla [had to remind CAs](https://wiki.mozilla.org/CA/Communications#February_2012) that no, validating domain names actually means validating domain names, and you can't issue MITM certificates. Yet even with that, it was and is still seen as potentially necessary to ["clarify" that MITM isn't permitted](https://github.com/mozilla/pkipolicy/issues/209). Ultimately, audits are for Mozilla and the community. If an audit doesn't provide sufficient assurance, Mozilla can and should request clarification. There's nothing incepient in Mozilla policy that dictates all audits should be accepted, much like the tremendous work Kathleen places in verifying auditor qualifications. The question Mozilla should ask, which is the same question that anyone looking at this should ask, is "Do I have enough information to trust DigiCert" and "Should I be concerned DigiCert reached this conclusion, given the available information?". Similarly, Mozilla specifically should also take into consideration "What are the implications for incidents, going forward, for all CAs"? Let's consider the facts: * Mozilla has repeatedly emphasized that policy (and audits) on the basis of "technical capability", not intent. * [February 2012 CA communications](https://wiki.mozilla.org/CA/Communications#February_2012) * [In Mozilla Root Policy 2.4.1](https://github.com/mozilla/pkipolicy/issues/27) * [Jan 2020 CA Communication](https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00090,Q00096,Q00091) * Mozilla has consistently applied that standard to other CAs * [Asseco DS/Certum](https://bugzilla.mozilla.org/show_bug.cgi?id=1598277) * "There are no valid end-entity certificates issued by these certificates we did not include them in audit scope", similar to what DigiCert is asserting here. * [Buypass](https://bugzilla.mozilla.org/show_bug.cgi?id=1595113) * [Firmaprofesional](https://bugzilla.mozilla.org/show_bug.cgi?id=1586115) * [GRCA](https://bugzilla.mozilla.org/show_bug.cgi?id=1614448) * [Identrust](https://bugzilla.mozilla.org/show_bug.cgi?id=1588213) * [Izenpe](https://bugzilla.mozilla.org/show_bug.cgi?id=1596744) * [PKIoverheid](https://bugzilla.mozilla.org/show_bug.cgi?id=1586125) * [SECOM](https://bugzilla.mozilla.org/show_bug.cgi?id=1563574) * And I'm sure more, that's just a quick scan * DigiCert specifically has had repeat issues with improper disclosures * Bug 1455150 * Bug 1358176 * Bug 1417771 * Bug 1451950 * Bug 1563573 * Bug 1575125 I can understand wanting to take the policy on its own, and if DigiCert were a new CA applying for trust, I think there'd be no issue with saying "No, sorry, try again, and we'll clarify that", because it'd not be appropriate to take on the risk, even if it was a benign mistake. However, this is not a benign mistake, with DigiCert as a large (if not the largest) CA in Mozilla's program. Given the pattern of systemic issues, what might be a reasonable interpretation by a neophyte doesn't really hold up when examined through the lens of a mature, established CA that continues to violate expectations. In the history of Mozilla, has there ever been an audit or communication where it's been communicated that intent, rather than capability, matter? If it does not matter for the BRs, if it does not matter for S/MIME, is it reasonable to conclude that somehow EV is exempt from this? And how does that assumption square with issues like [the Apple issue](https://bugzilla.mozilla.org/show_bug.cgi?id=1575125) where DigiCert recognized the need for audits of their sub-CAs to include the full scope? So I think we can throw out "reasonable" as, well, being unreasonable. So the question is one of "What's appropriate". It seems that you might be viewing this lens as "Revoke or do nothing" as the only options, and while revocation would entirely be consistent with Mozilla's policy, I can understand that in this **exceptional** circumstance, which would and should never be repeated by another CA, Mozilla might see revocation as disruptive. I'd question what evidence we have of that, since it seems such a conclusion should be supported by hard data, if the goal is objectivity, but I also think it overlooks other options. DigiCert has already been placed on remedial audit schedules in the past, in relation to the Symantec acquisition, and we saw that DigiCert exhibited a worrying trend of "moving quickly and breaking things"; that is, a number of troublesome issues in their development and integration that could and should have been avoided were, ultimately, revealed through the more regular audits. However, although there's considerable value, especially for DigiCert, in regular remedial audits, I don't think they're as applicable here. Another alternative is, highlighting DigiCert's routine control failures, both directly and through their integrated acquisitions (e.g. most recently, QuoVadis, and the repeat violations that have occurred since DigiCert's acquisition), is to require DigiCert provide a more detailed report. Using the Webtrust provided detailed control report, better explanations about the system design and the **human processes** involved at DigiCert, and how these processes are examined, seems relevant precisely to this repeat failure. The fact that DigiCert has had so many issues with their ceremonies, which are heavily scripted and provide many opportunities for human review and fail-safes, suggests that there's a culture at DigiCert that may not be attentive to the requirements involved in being a CA. Yet another alternative is to require Digicert obtain new and appropriate audit reports, were they appropriately audited. Of course, any challenges with that, either on performance or accepted, reveal yet another option: the removal of EV status from DigiCert, and the required establishment of a new, clean, appropriately audited EV hierarchy. At the core, I think the conclusion here, about whether or not "it was reasonable for DigiCert to believe it did not have to include certain CAs in scope", is something not supported by the ample record, both with DigiCert and within the broader set of CA incidents. If Mozilla ignores the discussions on m.d.s.p., ignores the discussions with other CAs, ignores the discussions in the CA/B Forum, and only takes the policy, and any interpretations, in isolation, which is what appears to be proposed here, then it seems there is ample room for mischief and mayhem, and Mozilla will constantly be in a reactionary mode against bad-faith interpretations of its policy. I can't help but feel that the conclusion, about whether or not this is right or expected, is being predisposed by an assumption that, if Mozilla says no, it is the effect of expecting or demanding revocation. I hope I showed that isn't the case, and that Mozilla has a wide array of options at its disposition to ensure that Mozilla, and the community that relies on Mozilla, has justified faith in DigiCert's operations.
Bug 1650910 Comment 30 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Ben, I can totally appreciate the viewpoint of "The language was confusing", but I don't think that's an appropriate or wholesome response to DigiCert here, given the surrounding evidence. That is, as captured in [Issue 147](https://github.com/mozilla/pkipolicy/issues/147), this started off as an attempt to clarify existing requirement and expectation. In general, these clarifications are done because they reflect long-standing practice and expectation, but for new CAs, without a history of following activity in the Forum or Mozilla, they might be confused. However, I don't think that generous interpretation applies to DigiCert. In this case, DigiCert's interpretation of policy appears to stretch belief, and is best akin to when Trustwave issued a MITM certificate, and Mozilla [had to remind CAs](https://wiki.mozilla.org/CA/Communications#February_2012) that no, validating domain names actually means validating domain names, and you can't issue MITM certificates. Yet even with that, it was and is still seen as potentially necessary to ["clarify" that MITM isn't permitted](https://github.com/mozilla/pkipolicy/issues/209). Ultimately, audits are for Mozilla and the community. If an audit doesn't provide sufficient assurance, Mozilla can and should request clarification. There's nothing incepient in Mozilla policy that dictates all audits should be accepted, much like the tremendous work Kathleen places in verifying auditor qualifications. The question Mozilla should ask, which is the same question that anyone looking at this should ask, is "Do I have enough information to trust DigiCert" and "Should I be concerned DigiCert reached this conclusion, given the available information?". Similarly, Mozilla specifically should also take into consideration "What are the implications for incidents, going forward, for all CAs"? Let's consider the facts: * Mozilla has repeatedly emphasized that policy (and audits) on the basis of "technical capability", not intent. * [February 2012 CA communications](https://wiki.mozilla.org/CA/Communications#February_2012) * [In Mozilla Root Policy 2.4.1](https://github.com/mozilla/pkipolicy/issues/27) * [Jan 2020 CA Communication](https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003waNOW&QuestionId=Q00090,Q00096,Q00091) * [On m.d.s.p.](https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg12259.html) * Mozilla has consistently applied that standard to other CAs * [Asseco DS/Certum](https://bugzilla.mozilla.org/show_bug.cgi?id=1598277) * "There are no valid end-entity certificates issued by these certificates we did not include them in audit scope", similar to what DigiCert is asserting here. * [Buypass](https://bugzilla.mozilla.org/show_bug.cgi?id=1595113) * [Firmaprofesional](https://bugzilla.mozilla.org/show_bug.cgi?id=1586115) * [GRCA](https://bugzilla.mozilla.org/show_bug.cgi?id=1614448) * [Identrust](https://bugzilla.mozilla.org/show_bug.cgi?id=1588213) * [Izenpe](https://bugzilla.mozilla.org/show_bug.cgi?id=1596744) * [PKIoverheid](https://bugzilla.mozilla.org/show_bug.cgi?id=1586125) * [SECOM](https://bugzilla.mozilla.org/show_bug.cgi?id=1563574) * And I'm sure more, that's just a quick scan * DigiCert specifically has had repeat issues with improper disclosures * Bug 1455150 * Bug 1358176 * Bug 1417771 * Bug 1451950 * Bug 1563573 * Bug 1575125 * [DigiCert's own confusion](https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg12270.html) regarding this specific page was [previously addressed](https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg12280.html) to try and help make them aware, which they at least were and had the opportunity to request further policy clarification **at any time** I can understand wanting to take the policy on its own, and if DigiCert were a new CA applying for trust, I think there'd be no issue with saying "No, sorry, try again, and we'll clarify that", because it'd not be appropriate to take on the risk, even if it was a benign mistake. However, this is not a benign mistake, with DigiCert as a large (if not the largest) CA in Mozilla's program. Given the pattern of systemic issues, what might be a reasonable interpretation by a neophyte doesn't really hold up when examined through the lens of a mature, established CA that continues to violate expectations. In the history of Mozilla, has there ever been an audit or communication where it's been communicated that intent, rather than capability, matter? If it does not matter for the BRs, if it does not matter for S/MIME, is it reasonable to conclude that somehow EV is exempt from this? And how does that assumption square with issues like [the Apple issue](https://bugzilla.mozilla.org/show_bug.cgi?id=1575125) where DigiCert recognized the need for audits of their sub-CAs to include the full scope? So I think we can throw out "reasonable" as, well, being unreasonable. So the question is one of "What's appropriate". It seems that you might be viewing this lens as "Revoke or do nothing" as the only options, and while revocation would entirely be consistent with Mozilla's policy, I can understand that in this **exceptional** circumstance, which would and should never be repeated by another CA, Mozilla might see revocation as disruptive. I'd question what evidence we have of that, since it seems such a conclusion should be supported by hard data, if the goal is objectivity, but I also think it overlooks other options. DigiCert has already been placed on remedial audit schedules in the past, in relation to the Symantec acquisition, and we saw that DigiCert exhibited a worrying trend of "moving quickly and breaking things"; that is, a number of troublesome issues in their development and integration that could and should have been avoided were, ultimately, revealed through the more regular audits. However, although there's considerable value, especially for DigiCert, in regular remedial audits, I don't think they're as applicable here. Another alternative is, highlighting DigiCert's routine control failures, both directly and through their integrated acquisitions (e.g. most recently, QuoVadis, and the repeat violations that have occurred since DigiCert's acquisition), is to require DigiCert provide a more detailed report. Using the Webtrust provided detailed control report, better explanations about the system design and the **human processes** involved at DigiCert, and how these processes are examined, seems relevant precisely to this repeat failure. The fact that DigiCert has had so many issues with their ceremonies, which are heavily scripted and provide many opportunities for human review and fail-safes, suggests that there's a culture at DigiCert that may not be attentive to the requirements involved in being a CA. Yet another alternative is to require Digicert obtain new and appropriate audit reports, were they appropriately audited. Of course, any challenges with that, either on performance or accepted, reveal yet another option: the removal of EV status from DigiCert, and the required establishment of a new, clean, appropriately audited EV hierarchy. At the core, I think the conclusion here, about whether or not "it was reasonable for DigiCert to believe it did not have to include certain CAs in scope", is something not supported by the ample record, both with DigiCert and within the broader set of CA incidents. If Mozilla ignores the discussions on m.d.s.p., ignores the discussions with other CAs, ignores the discussions in the CA/B Forum, and only takes the policy, and any interpretations, in isolation, which is what appears to be proposed here, then it seems there is ample room for mischief and mayhem, and Mozilla will constantly be in a reactionary mode against bad-faith interpretations of its policy. I can't help but feel that the conclusion, about whether or not this is right or expected, is being predisposed by an assumption that, if Mozilla says no, it is the effect of expecting or demanding revocation. I hope I showed that isn't the case, and that Mozilla has a wide array of options at its disposition to ensure that Mozilla, and the community that relies on Mozilla, has justified faith in DigiCert's operations.