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/CA%2B1gtaYACVE_sN_OdvczL_MKTX-sVE8PyFEhxfCoPRxi7CG04g%40mail.gmail.com.
