[DNSOP] Re: [Ext] Re: Working Group Last Call for draft-ietf-dnsop-rfc7958bis

[Paul Hoffman <[e-mail]>]

On Jul 3, 2024, at 07:50, Ben Schwartz <bemasc=[e-mail]> wrote:

> 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.

This is addressed in the revised draft coming out shortly.

> 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.

This can be done during IETF Last Call. I'm hesitant to change this based on opinions that are not instantiated in an RFC.

> 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.

This is addressed in the revised draft coming out shortly.

--Paul Hoffman