Re: [Acme] Renewal Information extension: Proposal to add an Explanation URL

How can we make this testable, and ensure ACME clients won't break because
of bugs that only show in the edge cases when this explanation URL is
given? The current ARI proposal looks identical to the ACME client no
matter if it is a regular scheduled renewal, or an exceptional renewal,
which makes it harder to introduce bugs in the ACME clients for the
exceptional case.

Den tor. 10. feb. 2022 kl. 05.38 skrev J.C. Jones <ietf@insufficient.coffee
>:

> While ARI is clearly intended for automated usage, its ease of
> construction permits interested third parties with knowledge of a
> certificate to request the ARI information as well as the
> certificate's subscriber. This is a feature, not a bug, as it permits
> another useful use case:
>
> Imagine a certificate lifecycle tool that monitors many TLS endpoints
> for certificate lifetime and status. Such a tool could naturally also
> query the ARI endpoint for each compatible certificate, as a means of
> determining certificate lifetime in the face of pending revocation.
>
> When the tool notices via ARI that a certificate should be renewed
> early, that's probably going to generate alerts -- and it would be
> valuable to those receiving an alert for a certificate that suddenly
> needs renewal to have some context as to why, if it's possible.
>
> Hence, I propose we add an optional field to the ARI response
> structure, "explanationURL", which when populated should be presented
> in any user-visible context (logging, alerting, etc) by the
> ARI-compatible client. It would be up to the Certificate Authority to
> ensure the URL presented appropriately translated information for the
> operator, and the CA _should_ only provide the field if there was
> something exceptional that warranted additional explanation or
> context.
>
> J.C.
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>