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]erik+i...@nygren.org> > 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]r...@ipv.sx> 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]rfc-edi...@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: > [5]https://www.rfc-editor.org/errata/eid8381 > > -------------------------------------- > Type: Technical > Reported by: Erik Nygren <[6]erik+i...@nygren.org> > > 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:erik%2bi...@nygren.org/ > 2. mailto:r...@ipv.sx/ > 3. > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/acme/zSDRngwBWTgsCfNPcAp6tGO1Ba4/__;!!GjvTz_vk!RAD5VXwqPE8seyvrvjs4dx_HdssruykT5XU8fjK1JJ5b2t2EOGp4uVBLbMVHsLBMRIqb9DL7F3C8mHiJrw$ > 4. mailto:rfc-edi...@rfc-editor.org/ > 5. > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid8381__;!!GjvTz_vk!RAD5VXwqPE8seyvrvjs4dx_HdssruykT5XU8fjK1JJ5b2t2EOGp4uVBLbMVHsLBMRIqb9DL7F3ByRaNYsg$ > 6. mailto:erik%2bi...@nygren.org/ _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
