The CCADB Steering Committee has opened a new forum for public trust matters that affect Certificate Consumers in general rather than just Mozilla specifically. As we just barely opened this thread and it hasn’t really had a chance to get going yet, we suggest holding back on commentary and dialog for this thread. We will give the new forum a few days to be ready for active discussion, and then we will start a thread there to replace this thread.
Then everyone will have a chance to get into commentary on Sectigo’s points and requests in the going-forward forum. On Friday, November 4, 2022 at 11:21:39 AM UTC-4 [email protected] wrote: > 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/e89a5757-45cd-4648-8f99-7b2c83d608cfn%40mozilla.org.
