On 2013-02-16, at 18:04, Ted Lemon <ted.le...@nominum.com> wrote: > 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.
I'm confused where you drew the reference to 5280 from (or X.509). I don't see anything in the draft that concerns publication or automatic retrieval of NTAs from elsewhere; which section did I miss? I do quite like the idea of being able to publish a policy for a family of validators, however. I like the idea of being able to bring up a validator and subscribe consciously to the policy in such a zone, along the lines of "I'll disable validation for anything I've noticed needs to be handled that way, plus anything that Comcast is willing to tell me about their current validation policy because they know what they are doing". This has advantages for me as a validator operator, and advantages for others who might want to debug the output of my validator with reference to my current validation policy. I like the idea of such a policy being published in the DNS, also. Given that validators already have hooks to disable validation for particular domains, and assuming we don't necessarily need to invent new RRTypes to encapsulate that policy in the DNS, I don't necessarily see dnsext work in here. A convention about how to represent this kind of policy in the DNS seems like it could be dnsop work, though. Jason: you didn't ask directly, but if the working group was polled to determine support for adopting this document, I would say yes and volunteer to review it. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
