We can’t know what problems misissued certificates caused or will cause in the future, specifically. The BRs are a commitment to the participants of the web that they can rely on certain properties of TLS server certificates. They might not even know that they (or a customer or a customer’s customer) operated a system that misbehaved because it was relying on a field in a certificate, or a property of the CPS, which was not correctly handled. X.509 itself is a pretty complex protocol space, and it’s very likely that people are building systems that only handle a pretty narrow subset that the developers see from BRs, RFCs, and sampling the web.
TLS certificate fields are expensive, and in a way that IMO is much more important than CAs having to scale up their kube pods and deal with the economics of that. They have to be exchanged trillions of times a day over the internet. If the country code in a field doesn’t matter such that it’s OK to have certs with the wrong ones floating around the web, and adding more branches to all code that handles it (and that computational cost, if we’re doing energy math), then we should just *remove it from the certs*. Everyone wins: the handshakes get smaller, the specs get smaller, people don’t have to guess if a given part of the cert was deemed important enough to get right, and CAs don’t have to pay close attention to things and actually lint stuff effectively. Everything in a TLS certificate needs to carry its weight. As far as dealing with deceptive use of certs/domain names/site appearance, as a founding board member of StopBadware I certainly agree that it is an area that is useful to consider, but I think well apart from the scope of CCADB/CABF/root programs. TLS certificates are approximately universal now, and conflating “you can trust the connection” with “you can trust the party on the other end” is in my opinion a pretty bad direction to go in. The industry tried with EV (and I regret supporting it), and I think we’ve collectively learned that connection-level protocol elements are not a good basis for making that sort of trust decision. Mike On Mon, Aug 12, 2024 at 5:08 AM Roman Fischer <[email protected]> wrote: > Dear Matthew, > > > > Every halfing of certificate lifetime doubles the load on the CA's. This > has impact on cost, energy, number of systems… of course that's purely > technical and manageable but going from the current 1 year to 1 day would > mean two orders of magnitude increase. > > > > I'm not sure if this energy and effort is well invested in this place. How > much damages did subscribers or end-customers have due to mis-issued > certificates? Would it maybe not be better to tackle the problem of (valid) > certificates for malicious purposes? > > > > Kind regards > Roman > > > > *From:* [email protected] <[email protected]> *On > Behalf Of *Matthew Hardeman > *Sent:* Freitag, 9. August 2024 20:19 > *To:* [email protected] > *Subject:* Re: Feasibility of a binding commitment to revoke before > issuance > > > > While policy proposals are being discussed, I'd like to take a step back > and offer up a different perspective: > > > > If we accept that timely execution of revocation is an essential and > non-optional function of the WebPKI and that all subscriber parties in the > WebPKI must be prepared to either sacrifice some availability or in the > alternative be prepared to rotate to a new certificate in 24 hours -- at > the outside -- then, I would submit, it's time to approach the matter quite > differently. > > > > Post-issuance certificate lifecycle management is a disaster and it always > has been and no one has put forth good evidence that it will ever improve > -- particularly if we continue to indulge certain constraints imposed by > relying parties and subscribers. > > > > OCSP generally is a privacy problem and OCSP stapling has limited uptake > in the very same systems which are less certificate rotation agile. It's > also a costly post-issuance burden, the value has not been well > demonstrated. CRLs have other but significant problems. > > > > One solution is right in front of us: Short Lived Certificates. > > > > The WebPKI as represented in modern browsers' CA programs' policies should > set forth that either automated rotation by the server-side software stack, > mechanical rotation by external automation, or the introduction of > reverse-proxy elements which provide WebPKI friendly relying-party-facing > interfaces are required elements of offering a reliable WebPKI enabled > service for consumption in modern web clients. At which point it becomes > relatively trivial to move toward a world with 1 week, 48 hour, and 24 hour > certificate validity periods. Once we get it down to 24 hour certificate > validity, there is simply no point to further effort on revocation and > revocation effectiveness. > > > > The operational simplicity from the CA side should appeal from a cost > control basis -- administrative labor related to receiving & processing > revocation requests, mass revocation, etc, are eliminated. Compliance > issues become a pause issuance and fix move-forward issuance. Commercial > opportunities arise in client infrastructure certificate deployment > management software solutions and consulting. > > > > A humble enterprise rp & subscriber, > > > > Matthew Hardeman > > -- > 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/CAPAx59G%3D%2BXDKiakyk81WvCKarSUzkX-G3uZX0a3%3DFJTWnQgR-Q%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPAx59G%3D%2BXDKiakyk81WvCKarSUzkX-G3uZX0a3%3DFJTWnQgR-Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > 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/ZR0P278MB0170989FD2AE333B2690492EFA852%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB0170989FD2AE333B2690492EFA852%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer> > . > -- 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/CADQzZquvk7%3Dvc1j29N5t3w85Ad_iKOYxNVJ%2BrgUOv%2BURcU%2BUWQ%40mail.gmail.com.
