> 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?
Sorry, I was one RFC deeper in the reference tree than I thought. The draft that Jason's draft references is RFC5914, not RFC5280, in Section 7. RFC5914 in turn references RFC5280. :) > 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. Yes, this does have advantages, although Comcast's security infrastructure may be much less secure than the infrastructure of the zones it could invalidate. > 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. If it's represented in the DNS, we need to talk about the security model. I guess we do anyway, but the point is that merely having an ops doc that stashes it in the DNS somewhere isn't going to be enough. > 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. I want to hear Jason's response to my possibly out-from-left-field comments before making any such commitment. :) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
