What are the issues you see from the perspective of a root program with the current framework?
On Wed, Jul 24, 2024 at 17:05 Ben Wilson <[email protected]> wrote: > Thanks, everyone, for keeping this conversation going. It's essential that > we continue because I believe the current framework is unworkable. > > Ben > > > On Wed, Jul 24, 2024 at 2:53 PM Mike Shaver <[email protected]> wrote: > >> On Wed, Jul 24, 2024 at 2:36 PM 'Ben Wilson' via >> [email protected] <[email protected]> wrote: >> >>> Personally, I currently favor extending the timeframe for the revocation >>> of certificates that have no security impact, >>> >> I propose, tongue only slightly in cheek, that if a component of the >> certificate doesn't have security impact, it be removed from the >> certificate specification in the BRs. TLS certificates are precious space, >> and reducing their size by eliminating things that have no use in security >> contexts >> >> Are there any specific examples of what deviations of certificates would >> be deemed so minor that they can stay live on the web for 20 days, but >> still worthy of revocation? With the number of CAs out there, and the rate >> of certificate issuance and error related there-to, it would be a virtual >> guarantee that there are a number of flavours of "slightly wrong" >> certificates active on the web. That means that everything needs to handle >> such certificates existing, in order to operate as part of the web PKI, so >> we should just capture in the standard that this alternative shape is OK >> and let everyone issue in that expanded envelope all the time. Presumably >> the web would benefit from this in some way, if the CABF would entertain >> such changes, but I confess that I can't tell what that benefit is. >> >> Similarly, I might ask: how much of a grace period should Firefox give >> for accepting a certificate after it has expired? I mean, what's 20 days? >> It expired naturally, after all... >> >> More seriously, I don't think that we are generally in a position to be >> certain that no system exists which depends on a certain property of a >> certificate. Is there something out there that is gating access or acting >> differently on the basis of a case-sensitive country code match? If there >> is, the designers certainly weren't wrong to build it that way, IMO. The >> BRs are a commitment to the world that web PKI certificates will behave a >> certain way, and laxity on making sure that certificates actually do >> conform will mean that effectively the BRs are no longer really true or >> useful for their purpose. >> >> In addition to whatever subjective assessment a CA might make (hardly as >> a disinterested party, I hasten to add) about the security implications of >> a given certificate's deviation from, there is also the concern of >> interoperability. A new entrant to the web (such as a browser like >> Ladybird, or a CA like the next Let's Encrypt, or some future CDN >> Fastflare) will need to not only implement to meet and handle the >> *specified* certificate forms and behaviours, but also somehow know about >> all the kinds of variants that are likely to be floating around at any >> given time. Mozilla and Firefox know first-hand and extensively what a >> barrier it can be when the standard says that things should be one way, but >> other parties produce or expect something different. >> >> Finally, conformance to the standards and correct issuance is just not >> that hard, as regards the things that have been argued to be "too minor to >> revoke in 5 days". They would virtually all have been caught by decent >> linting. I don't see how it helps the web to make these cases easier for >> CAs to handle. It seems only that it would benefit CAs who routinely >> misissue sloppy certificates in "minor" ways. If they can't get these >> little things right, how can we trust their key material management or >> background checks or entropy sources? It's not like we're seeing the raw >> audit reports, even though they are really for the benefit of the root >> programs. >> >> Maybe the job of being a CA is too hard for some organizations that are >> doing it now. That's OK. The Web doesn't need all of the CAs we have today >> as much as it needs CAs that help move the integrity of web PKI *forward*, >> rather than weakening it a little bit at a time for their convenience when >> they have failed to meet their commitments. >> >> Mike >> >> -- 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/CAOG%3DJUL3-ZokN8cSWw4pixP%3DRVeDOLFP4pF-cv_%3DjSF_ce_rNw%40mail.gmail.com.
