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

Yes please. This is something I noticed while doing a reading of this draft
a while back.

Amir Omidi (he/them)

On Wed, Feb 21, 2024 at 16:57 Rob Stradling <rob=
40sectigo.com@dmarc.ietf.org> wrote:

> Given the recent interest in processing the backlog of RFC8555 errata
> reports, could I please ask again for
> https://www.rfc-editor.org/errata/eid5732 to be reviewed, approved, and
> marked as "Verified"?
>
> On 4th October 2019, Jacob wrote:
> *"As an author, I think this erratum should be approved."*
> (see
> https://mailarchive.ietf.org/arch/msg/acme/JjLqCSwehaT406A5FxVfTOWYqkw/)
> ------------------------------
> *From:* erica <erica@eff.org>
> *Sent:* 29 February 2020 00:44
> *To:* RFC Errata System <rfc-editor@rfc-editor.org>
> *Cc:* rlb@ipv.sx <rlb@ipv.sx>; jsha@eff.org <jsha@eff.org>;
> cpu@letsencrypt.org <cpu@letsencrypt.org>; jdkasten@umich.edu <
> jdkasten@umich.edu>; rdd@cert.org <rdd@cert.org>; kaduk@mit.edu <
> kaduk@mit.edu>; rsalz@akamai.com <rsalz@akamai.com>; ynir.ietf@gmail.com <
> ynir.ietf@gmail.com>; Rob Stradling <rob@sectigo.com>; acme@ietf.org <
> acme@ietf.org>
> *Subject:* Re: [Acme] [Technical Errata Reported] RFC8555 (5732)
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
> Circling back on this -- I'd still like to see this get verified; are
> there any additional evidence or actions on Certbot's part that could help
> with that?
>
> On 2019-08-23 14:02, erica wrote:
>
> Hi, Erica from Certbot here. I'd love to see this get verified -- it seems
> impossible to implement the "retrying challenges" section as the spec
> currently stands.
>
> On 2019-05-23 02:46, RFC Errata System wrote:
>
> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5732
>
> --------------------------------------
> Type: Technical
> Reported by: Rob Stradling <rob@sectigo.com>
>
> Section: 8
>
> Original Text
> -------------
> A challenge object with an error MUST have status
> equal to "invalid".
>
> Corrected Text
> --------------
> A challenge object with an error MUST have status
> equal to "processing" or "invalid".
>
> Notes
> -----
> Section 8.2 says that 'The server MUST add an entry to the "error"
> field in the challenge after each failed validation query'.  However,
> if the challenge must then become "invalid", it is never possible to
> retry any validation query (because "invalid" is a final state for a
> challenge object).
> This erratum is necessary to permit validation query retries to ever
> happen.
>
> 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
>