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
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
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
> Am 13.02.2022 um 06:39 schrieb Benjamin Kaduk :
>
> On Thu, Feb 10, 2022 at 02:31:15PM -0500, Michael Richardson wrote:
>>
>> J.C. Jones wrote:
>>> Hence, I propose we add an optional field to the ARI response
>>> structure, "explanationURL", which when populated should be presented
>>> in
On Thu, Feb 10, 2022 at 02:31:15PM -0500, Michael Richardson wrote:
>
> J.C. Jones wrote:
> > 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,
J.C. Jones wrote:
> 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
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
