Could Let's Encrypt (ISRG) consider drafting a RFC for ARI, as an X.509 extension embedded in SSL certificates, to facilitate the integration of renewal/replacement functionality in non‑ACME environments?
What would be the purpose of hardcoding something statically that is inherently meant to be dynamic?
1 Like
I think this is asking for something akin to how OCSP URLs can be embedded within certificates, to embed the ARI URL as well. This might let monitoring systems and the like check the ARI status more easily. I vaguely remember this idea coming up in the discussions as ARI was being drafted. I think it's possible, and might help some cases, but probably isn't actually worth the effort.
4 Likes
ARI is not of interest to the relying party (ie, the browser, or whoever is connecting to the site), so including it in the certificate itself isn't likely to happen.
ARI is part of ACME, so I'm not sure how non-ACME environments would use this.
7 Likes
Isn't the info already available? e.g. You can use the directory of the acme service and the calculated certid?
GET https://example.com/acme/renewal-info/aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE
I guess the missing piece is that you have to work our which CA directory to resolve to from the issuer.
1 Like
I think he wants to use it for some other protocols: (or outside of renewal clients, from a CT log or something)
most likely it'd handle by cert renewal protocol, for example EST have this proposal
2 Likes