So, seeing that the recent incident utilized updating ARI to tell affected people to renew prematurely, even though I wasn't affected it inspired me to take some time this weekend and finally play around with getting the data.
At this point all I did was make a script to try to get the information; I haven't worked on integrating it into my weird custom workflow or anything yet. So here are a few random thoughts from first trying to see how to implement it.
I can only imagine that it's specified the way it is to make it easier for Let's Encrypt (and other CAs presumably) to reutilize some portion of what they already do for OCSP, since I can't imagine it makes it easier on any client authors. Though perhaps there are clients that already check OCSP that can pull out the CertID easily enough (maybe OpenSSL or some other common popular library gives it out of the box, I don't know, I just know that the framework I was using doesn't). I did get it working eventually, though (and got to learn a lot more about ASN.1 in the process).
Second: The spec says that "The full request URL is computed by concatenating the renewalInfo URL from the server's directory with a forward slash and the base64url-encoded bytes of a DER-encoded CertID…"
renewalInfoUrl + '/' + encodedCertId. However, the actual directory entry in the Let's Encrypt directory (both staging and production) already ends in a slash. So I think that by the spec there should an additional slash added to the end, like
https://acme-staging-v02.api.letsencrypt.org/draft-ietf-acme-ari-01/renewalInfo//MGgwDQYJYIZ… with two slashes between the
renewalInfo and the abomination of a path I needed to construct. Though in fact it works without the extra slash in there as well. I think in this case the spec is probably right and the Let's Encrypt directory should be updated to remove the slash at the end, matching how the other entries in the directory generally don't have one either.
So there's none of the usual ACME nonces and signing and such, which certainly makes things easier, especially if one is trying to run some process outside of one's regular ACME client to just keep an eye on needing to renew early due to an incident. All the information needed to look up the renewal info for someone's certificate is in the public certificate transparency logs, and the spec specifically says that anyone can look up anybody's information "because the information contained in renewalInfo resources is not considered confidential". I wonder though, if it could be used to tell people whether someone else's certificate was affected by an incident. Usually this wouldn't be a huge deal, I agree, but it potentially exposes what validation method a system uses or the like. That is, if an incident happens that affects all users in subset X, anyone can then check whether anybody's site is in that subset X. And if that subset is based on running a particular vulnerable web server or ACME client, that might expose information to an attacker that the subscriber might prefer not be exposed so easily.
I'm not really objecting, or saying that anything should necessarily change, just that if it turns out that there's some incident along the lines of "ACME Client ABC uses a bad RNG and its certs should all be revoked", if a CA uses ARI to mark them all as needing renewal immediately, someone could find out which sites were using the vulnerable version of ACME Client ABC, and that should be something people are aware of as this starts to roll out.
I'm sure I'll have more thoughts as I play around with it more. Thank you!