>
> Using something like "just HTTP headers" sounds very simple, but HTTP
> headers and their semantics do not come for free either. There is a large
> caching infrastructure out there that might, or might not, be sensible to
> added Headers. Those complications might qui
s do not come for free either. There is a large caching
infrastructure out there that might, or might not, be sensible to added
Headers. Those complications might quickly outweight any JSON parsing burdens.
Kind Regards,
Stefan
>
> From: Ryan Sleevi
> Sent: 18 February 2022 18:49
&g
er than the level of traffic from (relying
party) OCSP requests, but it's much easier for us to scale our OCSP responders
than our CA / ACME servers.
____________________
From: Ryan Sleevi
Sent: 18 February 2022 18:49
To: Rob Stradling
Cc: acme@ietf.org
Subject: Re:
On Fri, Feb 18, 2022 at 12:51 PM Rob Stradling wrote:
> draft-aaron-acme-ari-01 describes an "extension to ACME", but ISTM that
> the core, OCSP-inspired protocol is not specific to ACME at all. I
> appreciate that the document author's employer and this WG are only
> directly concerned with the
draft-aaron-acme-ari-01 describes an "extension to ACME", but ISTM that the
core, OCSP-inspired protocol is not specific to ACME at all. I appreciate that
the document author's employer and this WG are only directly concerned with the
ACME use case; however, ISTM that providing "renewal informa
