With Sectigo's encouragement, Apple recently opened the Bugzilla incident "Apple: CRLs for dormant CAs will not be populated in CCADB" (https://bugzilla.mozilla.org/show_bug.cgi?id=1793210). Mozilla closed this bug shortly thereafter on the rationale that it intends to make a change to its policy that will eliminate this issue as an incident and has communicated that intent to the public. This decision came despite the fact that on October 1 no such change had occurred, meaning that this behavior was still out of keeping with the stated requirements of Mozilla's official published policy.
We imagine that there are many other CAs who failed to meet the stated requirement in Mozilla's policy on October 1 of this year but that did not write up incidents, based at least in part on Mozilla's comment 4 on that thread and the decision to close the bug. DigiCert concurs with our evaluation in comment 2 on the same bug. We have been struggling with how to interpret this decision in a broader context for CAs and how we are to deal with the rules that root stores lay down for included roots and their providers. We find it deeply problematic that the stated intention to modify a requirement in the future would be treated identically to an actual published requirement. Opening the door to creative interpretation of unofficial statements from browser representatives as equivalent surrogates to the actual published requirements leaves subscribers, CAs, relying parties, and industry watchers unclear on exact expectations for the WebPKI. The core of the problem is that we have taken what ideally should be tight, well defined compliance rules and made them muddy and speculative. Traditionally, specified rules are captured in carefully worded published policies. They are subject to scrutiny by stakeholders, industry peers, and the general public. The owners of these policies regularly adjust them in response to direct feedback or if it becomes clear that the community is misunderstanding their intent. In principle this means these policies improve over time. Compare that to the inherent looseness of sidebar conversations about future intentions. These statements are deeply unlikely to carry the same level of detail as an official policy document. They do not undergo the same widespread scrutiny, don't endure the crucible of real-world use by scores of operating CAs, and don't improve iteratively over time. And perhaps of greater concern, there is no clear definition of which of these sidebar comments are meant to be taken as policy and which are not. When a browser representative makes a statement on m.d.s.p about a future intention, is that to be taken as a policy update? What if that same representative says the same thing in a private email to a single CA? To a non-CA? On a personal Twitter feed? In the hallway at the next CABF face-to-face? Are such sidebar communications to be interpreted as requirements by CAs, or are they optional for CAs to use or discard as they see fit? What if the CA doesn't see the sidebar communication in question? What if that CA isn't on the private email or wasn't standing in the right hallway at the right time? Of course, the major root programs could go through a carefully considered process of codifying exactly which of these sidebar communications should be considered policy and which should not, perhaps maintaining a list of sources that are considered surrogates for the official, published policy and then expecting CAs to follow them. Root programs would then have a set of known channels that were considered official communications, and they will know which are not. CAs would be able to unambiguously distinguish official from unofficial policy communications. The interested public would know which communications to scrutinize carefully as active policy and which to consider speculative and future looking. In Mozilla's case candidate repositories for the rules around sidebar communications could include the "Required or Recommended CA Practices" page at https://wiki.mozilla.org/CA/Required_or_Recommended_Practices or conceivably the "Forbidden or Problematic CA Practices" page at https://wiki.mozilla.org/CA/Required_or_Recommended_Practices. Other root programs would have to identify or create their own equivalents. Or on the other hand, we could use the existing root store policies for their intended purpose, which is to be the single, canonical place for all stakeholders and interested parties to find details of each root program's individual requirements of CAs. We are having trouble seeing the benefit of creating separate, parallel surrogates for published program policies. In this case it appears to be a matter of agility, with the time required to publish intended updates felt to be slower than desired. However, presumably there are reasons it takes time to make these updates. Publishing HTML in general is quick and easy, so we imagine it to be things like careful crafting, review, and buy-in that slow down the process. If these steps are still required for out-of-band policy updates, then the benefit to agility should be very small. If they are bypassed, then that raises a whole host of concerns about the accuracy, specificity, and longevity of any policy stated in such communication channels. Considering all the above, we cannot see how it makes sense for a root program to habituate CAs and the public at large to interpret anything other than the published policy document as an official source. We discourage Mozilla and all root programs from proclaiming and enforcing policy through channels other than their official, published policy documents. We ask the major root stores to reaffirm that their published policies are the sole source of enforced requirements and that other communications, while very helpful in educating the community and signaling important future directions, are not to be interpreted as official policy in their own right. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PH7PR17MB59305214C8CB2B5D9DD485FC863B9%40PH7PR17MB5930.namprd17.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
