> > This is an interesting point. ARI was first conceived > > <https://bugzilla.mozilla.org/show_bug.cgi?id=1619179#c7> as a way to > > improve business continuity across mass revocation events, and grew from > > there. The idea that 10-day certs might be a reality, and that revocation > > would be wholly optional for them, was almost unimaginable at that time. > > But even today, the reality is that CAs such as Let's Encrypt will likely > > have to support revocation for a very long time to come: migrating the > > whole world to 10-day certs will not happen overnight. So I think that this > > work is worthwhile, even if other solutions are also on the horizon. > > Yes, dealing with revocations is maybe the most important usecase for > ARI. > > Well, I don't think short-lived certs were unimaginable at the time. > Thought that CAs would not do those, yes.
The ARI post referenced here is only three years old. Short-lived certificates as an alternative to revocation was being actively and seriously discussed at the CA/Browser Forum around the time I started getting active, which was more like eight years ago (https://cabforum.org/2015/11/11/ballot-153-short-lived-certificates/). So it wasn't just imaginable, it was imagined. I wasn't at DigiCert at the time, but my boss was one of the leading advocates (https://www.digicert.com/blog/short-lived-certificates), and DigiCert has been issuing short-lived Certificates to organizations that want them for about that long. There Just isn't a lot of demand for them, for a variety of reasons, very few of which are technical or solvable by IETF. I'm really glad they're seriously being discussed again, and some progress Is being recently made towards clearing some of the barriers to adoption (https://cabforum.org/2023/07/14/ballot-sc-063-v4make-ocsp-optional-require-crls-and-incentivize-automation/). One remaining barrier is that Microsoft still requires revocation information for all certificates, regardless of lifetime. Getting that updated would be very helpful, but Microsoft policy moves slowly. I think they'll get there. Another technical barrier is the load impact on Certificate Transparency, if they became popular at scale. Some CT logs do not accept short-lived certificates today for that reason. That one also seems solvable to me, in fact I'd love to see some updates to CT to make it more efficient to log a "successor" certificate that only differs by issuance date and serial number. Or to be able to use the same SCT for an entire issuance chain, by requiring the first one to be logged, and then omitting the serial number and dates from the SCT comparison. Doesn't seem like it would be that challenging to figure out something that works. But most of the problem is that there isn't much incentive for customers to retrofit existing systems to use new, more modern certificate issuance and management techniques. I don't know how to fix that. If I did, there'd also probably be a lot less FORTRAN and COBOL out there. Getting all of the world's legacy systems updated is always a challenge. And we get to do that during the coming PQC era. Whee! At least maybe it is an opportunity to fix some of these things. -Tim _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
