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]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[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.
