On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse <dw...@infradead.org> wrote: > I don't see it. I still don't see *any* way for you to get a PKCS#11 > URI anywhere in the memory space of your application, unless you > specifically ask for one with a new API — or unless you take untrusted > input from the user or an editable config file, of course.
Exactly so. You fail to realize this as a change, but it's exactly that. > I certainly don't see how it could cause you to display such URIs > directly to the user, as you suggest. So tell me, what do you expect an application to do that displays the results from parsing such a configuration (for example, it reads from a config file "token:nickname", parses that value, and displays GUI for "token" and "nickname")? Is your belief that this is not an acceptable usage of the NSS API, and not a guarantee of the NSS API contract? Then just say that, and we can have a productive conversation. But it should be terribly simple, and not require any creativity or imagination, to see how such a scheme would be broken in the introduction of "pkcs11:token=Foo;object=bar;" - the UI would result in the token of "pkcs11" and the 'nickname' of 'token=Foo;object=bar". -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
