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 <sra(_at_)hactrn(_dot_)net> 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.