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

[Richard Barnes <[e-mail]>]

Just replace "errata" in your mind with "small change we would just make to
the document if the RFC publication process weren't so sclerotic", and it
makes perfect sense.

--RLB

On Thu, Apr 17, 2025 at 3:40 PM Benjamin Kaduk <[e-mail]> wrote:

> Hi Deb,
>
> That matches my understanding of the proposal.
>
> (I always get a bit nervous about using "Verified" for new text that
> points to
> references that didn't exist at the time of the publication of the original
> RFC, but maybe that's just me.  And I guess draft-ietf-dnsop-svcb-httpssvc
> was
> around then, technically speaking.)
>
> -Ben
>
> On Wed, Apr 16, 2025 at 07:35:22PM -0400, Deb Cooley wrote:
> >    This Message Is From an External Sender
> >    This message came from outside your organization.
> >
> >    Trimming the to line so it doesn't get stuck in moderation.....
> >    I'm just making sure that I know what needs to be done when I next go
> in
> >    to mark this errata as verified (not today, BTW).
> >    I'm replacing the Corrected Text with this text?
> >    "Dereference the URL using an HTTP GET request.  This request MUST be
> sent
> >    to TCP port 80 on the HTTP server.  The HTTP client MUST ignore the
> >    presence and content of any HTTPS DNS RRs [RFC 9460] for the domain
> name
> >    being verified.  This includes, but is not limited to, a requirement
> that
> >    the HTTP client MUST NOT apply the strict transport security behavior
> >    specified in Section 9.5 of [RFC9460]."
> >    And then not touching the original text or the notes.
> >    If I've gotten this wrong, it might be easier to file another errata
> and
> >    I'll reject the first and verify the second.
> >    Deb
> >    Your errata servant
> >    On Wed, Apr 16, 2025 at 2:43 PM Erik Nygren <[1][e-mail]>
> >    wrote:
> >
> >      Revised proposed text from Ben Kaduk:
> >      "The HTTP client MUST ignore the presence and content of any HTTPS
> DNS
> >      RRs
> >      [RFC 9460] for the domain name being verified.  This includes, but
> is
> >      not
> >      limited to, a requirement that the HTTP client MUST NOT apply the
> strict
> >      transport security behavior specified in Section 9.5 of [RFC9460]."
> >      On Wed, Apr 16, 2025 at 10:41 AM Richard Barnes <[2][e-mail]>
> wrote:
> >
> >        I would mark this as Verified, though I suggested a couple of
> friendly
> >        amendments on the mailing list:
> >
> >        [3]
> https://mailarchive.ietf.org/arch/msg/acme/zSDRngwBWTgsCfNPcAp6tGO1Ba4/
> >        On Tue, Apr 15, 2025 at 6:49 PM RFC Errata System
> >        <[4][e-mail]> wrote:
> >
> >          The following errata report has been submitted for RFC8555,
> >          "Automatic Certificate Management Environment (ACME)".
> >
> >          --------------------------------------
> >          You may review the report below and at:
> >          [5]https://www.rfc-editor.org/errata/eid8381
> >
> >          --------------------------------------
> >          Type: Technical
> >          Reported by: Erik Nygren <[6][e-mail]>
> >
> >          Section: 8.3
> >
> >          Original Text
> >          -------------
> >             3.  Dereference the URL using an HTTP GET request.  This
> request
> >          MUST
> >                 be sent to TCP port 80 on the HTTP server.
> >
> >          Corrected Text
> >          --------------
> >             3.  Dereference the URL using an HTTP GET request.  This
> request
> >          MUST
> >                 be sent to TCP port 80 on the HTTP server.  (The HTTP
> client
> >          must
> >                 not resolve and/or must ignore any HTTPS DNS RRs [RFC
> 9460].)
> >
> >          Notes
> >          -----
> >          Doing a DNS lookup of an HTTPS DNS RR [RFC 9460] might force the
> >          client to switch from HTTP to HTTPS scheme which would break
> HTTP-01
> >          lookups.  The RFC8555 text is clear that "request MUST be sent
> to
> >          TCP port 80 on the HTTP server" which would be violated if the
> >          validating client did an HTTPS RR lookup in the DNS and
> followed the
> >          instructions in RFC 9460 section 9.5.
> >
> >          Instructions:
> >          -------------
> >          This erratum is currently posted as "Reported". (If it is spam,
> it
> >          will be removed shortly by the RFC Production Center.) Please
> >          use "Reply All" to discuss whether it should be verified or
> >          rejected. When a decision is reached, the verifying party
> >          will 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
> >          Stream              : IETF
> >          Verifying Party     : IESG
> >
> > Links:
> > 1. mailto:[e-mail]/
> > 2. mailto:[e-mail]/
> > 3.
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/acme/zSDRngwBWTgsCfNPcAp6tGO1Ba4/__;!!GjvTz_vk!RAD5VXwqPE8seyvrvjs4dx_HdssruykT5XU8fjK1JJ5b2t2EOGp4uVBLbMVHsLBMRIqb9DL7F3C8mHiJrw$
> > 4. mailto:[e-mail]/
> > 5.
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid8381__;!!GjvTz_vk!RAD5VXwqPE8seyvrvjs4dx_HdssruykT5XU8fjK1JJ5b2t2EOGp4uVBLbMVHsLBMRIqb9DL7F3ByRaNYsg$
> > 6. mailto:[e-mail]/
>