On Jul 3, 2024, at 07:50, Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> 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 _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
