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/CADQzZqsR2TB7Aed1W-2O-OdA%2BZESOJYz8Uanq7mpvQy3cZTNiA%40mail.gmail.com.
