Re: RFC7512 PKCS#11 URI support

Hubert Kario <[email protected]> Tue, 05 Apr 2016 13:38:20 +0200
Newsgroups	gmane.comp.mozilla.crypto
Message-ID	<[email protected]>
On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote:
> On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse <[email protected]> 
wrote:
> > 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?
> David,
> 
> Let's work back from first principals, because you're being
> self-contradictory in replies.
> 
> As you yourself note, this change would mean that any time an
> application can be introduced a "nickname" from some source (whether
> an API, a configuration file, a command-line flag) suddenly has a new
> semantic structure to the nickname over the present NSS.
> 
> You present this as a positive change - all NSS using applications
> don't need to change. I've tried, repeatedly, to explain to you how
> that is an observable API difference. It means that nicknames supplied
> (again, whatever the API) now have additional structure and form.
> 
> Your justification seems to be that because you can't imagine my
> application doing it, I shouldn't be concerned. But just re-read the
> above and you can see how it affects every application - there's now a
> new structure and form, and that changes how applications deal with
> the API (*especially* if they did anything with that configuration
> flag, which, under present NSS, is perfectly legal)
> 
> Your change has observable differences. It breaks the API. Thus, it
> makes sense to introduce a new API. An application cannot safely
> assume it will 'just work' if your change was integrated - instead,
> authors would need to audit every API call they interact with
> nicknames from any source *other* than direct NSS calls, and see if
> they're affected.
> 
> That's simply not an appropriate way to handle API changes.

I'm sorry Ryan, but I also don't see how this would break API.

Stuff that didn't work previously and now will work is not something I 
would consider API or ABI break.

I see David argumentation as completely valid and correct - this is 
acceptable change.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

-- 
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
signature.asc (application/pgp-signature, 819 B)