On Mon, 2016-04-04 at 15:19 -0700, Ryan Sleevi wrote: > On Mon, Apr 4, 2016 at 12:39 PM, David Woodhouse <dw...@infradead.org> wrote: > > > > > > We usually reserve the term "breaks the API" for when something *used* > > to work, and now doesn't. Not when a previously-failing call now > > actually does something useful. > No, sorry David, that's not how we've done stuff in NSS. > > When it has an observable difference, when it breaks the contract > previously provided, we prefer not to do so. > > The contract that NSS has lived by is that applications have had to > know about the token:nickname vs nickname rule in the APIs. When you > get a nickname for a cert, depending on the function used, you may or > may not have to add the token. If you don't, you get bad results.
That won't change. Unless you explicitly use a new function that provides a URI instead of a nickname, of course. You will *only* get a URI from direct user input, in a situation where a user could already feed you any kind of nonsense. > So we've had an API contract that the nicknames input to this function > have a syntax and format, because applications have to be aware of how > to construct it. Because applications have to be aware of how to > construct it, applications also have to be aware of how to deconstruct > it. Many applications don't, and just pass the nickname provided by the user into NSS to select a certificate. Those are the cases which would benefit from having PK11_FindCertsFromNickname transparently take a PKCS#11 URI. The application automatically starts accepting the standard form for specifying PKCS#11 objects. Yay! Other applications may do this kind of deconstruction, and those applications explicitly *don't* support PKCS#11 URIs; only NSS nicknames. for the user to enter a PKCS#11 URI into their configuration would be an error. It would look like a nickname referencing a token named 'pkcs11', which almost certainly doesn't exist. I'm having difficulty imagining what the problem is though. Let's assume that a user *does* provide a PKCS#11 URI to one of the latter class of applications, which really does want a nickname. Either the application will fail to parse it (or say "there is no token named 'pkcs11'") and won't pass it to NSS at all, in which case nothing harmful has happened. Or the application passes it to NSS anyway, and it works as the user presumably intended. In which case nothing harmful has happened. Where's the problem? -- 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
