4 ms·

The release note brought my attention to ARI: https://letsencrypt.org/2023/03/23/improving-resliiency-and-reliability-with-ari.html https://letsencrypt.org/2023

The release note brought my attention to ARI: https://letsencrypt.org/2023/03/23/improving-resliiency-and-reliability-with-ari.html https://letsencrypt.org/2023/03/23/improving-resliiency-and-... Is it just me, or is this a monumentally bad idea? Which is more likely - LE having to revoke certificates, or hacker figures out how to trigger the revocation mechanism? Or Congress passes a bill outlawing encryption that doesn't use a backdoor key, and LE is ordered to revoke hundreds of millions of keys? This is a hammer in search of a nail that doesn't really exist.

mholt 2y ago
I was one of the first to doubt ARI and thoroughly grilled it on the IETF mailing list: https://mailarchive.ietf.org/arch/msg/acme/AeJ3zJKcBF-ZUhQXJajC0bb7orI/ https://mailarchive.ietf.org/arch/msg/acme/AeJ3zJKcBF-ZUhQXJ... Now I'm warming up to it. But I still think I would have done it differently... ARI is essentially a "hint" to clients, but at the same time CAs can provide benefits (e.g. rate limit exemptions) if abiding by ARI windows. It feels weird to have scheduling split between the CA and the client. I would have liked a solution that either keeps the scheduling authority with the client, or transfers it to the CA, rather than straddling both. (I think my ideal scenario would be to have a single endpoint that returns a list of all certificates on the account that should be renewed presently. That way clients just have to poll it and renew any certs on that list. It would be much simpler than what I ended up implementing.) I am not actually concerned too much with ARI with respect to revocation or hackers or government coercion. Mainly complexity. Anyway... I could probably talk about the pros and cons of ARI for a while. It is a net good, I think, and it does solve a problem (mostly a problem CAs have, and it kind of puts the burden on clients). I just want the ACME/TLS ecosystem to settle down a little now. :)

mholt 2y ago

I was one of the first to doubt ARI and thoroughly grilled it on the IETF mailing list: https://mailarchive.ietf.org/arch/msg/acme/AeJ3zJKcBF-ZUhQXJajC0bb7orI/ https://mailarchive.ietf.org/arch/msg/acme/AeJ3zJKcBF-ZUhQXJ... Now I'm warming up to it. But I still think I would have done it differently... ARI is essentially a "hint" to clients, but at the same time CAs can provide benefits (e.g. rate limit exemptions) if abiding by ARI windows. It feels weird to have scheduling split between the CA and the client. I would have liked a solution that either keeps the scheduling authority with the client, or transfers it to the CA, rather than straddling both. (I think my ideal scenario would be to have a single endpoint that returns a list of all certificates on the account that should be renewed presently. That way clients just have to poll it and renew any certs on that list. It would be much simpler than what I ended up implementing.) I am not actually concerned too much with ARI with respect to revocation or hackers or government coercion. Mainly complexity. Anyway... I could probably talk about the pros and cons of ARI for a while. It is a net good, I think, and it does solve a problem (mostly a problem CAs have, and it kind of puts the burden on clients). I just want the ACME/TLS ecosystem to settle down a little now. :)