I think this is important work. I have to confess that I haven't followed the development of this draft, so this may be an observation that's already been addressed, but I'm concerned that there's nothing in this document about ensuring that the negative trust anchor is trustworthy through validation other than through the X.509 CA infrastructure currently used for TLS.
The problem with this is that it means that a compromised CA (of which there have been a number recently) can be used as an attack on the DNSSEC validation chain. In addition, some CAs have been known to issue Certs for the express purpose of circumventing privacy and authentication features of X.509 certs. DANE has recently published documents that leverage the DNSSEC infrastructure to protect organizations that have implemented DNSSEC from X.509 PKI attacks. If you use that same PKI to validate negative trust anchors, you're effectively invalidating the security model of those RFCs. I think therefore that using X.509 certs as negative trust anchors is a really bad idea, and I would suggest that it might be worth proposing a mechanism in your draft that does not rely on such trust anchors. I would suggest that the right solution is to rely on the DNSSEC security infrastructure to publish negative trust anchors, rather than relying on RFC5280. I realize that this means more work, probably for DNSEXT, the chairs of which were hoping for a vacation after completing their current work, but I think this would be a much better option nevertheless. Again, sorry if I'm misunderstanding what you're proposing. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
