[For some reason, I seem to receive Phillip's messages later than other people who are responding to his messages. Odd.] Hi, > Signing the .com zone is irrelevant until we have a process for > putting the key in. Not really. If VeriSign were to sign .COM tomorrow and publish their key somewhere well known, people who run validating resolvers could fetch that key, validating it however they see fit, and install it as a trust anchor in their resolver. This is among the reasons ITAR was created. To date, 12 TLDs have listed their keys in ITAR (see https://itar.iana.org/anchors/) using the same authentication mechanisms used to validate TLD update requests. > Several people are aware that I am asking this > question and will be speaking on DNSSEC at RSA next week. The fact > that the answer has been invariably 'I will get back to you on that' > and not 'here is the document you need to read' is itself rather > significant. Not really, other than in the sense that people are really, really busy and, having presented on the ITAR in numerous venues over the past year or two (I've forgotten when we stood up the ITAR and can't be bothered to go look it up), generally assume people who have need of ITAR services can find out about it. > Instead of positioning DNSSEC as an alternative to SSL certificates, Huh? Who is positioning DNSSEC that way? People have mentioned that DNSSEC could, maybe someday in the far future, perhaps provide an alternative PKI infrastructure but that generally is not how DNSSEC is being positioned, at least to my knowledge. DNSSEC is primarily being positioned as protection against MITM DNS-based attack. > Nobody can deploy or test standards based validation > infrastructure until the root is signed and a lot more happens > besides. Sure they can, and in fact do. ISPs in Sweden, for example, have (I'm told) been validating .SE domains for some time now. For TLDs, there is ITAR. For folks in islands of trust, there is DLV (if you trust ISC and are willing to accept the implications of using DLV). Regards, -drc _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf