Re: [Acme] [Technical Errata Reported] RFC8555 (5861)

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 <tjtncks@gmail.com> 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 <debcooley1@gmail.com>
> 작성함:
>
>> 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 <
>> rfc-editor@rfc-editor.org> 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 <ofriel@cisco.com>
>>>
>>> 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
>>> Acme@ietf.org
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>