On Mon, 2016-04-04 at 08:23 -0700, Ryan Sleevi wrote: > This is, of course, demonstrably false. One can no longer filter the inputs > to this API if your change is accepted, because the format will have > changed. For example, colon no longer becomes the separator between the > token and the nickname. > > This is basic, so I'm not sure why you're suggesting it doesn't change.
My understanding is that in your environment there are only *ever* the traditional nicknames. There are no PKCS#11 URIs. So your filtering doesn't need to change, does it? Can you provide a specific reference to the filtering that you do, and what it achieves? Your description is still insufficiently specific for me to understand the failure mode you're concerned about. Do you even have a way for a nickname to be entered in text form, such that you could "maliciously" be given a PKCS#11 URI instead of the normal "token:nickname" form? Perhaps a user could edit a config file? Or is it *all* selected via a GUI, as far as the user is concerned? FWIW a PKCS#11 URI will always start with 'pkcs11:', so the only prospect for collision is if there is a token whose name is 'pkcs11'. Which is both unlikely, and easily handled in a manner which gives precedence to the original 'token:nickname' format. > > ... which would cause us to display such URIs directly to the user. > > > > No. As repeatedly stated, we were *only* talking about allowing > > functions like PK11_FindCertsFromNickname() to accept a RFC7512 > > identifier (PKCS#11 URI) in *addition* to the existing NSS nickname > > form. There is *no* way that such a change could possibly have the > > effect you describe. > > See above. I just described to you how it can and would happen. 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. I certainly don't see how it could cause you to display such URIs directly to the user, as you suggest. > > Separately, we would also want to add new functions to obtain the > > RFC7512 identifier for a given object. But obviously those *couldn't* > > overload the existing functions to get nicknames; that would be silly. > > And yet it would do exactly that, when indirected through a persistence > layer, which is part of the justification for this change. If the "get the > nickname from this config" returns a URI, which was explicitly part of the > justification for his change, ... (Reference please) What we said was that we want applications (and libraries) like cURL to Just Work if they are provided with a standard PKCS#11 URI on their command line (or in their config file) in place of the existing NSS- specific nickname. Yes, if the user can edit your config files and *introduce* arbitrary strings of their own choice, then you might see a PKCS#11 URI. Otherwise, you'll never see one. This whole thing should basically be a no-op for a purely GUI program like the browser. You'll *never* see a PKCS#11 URI, you'll never even have cause to notice that PK11_FindCertsFromNickname() *would* have accepted one, if you were to pass it one. Because you won't. You enumerate objects and obtain their (traditional) nickname as you do so, and as the user selects them in a GUI. If you do store the string in a persistent fashion, that's still the NSS nickname, never a PKCs#11 URI. You basically shouldn't *notice* the change. It isn't for you. The design goal is basically that you shouldn't notice it. > then it very much is a > change of a "get the nickname" function. Again, please be specific. What, exactly, is it that you think is going to break? A worked example with function names, please. Preferably with a specific reference to the existing source code. -- 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
