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
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
