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 <r...@ipv.sx> wrote: > I would mark this as Verified, though I suggested a couple of friendly > amendments on the mailing list: > > https://mailarchive.ietf.org/arch/msg/acme/zSDRngwBWTgsCfNPcAp6tGO1Ba4/ > > On Tue, Apr 15, 2025 at 6:49 PM RFC Errata System < > 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: >> https://www.rfc-editor.org/errata/eid8381 >> >> -------------------------------------- >> Type: Technical >> Reported by: Erik Nygren <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 >> >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
