I think this document is ready for publication with some nits. Section 1.1
I like the "assumed and not derived" notion for a "trust anchor", but it's tricky and bears a bit more explanation. Rather than repeating it in the following sentence, perhaps you could say "the decision to trust this entity is made outside of the system that relies on it". My point is that "assumed and not derived" requires a certain sort of "horizon" comprising a single "system"; expand the horizon and it is indeed derived. For example, trust in these DNSKEYs can be derived from the CMS signature, making the ICANN CA the trust anchor, but that process is outside of DNSSEC, so from DNSSEC's perspective the root key is the trust anchor. Section 3.1 The existence of a protocol called "HTTPS" is controversial in the HTTP world. I recommend checking with the HTTPBIS chairs or other relevant experts on this point of style. Section 3.3 This section says "cryptographic assurance for the contents of the trust anchor now comes from the web PKI as described in Section 3.2", but Section 3.2 outlines two ways to verify the contents: an attached signature or TLS. The TLS case looks like the Web PKI, especially since it is not guaranteed to chain to any particular root CA, but the attached signature does not seem to represent a dependency on the Web PKI. --Ben Schwartz ________________________________ From: Tim Wicinski <tjw.i...@gmail.com> Sent: Wednesday, June 19, 2024 12:32 PM To: dnsop <dnsop@ietf.org> Cc: dnsop-chairs <dnsop-cha...@ietf.org> Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7958bis All The authors have updated the document based on some early reviews. Since this is an update from the original RFC7958, I urge folks to take a look at the diff from the original: https: //author-tools. ietf. org/iddiff?url1=rfc7958&url2=draft-ietf-dnsop-rfc7958bis-02&difftype=--htmlThis ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd All The authors have updated the document based on some early reviews. Since this is an update from the original RFC7958, I urge folks to take a look at the diff from the original: https://author-tools.ietf.org/iddiff?url1=rfc7958&url2=draft-ietf-dnsop-rfc7958bis-02&difftype=--html<https://author-tools.ietf.org/iddiff?url1=rfc7958&url2=draft-ietf-dnsop-rfc7958bis-02&difftype=--html> This starts a Working Group Last Call for: draft-ietf-dnsop-rfc7958bis "DNSSEC Trust Anchor Publication for the Root Zone" Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/<https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/> The Current Intended Status of this document is: Informational Benno will be the document shepherd Please review the draft and offer relevant comments. For WGLC, we need positive support and constructive comments; lack of objection is not enough. So if you think this draft should be published as an RFC, please say so. If you feel the document is *not* ready for publication, please speak out with your reasons. This starts a two week Working Group Last Call process, and ends on: July 3rd, 2024 thanks tim
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
