Looks good to me as well. On Thu, Apr 17, 2025 at 3:40 PM Benjamin Kaduk <bka...@akamai.com> 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]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
