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

From: "J.C. Jones" <[email-masked]>
Date: Wed, 9 Feb 2022 21:31:08 -0700

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.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Feb 2022 14:31:15 -0500

> something exceptional that warranted additional explanation or

Sounds good.

If it's for human consumption, then it might need to be an array or dict,
with per-language versions.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 12 Feb 2022 21:39:44 -0800

> with per-language versions.

Yes, BCP 18 has a few things to say on this matter.

-Ben

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 14 Feb 2022 10:17:23 +0100

> Am 13.02.2022 um 06:39 schrieb Benjamin Kaduk <[email-masked]>:
> 

Unnecessary. HTTP servers can redirect to language specific resources just fine. Let's not i18n the protocol urls, please.

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Aaron Gable <[email-masked]>
Date: Mon, 14 Feb 2022 09:16:32 -0800

In fact, what BCP 18 has to say on the matter is:
> ...protocols are not subject to internationalization; text strings are.
So yes, the appropriate place for internationalization here would be at the
level of the site pointed at by the URI, not at the level of the URI itself.

Regardless, I like this proposal. It provides good value (especially for
certificate monitoring services) at very little cost (completely optional
for both server and client). It does feel a little odd to include something
directly in the protocol that is not actually intended for consumption by
most ACME clients (they're non-interactive, the most they're likely to do
is log it to a file their operator isn't going to look at anyway). But I
think it makes sense to recognize the reality of the current ecosystem.
ACME clients do one thing well -- renew certs. Cert monitors do one thing
well -- alert site operators when something unusual is happening. No reason
not to enable both.

Aaron

On Mon, Feb 14, 2022 at 1:17 AM Stefan Eissing <[email-masked]> wrote:

> Unnecessary. HTTP servers can redirect to language specific resources just
> fine. Let's not i18n the protocol urls, please.
>
> >

---

From: Jesper Kristensen <[email-masked]>
Date: Mon, 14 Feb 2022 19:29:00 +0100

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 <[email-masked]
>:

---

From: "J.C. Jones" <[email-masked]>
Date: Mon, 14 Feb 2022 12:20:45 -0700

Since it's informational, it seems that in testing environments (e.g.,
Pebble), one can populate the field some percentage of the time, so
client developers can handle it safely (or ignore it, if they choose).

(While we're at it, we can also explicitly recommend GREASE[0]
behavior for the ARI response.)

[0] https://tools.ietf.org/html/draft-davidben-tls-grease-01

On Mon, Feb 14, 2022 at 11:29 AM Jesper Kristensen <[email-masked]> wrote:
>
> 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 <[email-masked]>:
>>