Hi Andrew, > That could potentially be useful. Do you have any other information in mind that would be included?
My initial thoughts are that a "reason" field with a URN denoting the rationale for the specified renewal information (pending revocation, expiration, etc.) would be useful. Each reason could then have specific fields, such as "anticipatedRevocationDateTime" for the revocation case, or even the anticipated RFC5280 revocation reason code. The "explanationURL" could also be moved to this structure as opposed to being a top-level field, as it is metadata-only. Even if only a few fields are defined within this metadata-only sub-structure, I think there's value in putting all metadata-only information within this sub-structure to avoid polluting the top-level namespace if additional fields are needed in the future. Thanks, Corey -----Original Message----- From: Acme <[email protected]> On Behalf Of Andrew Ayer Sent: Wednesday, March 22, 2023 4:30 PM To: Corey Bonnell <[email protected]> Cc: [email protected] Subject: Re: [Acme] ARI: Indication if certificate will be revoked Hi Corey, On Wed, 22 Mar 2023 17:55:59 +0000 Corey Bonnell <[email protected]> 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 about the pending replacement window that is potentially > human or machine-readable? It is the latter - to provide richer metadata about why the window is what it is. ACME client behavior would not be affected. > If the latter, I'm wondering if we could consider defining a RFC > 7807-style "problem document" format that would provide fuller > information that is both human- and machine-readable. The > "explanationURL" field as it currently exists in the draft might be > useful for conveying human-readable information, but defining a fuller > representation of replacement-related metadata would also allow > machine-readable information to be conveyed. That could potentially be useful. Do you have any other information in mind that would be included? Regards, Andrew _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
