So very, very many things to respond to... On Mon, Jun 02, 2025 at 04:58:14PM -0600, 'Ben Wilson' via [email protected] wrote: > There was broad concern that minor misalignments between a CA's > Certification Practice Statement (CPS) and its actual practices—when those > practices still comply with the Baseline Requirements (BRs)—can trigger > unnecessary and disruptive mass revocations.
Arguing that CAs shouldn't need to revoke misissued certificates (and a certificate that was issued in contravention of the CPS _is_ misissued) because mass revocations are "disruptive" is, in the _proper_ sense of the word, begging the question. Specifically, mass revocations should _not_ be disruptive, and in fact I would argue that it is _required_ by Mozilla policy to not be disruptive. > "A good faith, trivial error in somebody's CPS can require that 100% of > their certificates need to be revoked and replaced with certificates that > are identical in every way except for the not-before date." That is a gross mischaracterisation. Certificates are more than the bytes-on-the-wire. They're a representation of a specific set of validation practices, as of a particular point-in-time. Two certificates with identical representations, but issued under different validation practices, are _not identical_. > "We want to encourage transparency and process improvement, not discourage > accurate documentation by threatening revocation." Revocation shouldn't be a threat, and the fact that CAs appear to think it is a threat says a lot about how they're (un)able to handle the necessity of revocation. > Concerns: > > - This leads to “pointless mass revocations” when the only discrepancy > is outdated or incomplete documentation. Suggesting that outdated or incomplete documentation is somehow trivial, when a large part of a CA's entire purpose is to maintain accurate and up-to-date documentation, is concerning. > - Participants noted the perverse incentive to write vague CPS > documents to avoid being held accountable to overly specific details. > > "There's this kind of perverse incentive to never specify anything in your > documentation that's not in the requirements itself." Hopelessly vague documentation is a different problem, and speaks to the inadequacy of CPS vetting practices, and to a lesser extent auditing deficiencies. If a CPS does not contain sufficient information to allow a reasonably-competent third party to gain an accurate picture of a CA's practices (because this is a Certification _Practice_ Statement, after all), then it is not truly a CPS, and should be rejected until such time as it is brought "up to code". Similarly, an auditor that waves through a CPS that does not have sufficient detail to be able to be evaluated against actual practices is not performing their duties diligently. > Suggestions: > > - Consider creating a mechanism for corrective documentation updates > instead of mandatory revocation in such cases. Alternate suggestion: consider implementing change control practices that ensure that a CA is doing what it says it is doing. > - Possibly update section 4.9.1.1 of the BRs to allow for exceptions > where the error is trivial and does not affect certificate validity. Alternate suggestion: don't put things in your CPS that do not affect certificate validity. > 2. Clarifying Compliance Expectations and the Wiki > > HIGHLIGHTS: > > - Mozilla’s CA Wiki pages (especially "Forbidden and Problematic > Practices" and "Recommended Practices") were seen as important but in need > of frequent maintenance. > - New problematic practices should be added. As the name suggests, it's a wiki. Every participant of this call is, presumably, able to obtain an account and edit it. That the edit history of these pages does not show a wave of contributions from the non-Mozilla call participants, suggests that this is not a serious point of discussion, but is instead some species of red herring. > 3. Incident Reporting and Bugzilla Process > Participants discussed the need for CAs to consistently respond within 7 > days and to clearly answer all questions raised. However, ambiguity in > questions—especially from anonymous accounts—can create uncertainty about > what requires a formal response. There are no "anonymous accounts" in Bugzilla. There may be *pseudonymous* accounts, but that is not the same thing, and it is also irrelevant -- a good question is a good question, regardless of whether the CA can identify an entity to which they can send legal process. The impression I get from this sort of comment is that CAs want to know who is "important enough" to have to respond to, and who they can safely ignore. This impression is reinforced by the stark difference in responsiveness to, say, questions and comments from the chrome-root-program account, as opposed to individual members of the Mozilla community. This is disappointing, as the entire point of the Mozilla root program is that it is supposed to be _community driven_, which suggests that all members of that community should be equally valued, until such time as their behaviour indicates otherwise. > "Sometimes it's difficult to know when there are questions in a comment... > if there is a question, please isolate it and put a question mark at the > end." This would be a more plausible observation if there weren't CAs that ignored questions that were prefaced with "My question for <CA> is thus:". In reality, it's laughable that the excuse for not answering questions is "we didn't know it was a question!", when there are no shortage of unanswered clearly-a-question questions. > "Sometimes people think they've answered the question, but they haven't, or > the question wasn't clearly phrased as a question." And sometimes, it's absolutely, blatantly obvious to everyone that CAs are failing to answer the question, and attempts to claim otherwise are the most egregious form of gaslighting. > Best Practices for Asking and Responding to Questions > > There was consensus that using official CA accounts for incident response > would increase clarity and promote blameless, process-oriented discussion. I have seen no evidence that using official CA accounts is "increasing clarity". Mostly it seems to be a way to encourage bland platitudes and non-answers. I'd also like to highlight the hypocrisy of encouraging pseudonymity from CA representatives through the use of role accounts, whilst simultaneously decrying the use of pseudonymous accounts by the Mozilla community at large. The logical conclusion is that Mozilla community members should create a "friends-of-the-webpki" Bugzilla account, and ask all questions of CAs through that account. > - Not all questions are clearly marked as such. Questions that _are_ clearly marked as such are still ignored. Do we need to send a bevy of dancing clowns, holding signs saying "this is a question!" and gesturing to the relevant sentence? > - Unclear if questions are rhetorical, hypothetical, or require a > formal CA response. How about erring on the side of caution, and going with more communication rather than less? (Determining whether this is a rhetorical question is left as an exercise for the reader) > - Difficulty in determining which questions must be answered > (especially when raised by anonymous commenters). Everyone who asks a question in Bugzilla is a member of the Mozilla community, and as such is prima facie entitled to an answer. > Use of Incident Reports for Policy Development: Incident discussions can be > valuable for identifying insecure practices that are not explicitly covered > by existing rules. However, participants warned against letting these > discussions become unstructured fishing expeditions. >From the transcript, the only use of the phrase "fishing expedition" appears to come from the moderator. No participant appears to have used that phrase, and it's not obvious to me, at least, what prior comment by a participant was being characterised as a warning against such practices. Thus, I am extremely curious to hear more about these supposed activities that are so common as to apparently have multiple participants warning against them in deeply coded language. I don't recall seeing any particular rash of anything I'd describe as a "fishing expeditioy" in any of the issues I've looked into. > There was strong agreement that most CAs are already promoting automation > as much as they can, and that end-user barriers—not lack of effort from > CAs—are the primary challenge. Strong agreement from CAs, perhaps. I don't see how anyone outside a CA can have sufficient evidence to be able to support such a statement. > "We’ve poured ludicrous amounts of effort into promoting automation over > the last 5 years." That's a statement that could be read in at least two very different ways. > "People who say they have automation sometimes haven’t actually set it up > right—it gets revealed later." ... and? Stuff breaks all the time. You fix it and move on. > "We're expending hundreds of thousands of dollars to get fully automated, > but it's not easy for the last 0.4%." OK, what are the barriers -- and please, be specific -- to the adoption of automation of that last 0.4%? What approaches have been considered, and why were they rejected? What is the assessment of the costs and benefits to the various approaches? Absent such analysis, this reads as hyperbole. > "There is an overemphasis on ACME. It’s not a magic wand. We need to > broaden the conversation." I feel like this "it's not all ACME!" is either a red herring or evidence of some sort of delusional thinking. I don't recall seeing a mass of people advocating specifically and exclusively for ACME as the only solution to the entire certificate lifecycle. It is promoted widely, yes, because it is the first protocol I'm aware of to get such widespread acceptance and adoption, and to be able to be a "lingua franca" for certificate issuance. But just as the existence of a common language in the meatspace world hasn't led to the immediate elimination of all other languages, the existence of ACME does not imply the elimination of all other approaches to automating certificate issuance. > Some end users echoed that while they're supportive of automation and are > mostly automated, the remaining edge cases involve legacy systems or > security-sensitive environments where automation introduces risks. This reminds me of the old Yes, Prime Minister scene where all the ministers were broadly in support of hiring quotas for women, but there were reasons why their own department wasn't able to adopt such a quota, but in principle, certainly, it should be adopted as policy. > "Automation requires installation of software... and that increases the > attack surface." If a small shell script that makes HTTPS requests to a specific endpoint is a meaningful increase in attack surface, you've got much bigger problems. Anyone who has spent more than 10 minutes in infosec knows how the "ermahgerd securiteh!" argument is wielded regularly to stop anything that someone doesn't really want to do. I'll bet that a sizeable proportion of organisations that argue they can't automate certificate installation "because attack surface" has done all manner of insecure stuff, and management has accepted the risk, because it was deemed necessary for some executive's pet project. > - ACME isn’t suitable for all environments. That's a strawman big enough to be seen from space. > - The industry needs a broader definition and framework for automation. The problem isn't definitions and frameworks, it's willingness to actually invest in the changes required. > - There is a need to catalog and address real-world blockers to adoption. Since CAs are the only parties on the call that have access to the people who have knowledge of the real-world blockers to adoption, this work is entirely on them. I look forward to the detailed case-studies that are sure to be published Real Soon Now. > "If we want more automation, we need to stop talking about ACME and start > talking about other things." No, if you want more automation, you need to build more automation. The existence of ACME is not the reason that work isn't being done; the lack of willingness to do that work is the reason it isn't being done. > Root programs and CAs could: > > - Encourage subscribers to treat automation as lifecycle management, > not just certificate renewal. Waitaminute... CAs claim they "are already promoting automation as much as they can", but until this moment, it didn't occur to any of them to mention that automation might be more than just certificate renewal? > 7. Improving Community Engagement and Policy Development > > HIGHLIGHTS: > > - There was support for escalating appropriate issues to the Mozilla > dev-security-policy list or the CCADB public list. Given that the CCADB public list is invite-only, I do not support the use of that list for anything that is properly within the remit of the Mozilla trust store. > Recommendations: > > - If a Bugzilla discussion raises questions of precedent or future > policy, transition the conversation to the Mozilla > dev-security-policy list or CCADB Public. What has been stopping CAs from starting threads on mdsp that spin out of Bugzilla issues before now? - Matt -- 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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/beb390f1-58a6-4da3-8a51-d3822bc37fd4%40mtasv.net.
