Re: RFC7512 PKCS#11 URI support

On 04/04/2016 03:19 PM, Ryan Sleevi wrote:
> On Mon, Apr 4, 2016 at 12:39 PM, David Woodhouse <[email protected]> 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.
I think I would push back on this a bit. David change is very close to 
other changes we've made in the NSS API, in fact this very API. This API 
originally only took a nickname. The token: was an extension added in 
such a way that existing applications that knew nothing about token: 
could still function.

It was purposefully done so that applications that simply passed through 
the nickname from the command line or from the user would get access to 
the new functionality.
>
> When it has an observable difference, when it breaks the contract
> previously provided, we prefer not to do so.
I would disagree it breaks the contract.

I'm presuming the issue here is that you are screening nicknames to 
prevent certain nicknames from being accessed. That presumably means you 
are restricting nicknames to certain tokens? since pkcs11 is not a valid 
token, it would not be in our allow list.

In general I wouldn't recommend using a nickname filter to restrict 
access to certain certs, I'm pretty sure I can break out of any such 
filter you set up with the existing code.

This code wouldn't affect filters on nicknames for object creation.

I think rather than arguing from first principles (because you aren't 
getting any agreement that the priniciples you are starting from are the 
same ones the rest of us are seeing, let's just have an concrete example 
of a broken case in your existing filtering code where would be fooled 
into allowing something it didn't want to allow once this change is made.

bob

-- 
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto