Thanks for the comments. They are all addressed in the revised draft coming out shortly.
--Paul Hoffman On Jun 30, 2024, at 15:31, John R Levine <jo...@taugh.com> wrote: > > I took a look and didn't find anything particularly troubling. I agree that > adding the new optional DNSKEY element doesn't need a version number. Getting > rid of private certificates in favor of a CA signed cert for the HTTPS server > makes sense. > > On the other hand, I don't understand what the point of the new optional > DNSKEY field in the XML is. I see that IANA does not currently include it. > > It's always been possible to retrieve the DNSKEY records from the live root > and check that one of them matches the digest in the XML. Is this to provide > a way to remember the old DNSKEYs that have been rotated out of the root? A > sentence or two describing the motivation would help. > > The third paragraph of section 3.2 describes a detached CMS signature. While > I realize it's there in 7958, I don't see how it provides any security at > all. It's signed with an ICANN private key but there's no way I can see to > tell the "real" ICANN CA from one that I just made up to sign my fake XML. > The useful security is the accredited CA signed HTTPS certificate described > in the following paragraph, so I'd take the CMS signature out or at least > note that it's trivial to defeat unless you have external knowledge about > ICANN's private CA. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
