On Tuesday 05 April 2016 07:26:56 Ryan Sleevi wrote: > On Tuesday, April 5, 2016, Hubert Kario <hka...@redhat.com> wrote: > > On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote: > > > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse > > > <dw...@infradead.org > > > > 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
signature.asc
Description: This is a digitally signed message part.
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
