Re: RFC7512 PKCS#11 URI support

Hubert Kario <[email protected]> Tue, 05 Apr 2016 16:58:57 +0200
Newsgroups	gmane.comp.mozilla.crypto
Message-ID	<[email protected]>
On Tuesday 05 April 2016 07:26:56 Ryan Sleevi wrote:
> On Tuesday, April 5, 2016, Hubert Kario <[email protected]> wrote:
> > On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote:
> > > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse
> > > <[email protected]
> > 
> > I'm sorry Ryan, but I also don't see how this would break API.
> 
> Does that mean you don't understand the use cases and situations
> outlined? Or that you don't believe they are valid use cases? Because
> those are all very different statements.

No, I believe that I do understand the use cases as outlined by David.
And I'm very much interested in adding the PKCS#11 URI support.

What is unconvincing to me is your arguments against the change.

> > Stuff that didn't work previously and now will work is not something
> > I would consider API or ABI break.
> 
> We have considered such changes multiple times in the past as breaks -
> most typically on Red Hat's request! This is why multiple extensions
> and behaviours are disabled by default in the TLS stack right now,
> even though they are strictly additive. How would you see this as any
> different?

Because this does not affect existing code. When some API didn't support 
one value, but suddenly starts accepting it, it's not an API or ABI 
break.

That's exactly how APIs like SSL_OptionSet() were changed in the past.

Did Red Hat ever say that making SSL_OptionSet() support a new option ID 
was an API or ABI break?

The previous options being disabled by default were like this because 
the change would be visible by default (e.g. a new extension being 
present in Client Hello, likely the only extension in a TLS1.0 hello). 
And that does pose a problem when you have TLS version intolerant and 
TLS extension intolerant servers out there.

PKCS#11 change is invisible for anybody using certificate nicknames that 
do not happen to be also valid PKCS#11 URIs.

If your code can't handle PKCS#11 URIs, then it won't handle it, but it 
won't break any existing workflow, baring stuff like 
https://xkcd.com/1172/ (existing nicknames are PKCS#11 URIs).
-- 
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)