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 <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 >> > <mailto:erik%2bi...@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 >> > <mailto:erik%2bi...@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 <mailto:erik%252bi...@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 <mailto:erik%252bi...@nygren.org>/ > _______________________________________________ > Acme mailing list -- acme@ietf.org > To unsubscribe send an email to acme-le...@ietf.org _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
