Whilst I agree it has no operational consequence for current relying party code, or consumers of the products of certificates embedded in online systems, I don't agree with Randy's or Rob's conclusions regarding the desirability or risks of this feature.
I think this is a useful addition to the qualities of information in a certificate, and I support its status. Since the drivers are non-operational, I don't feel it useful to try and suggest there are any. I also think that should not preclude the adoption of this requirement in certificates. This is a documentation and risk-minimisation process which makes layer-9 happy. -George On Thu, Feb 13, 2014 at 7:06 AM, Rob Austein <[email protected]> wrote: > Since we seem to be re-hashing some of the issues discussed during > WGLC of this draft: > > I don't agree that this draft is harmless: I think it's an attractive > nuisance. Given that we already have an RIR which makes people sign a > non-disclosure agreement (!) to get a copy of their trust anchor > locator, it's not all that far-fetched to imagine that same RIR adding > another contractual requirement in which the user of their trust > anchor locator is also made to promise that they will perform > additional checks outside the core specification using the URI > specified in the policy qualifier. The draft doesn't rule this out, > it just says that the draft itself adds no such processing > requirements. I do not find this particularly reassuring. > > That said, the RIR in question has already demonstrated that they > don't need policy qualifiers to impose whacky restrictions outside the > scope of the protocol architecture, so denying them use of this policy > qualifier hack wouldn't gain the user community all that much. > >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
