Re: RFC7512 PKCS#11 URI support

On 04/07/2016 03:49 PM, David Woodhouse wrote: On Thu, 2016-04-07 at 05:01 -0700, Julien Pierre wrote: The problem really stems from the design of NSS, specifically the CERTCertificate*, which maps to a unique DER encoded cert, but not to a single PKCS#11 object in a single token. Since the

Re: RFC7512 PKCS#11 URI support

On Thu, 2016-04-07 at 17:13 -0700, Julien Pierre wrote: > > Hm, I thought PK11_ListCerts tried to eliminate duplicates too, which > > is why it has that crappy O(n²) behaviour? Does it *really* return more > > than one of the 'same' certificate? Don't you *still* get a randomly- > > chosen one

Re: RFC7512 PKCS#11 URI support

David, On 4/7/2016 15:49, David Woodhouse wrote: On Thu, 2016-04-07 at 05:01 -0700, Julien Pierre wrote: The problem really stems from the design of NSS, specifically the CERTCertificate*, which maps to a unique DER encoded cert, but not to a single PKCS#11 object in a single token. Since the

Re: RFC7512 PKCS#11 URI support

On Thu, 2016-04-07 at 05:01 -0700, Julien Pierre wrote: > The problem really stems from the design of NSS, specifically the > CERTCertificate*, which maps to a unique DER encoded cert, but not to > a single PKCS#11 object in a single token. Since the same cert can > exist in multiple tokens, but

Re: RFC7512 PKCS#11 URI support

David, Responses inline. - Original Message - > It certainly makes sense to add a new function which can locate objects > *purely* by their PKCS#11 URI. And if I can spend a little time trying > to properly understand the reasons you currently eschew > PK11_FindCertsFromNickname(),

Re: RFC7512 PKCS#11 URI support

On Wed, 2016-04-06 at 16:09 -0700, Julien Pierre wrote: > David, > > On 4/6/2016 05:57, David Woodhouse wrote: > > ... all this is mostly solved. You can use any or all of CKA_CLASS, > > CKA_ID and CKA_LABEL to identify the objects you want to use. > > Except that CKA_ID does not uniquely

Re: RFC7512 PKCS#11 URI support

David, On 4/6/2016 05:57, David Woodhouse wrote: I also want to mention that there are some fairly major deficiencies in NSS when it comes to finding certificates. The nickname only represents a subject. It does not uniquely identify a certificate. Even token:nickname - which is really

Re: RFC7512 PKCS#11 URI support

On Tue, 2016-04-05 at 17:27 -0700, Julien Pierre wrote: > The API itself may not have been documented, but products using the API  > have documented this token:nickname usage. That is the case for some  > Oracle server products. Now, I can't say that we really envisioned  > anyone entering a URI

Re: RFC7512 PKCS#11 URI support

The API itself may not have been documented, but products using the API have documented this token:nickname usage. That is the case for some Oracle server products. Now, I can't say that we really envisioned anyone entering a URI in the nickname field of our server config files. It would

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 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,

Re: RFC7512 PKCS#11 URI support

On Tue, 2016-04-05 at 12:49 -0400, John Dennis wrote: > > If the API does not have documented behavior constraints then you can't  > be causing a API breakage. I think that's overstating the case a little. Even if the behaviour is undocumented, if real applications are depending on it in

Re: RFC7512 PKCS#11 URI support

One of the problems I have with the argument Ryan presents concerning API contracts and breakage is that "API contract" Ryan talks about is to the best of my knowledge undocumented, it's a API "convention" observed by a select group of developers "in the know". I don't see anything about a

Re: RFC7512 PKCS#11 URI support

On Tuesday 05 April 2016 07:26:56 Ryan Sleevi wrote: > On Tuesday, April 5, 2016, Hubert Kario wrote: > > On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote: > > > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse > > > > > > I'm sorry Ryan, but I also

Re: RFC7512 PKCS#11 URI support

On Mon, 2016-04-04 at 16:23 -0700, Ryan Sleevi wrote: > > I understand and appreciate that you want the standard to be "Show me > the code." But that's not the standard we set. Not at all. I fully appreciate that just because you can't provide any specific failure mode doesn't mean that no such

Re: RFC7512 PKCS#11 URI support

On Tuesday, April 5, 2016, Hubert Kario wrote: > On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote: > > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse > > wrote: > > > Do you even have a way for a nickname to be entered in text form, > >

Re: RFC7512 PKCS#11 URI support

On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote: > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse 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

Re: RFC7512 PKCS#11 URI support

On Mon, Apr 4, 2016 at 4:09 PM, David Woodhouse wrote: > I'm perfectly happy to entertain the notion of adding new functions for > PK11_FindCertsFromURI() (et al.), but I was looking for *real* > information about whether it was actually necessary. Which you don't > seem to

Re: RFC7512 PKCS#11 URI support

On Mon, 2016-04-04 at 16:04 -0700, Ryan Sleevi wrote: > > I've already tried to explain this several times to you. I don't feel > there's anything more useful to contribute. Very well. From my point of view it seems that you have offered straw men, and talked about what would happen if NSS

Re: RFC7512 PKCS#11 URI support

On Mon, Apr 4, 2016 at 3:53 PM, David Woodhouse wrote: > Of course it's an API change. But as noted, it's an API *addition*, in > that it makes something work that didn't before. > > The criterion for such additions should be "if it isn't a *bad* thing > for that to start

Re: RFC7512 PKCS#11 URI support

On Mon, 2016-04-04 at 15:49 -0700, Ryan Sleevi wrote: > I appreciate your argument "but user provided!", but you seem to be > missing the core point - you're changing the syntax of an API's > arguments, in a way that breaks the previously-held pre and post > conditions. That's an API change. > >

Re: RFC7512 PKCS#11 URI support

On Mon, Apr 4, 2016 at 3:45 PM, David Woodhouse wrote: > 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

Re: RFC7512 PKCS#11 URI support

On Mon, 2016-04-04 at 15:19 -0700, Ryan Sleevi wrote: > On Mon, Apr 4, 2016 at 12:39 PM, David Woodhouse 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 > >

Re: RFC7512 PKCS#11 URI support

On Mon, Apr 4, 2016 at 12:39 PM, David Woodhouse 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

Re: RFC7512 PKCS#11 URI support

On Mon, 2016-04-04 at 12:17 -0700, Ryan Sleevi wrote: > > 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

Re: RFC7512 PKCS#11 URI support

On Mon, 2016-04-04 at 12:21 -0700, Ryan Sleevi wrote: > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse wrote: > > > > I don't see it. I still don't see *any* way for you to get a PKCS#11 > > URI anywhere in the memory space of your application, unless you > > specifically

Re: RFC7512 PKCS#11 URI support

On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse wrote: > I don't see it. I still don't see *any* way for you to get a PKCS#11 > URI anywhere in the memory space of your application, unless you > specifically ask for one with a new API — or unless you take untrusted > input

Re: RFC7512 PKCS#11 URI support

On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse 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

Re: RFC7512 PKCS#11 URI support

On Mon, 2016-04-04 at 08:23 -0700, Ryan Sleevi wrote: > This is, of course, demonstrably false. One can no longer filter the inputs > to this API if your change is accepted, because the format will have > changed. For example, colon no longer becomes the separator between the > token and the

Re: RFC7512 PKCS#11 URI support

On Monday, April 4, 2016, David Woodhouse wrote: > > I didn't call you a liar. I simply said that I can't see how the > statement you made could be anything but false. There are plenty of > reasons that could be the case — including my own ignorance — which > don't involve

Re: RFC7512 PKCS#11 URI support

On Mon, 2016-04-04 at 07:48 -0700, Ryan Sleevi wrote: > > On Apr 4, 2016 7:15 AM, "David Woodhouse" wrote: > > > > Ryan? > > > > Unless you are able to provide an explanation of how this would "break > > Chrome's use of the API", I shall continue to assume that your > >

Re: RFC7512 PKCS#11 URI support

On Apr 4, 2016 7:15 AM, "David Woodhouse" wrote: > > Ryan? > > Unless you are able to provide an explanation of how this would "break > Chrome's use of the API", I shall continue to assume that your > statement was false, and design accordingly. > > I certainly can't see how

Re: RFC7512 PKCS#11 URI support

On Thu, 2016-03-17 at 15:18 +, David Woodhouse wrote: > > > I am still strongly opposed to introducing this behaviour to the existing > > functions. The nickname functions already have significant magic attached > > to them, both in parsing from NSS APIs and in providing to NSS APIs > >

RFC7512 PKCS#11 URI support

As Varun ramps up for the potential GSoC project on implementing URI support, I'd really like to get some consensus on the implementation details — there is at least one choice which needs to be made, which will affect his development from day one. As discussed in 

Re: RFC7512 PKCS#11 URI support

On 03/17/2016 10:52 AM, Ryan Sleevi wrote: On a technical front, Chrome and Firefox, as browsers, have been removing support for the notion of generic URIs, and investing in aligning on the URL spec - that is, making a conscious decision NOT to use URIs as URIs. Could you clarify this

Re: RFC7512 PKCS#11 URI support

On Thursday, March 17, 2016, John Dennis wrote: > On 03/17/2016 10:52 AM, Ryan Sleevi wrote: > >> On a technical front, Chrome and Firefox, as browsers, have been >> removing support for the notion of generic URIs, and investing in >> aligning on the URL spec - that is,

Re: RFC7512 PKCS#11 URI support

On Thursday, March 17, 2016, David Woodhouse wrote: > > It is a fundamental part of all the major Linux desktop distributions, > and thus fairly much ubiquitous there. This is a loaded statement, but I still believe this is overstated. But I don't want to get into a "whose

Re: RFC7512 PKCS#11 URI support

> I am still strongly opposed to introducing this behaviour to the existing > functions. The nickname functions already have significant magic attached > to them, both in parsing from NSS APIs and in providing to NSS APIs > (filtering or setting the token via parsing or adding to the token name,