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

[Martin Thomson <[e-mail]>]

I don't think that Verified fits that definition, though "Hold for Document Update" might.

On Fri, Apr 18, 2025, at 11:31, Richard Barnes wrote:
> 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] <mailto:[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] <mailto:[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] <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] <mailto:[e-mail]>/
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]