On Mon, 2016-04-04 at 12:21 -0700, Ryan Sleevi wrote: > 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".
In the case you describe, the user might *already* enter a PKCS#11 URI instead of a nickname. Take a look at cURL, for example — with open bugs for the NSS-built version, because it doesn't take certificate specifiers in that form when the GnuTLS-built version *does*. Those bugs were filed because people are *already* trying to feed PKCS#11 URIs to NSS applications, and NSS is failing to work. So what actually happens? Yes, if we parse the token:nickname and display it to the user as you describe, then we'll display something odd. Always true, before or after my proposed changes. My proposed changes would make no difference to that cosmetic issue; what they *would* do is make the PKCS#11 URI specified by the user actually *work* instead of failing. So your cosmetic argument above, while true, is not particularly interesting. It is *just* cosmetic, and exists already. (And not in Chrome, as far as I'm aware. Or indeed anywhere in reality. Feel free to contract me, but with references only). I'm more interested in whether there's a case where we *wouldn't* want NSS to actually work. After all, if the user gets to specify arbitrary strings to identify the certificates they want you to use, why would you not honour that? That's why I asked you for specifics about the "filtering" that you do. Which I note you failed to provide. But even so, unless you were going to permit the user to specify *any* object in a token named 'pkcs11', I don't see how the filtering comes to any harm either. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
