Re: RFC7512 PKCS#11 URI support

[Julien Pierre]

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 certainly be unexpected if the server found a cert and came up 
in this case. Would we consider it a bug ? I think it's unlikely that 
any customer would ever run into this and complain about it. It's not an 
impossibility. But this would be borderline user error.


I think there is a difference between extending the syntax of something 
like SSL_OptionSet and PK11_FindCertFromNickname .
In the first case, the cipher suite values passed to the API are 
normally not exposed to the end-user of the application.
But in the later case, the nickname string often is. Thus, it might make 
more sense to create a separate API, that takes a URI as a separate 
argument.

Maybe PK11_FindCertFromNicknameOrURI, or something like that.

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 token:subject - still does not 
uniquely identify a certificate.
There can be multiple certs with different validities, key types, in a 
single token. Only searching on a nickname argument, or even 
token:nickname, is of limited value, as it does not handle many of those 
possibilities. Applications that care about those cases - and server 
administrators tend to want to make sure they are using the right 
certificate - usually have to write their own cert selection functions. 
This is what we have had to do in several products. IMO, the whole 
nickname - or token:nickname - is not really precise enough. In cases of 
ambiguity, it should either fail, or return a list of certs and private 
keys. Then the application could filter that list further. Why cert and 
key ? Because there is a single CERTCertificate even a cert/key lives in 
several tokens. But there are distinct, slot-specific private key 
structures.
IMO, a function that finds a cert with the combination following 
criteria would be helpful :

1) token (PK11Slot*)
2) subject (or nickname)
3) issuer subject  (or nickname of issuer)
4) serial number
These criteria are necessary to uniquely identify a cert and private key 
in a particular token in the NSS world.

This is quite a bit more than just "nickname" or "token:nickname".

Of course, the moment you do a cert renewal, you need to specify the new 
cert properly. If you want this to happen automatically, then you can't 
use uniquely-identifying criteria. Personally, I believe it is 
preferable to have unique identifiers in the runtime. Admin GUIs can be 
used to present the user with a list of certs that are fit for a 
particular purpose in the application. Beyond that one can come up with 
logic to possibly to auto-selection of renewed cert, but the criteria 
would likely be application specific. When even the definition of 
"CERT_IsNewer" is ambiguous, it's very hard to come up with a one-size 
fits all solution.


Anyway, I have digressed quite a bit from the PKCS#11 URI subject at 
this point, so I will stop.


Julien

On 4/5/2016 09:49, John Dennis wrote:
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 token plus colon prefix in the documentation:


https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/SSL_functions/pkfnc.html#1035673 



If the API does not have documented behavior constraints then you 
can't be causing a API breakage.


P.S.: CERT_FindCertByNickname is also undocumented. Nor is there any 
documentation on the syntax of nicknames in Cert DB.


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: RFC7512 PKCS#11 URI support

[Robert Relyea]

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




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: RFC7512 PKCS#11 URI support

[David Woodhouse]

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 anything other than a completely crack-inspired
fashion then we shouldn't break them.

I speak of the general case, of course.

In *this* case, nobody's managed to offer any examples of where an
application might feed a valid PKCS#11 URI as a "nickname" to one of
these functions, and *depend* on the failure they currently get. Not
even as a wild hypothetical.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: RFC7512 PKCS#11 URI support

[John Dennis]

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 token plus colon prefix in the documentation:


https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/SSL_functions/pkfnc.html#1035673

If the API does not have documented behavior constraints then you can't 
be causing a API breakage.


P.S.: CERT_FindCertByNickname is also undocumented. Nor is there any 
documentation on the syntax of nicknames in Cert DB.

--
John
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: RFC7512 PKCS#11 URI support

[Hubert Kario]

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

Re: RFC7512 PKCS#11 URI support

[David Woodhouse]

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 failure mode exists.

But given the amount of time you've expended in arguing your case, it
*is* rather telling that you can't actually come up with *anything*
concrete at all. Not even a reasonable hypothetical with specifics;
only wild handwaving.

I picked up on this part of your original response because it seemed
like there might *possibly* be something in there that's based in
reality, and you've now helped me to conclude that there was not.

Other parts, like the wanton digression about URL vs. URI semantics, I
glossed over completely since they were so obviously a red herring.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: RFC7512 PKCS#11 URI support

[Ryan Sleevi]

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


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.


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


> I see David argumentation as completely valid and correct - this is
> acceptable change.


I still do not believe this is the case. We can certainly bring it up on
the next NSS call.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: RFC7512 PKCS#11 URI support

[Hubert Kario]

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

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