On Wed, 22 Mar 2023 14:16:40 -0700
Aaron Gable wrote:
> I'm not totally sold on the utility of including extra information in
> the ARI response, if that extra information will not modify client
> behavior. If the purpose is to modify human behavior, then I believe
> the current explanationURL is
I'm not totally sold on the utility of including extra information in the
ARI response, if that extra information will not modify client behavior. If
the purpose is to modify human behavior, then I believe the current
explanationURL is sufficient. Adding a machine-readable problem document
that wou
On Thu, 23 Mar 2023 01:55:06 +0900
Seo Suchan wrote:
> I think it's pretty safe to say IFF ARI time changes from what it's
> set just after certificate creation, you could guess there will be
> revocation for that leaf certificate.
I don't think that's a safe assumption - the CA could be adjust
Hi Corey,
On Wed, 22 Mar 2023 17:55:59 +
Corey Bonnell wrote:
> Hi Andrew,
> Is the purpose of the "revocationTime" field such that ACME client
> behavior would be different than the recommended replacement
> time-selection algorithm in section 4.1, or is it to provide richer
> metadata abou
On Wed, 22 Mar 2023 12:46:46 -0400
Amir Omidi wrote:
> My concern with this is that it creates a bit of a requirement to
> revoke by/on that time, which doesn't seem to be the intent of ARI I
> think?
>
> Also what should the precision of this time field be? day/hour/etc?
The same as the suggest
Hi Andrew,
Is the purpose of the "revocationTime" field such that ACME client behavior
would be different than the recommended replacement time-selection algorithm
in section 4.1, or is it to provide richer metadata about the pending
replacement window that is potentially human or machine-readable?
IIRC it was dual purpose: state some randomish time to reduce load spike
at 12:00AM or mass renewal after mass revocation event, and order renew
when revocation is imminent.
I think it's pretty safe to say IFF ARI time changes from what it's set
just after certificate creation, you could guess
My concern with this is that it creates a bit of a requirement to revoke
by/on that time, which doesn't seem to be the intent of ARI I think?
Also what should the precision of this time field be? day/hour/etc?
On Wed, Mar 22, 2023 at 10:35 AM Andrew Ayer wrote:
> I'm working on adding an ARI cl
I'm working on adding an ARI client to a certificate monitoring service
to notify users when one of their certificates is scheduled to be
revoked. Unfortunately, ARI doesn't currently convey whether the
suggestedWindow is mandatory (because the certificate is going to be
revoked) or merely advisor
