Agreed on all counts. It is a sensible addition, and is likely the approach that would be taken by ACME servers that implement pre-authorization. To address Seo's good point, I would suggest inserting the text *just before* the last paragraph of Section 7.4.1, and phrasing it as:
"If the constructed authorization object is identical to an existing authorization object associated with the same account, the server MAY return a 200 (OK) response with the existing authorization URL in the Location header and the existing JSON authorization object in the body. Otherwise, the server allocates a new... (text continues as-is)" Aaron On Wed, Jan 3, 2024 at 6:18 AM Seo Suchan <[email protected]> wrote: > Think it should limit to authz with valid or pending state, and for same > account. Finalized auths are still exsit on server; and other accounts may > have auth for it > > > On 2024년 1월 3일 오후 8시 36분 37초 GMT+09:00, Deb Cooley <[email protected]> > 작성함: > >> Happy New Year! >> >> I'm going through acme's errata. This one was reported, but crickets on >> any responses from the authors (or others). It looks like a sensible >> addition to me, but I'd like confirmation. >> >> Thanks >> Deb >> >> On Mon, Sep 23, 2019 at 8:50 AM RFC Errata System < >> [email protected]> wrote: >> >>> The following errata report has been submitted for RFC8555, >>> "Automatic Certificate Management Environment (ACME)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid5861 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: owen friel <[email protected]> >>> >>> Section: 7.4.1 >>> >>> Original Text >>> ------------- >>> >>> >>> Corrected Text >>> -------------- >>> If a server receives a newAuthz request for an identifier where the >>> authorization object already exists, whether created by CA provisioning on >>> the ACME server or by the ACME server handling a previous newAuthz request >>> from a client, the server returns a 200 (OK) response with the existing >>> authorization URL in the Location header field and the existing JSON >>> authorization object in the body. >>> >>> Notes >>> ----- >>> The above text (or similar) should be appended to the end of section >>> 7.4.1 >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC8555 (draft-ietf-acme-acme-18) >>> -------------------------------------- >>> Title : Automatic Certificate Management Environment (ACME) >>> Publication Date : March 2019 >>> Author(s) : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. >>> Kasten >>> Category : PROPOSED STANDARD >>> Source : Automated Certificate Management Environment >>> Area : Security >>> Stream : IETF >>> Verifying Party : IESG >>> >>> _______________________________________________ >>> Acme mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >>> >> _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
