Re: RFC7512 PKCS#11 URI support

[Robert Relyea]

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 same cert can
exist in multiple tokens, but there can only be one CERTCertificate*
pointer for all of them, the only way to resolve the issue would be
for the lookup function to return something other than just
CERTCertificate* alone. PK11_ListCerts does that.

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 with unpredictable contents of cert->slot?


No, there is only one cert no matter how many tokens that cert exists in.

cert->slot points to either the internal token (if the cert doesn't 
exist in a removable slot), or the first PKCS #11 removable slot. There 
is a call: PK11_GetAllSlotsForCert() which will return a slotlist of all 
the slots that certificate lives in.



Hm, purely for finding the *cert*, why doesn't the token: prefix
resolve that?

The token: prefix is only used as a starting point for the lookup.
But if the same DER cert exists in multiple tokens, then the value of
CERTCertificate->slot pointer is unpredictable.
It may or may not match what was used during the lookup. Same issue
for the nickname field.


It doesn't really work like that Julian. There is only one cert, the 
slot value is the same for all certs no matter how you looked it up. 
There is no guarantee that the token: value will map to the same slot as 
cert->slot.


In practice the number of times you have the same certificate on more 
than just the internal token and one other slot is exceedingly rare. 
That is the only reason the current code works at all.



OK, but you have the cert in your hand; it doesn't matter where it came
from as long as it's the right one. Hell, in OpenConnect I support
modes where the cert is in a file and only the key is in PKCS#11 or
TPM. Who *cares* where the cert came from?

It's only the *key* which really needs to be found in the right place,
since you have to *use* it from there, right?


This is correct. This is exactly how it works in NSS. NSS knows how to 
search all the slots the certificate lives on to find the related key.



Basically, what it comes down to, is that if you use the following
sequence :
cert = PK11_FindCertFromNickname("token:subject")
key PK11_FindKeyByCert(cert);

Your cert and key may not match the "token" in the original lookup
string. cert->slot and key->slot may not match.


There isn't  a PK11_FindKeyByCert. There is a 
PK11_FindPrivateKeyFromCert and it takes a slot from the caller, not 
from cert->slot.



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 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 with unpredictable contents of cert->slot?
>
> It depends on the argument to PK11_ListCerts .

Hm, I'd missed that useful detail; thanks. I'll experiment with making
Evolution use that, and maybe it'll stop taking so long to enumerate
certs, when I make the entire company Exchange address book (well, the
S/MIME certs therein) available in a PKCS#11 token :)

Our GSoC student has actually come up with a good patch to fix the
O(n²) behaviour, but avoiding the filtering altogether would fix it for
Evolution in even *current* NSS versions, and allow us to enable that
new PKCS#11 token straight away.

> Well, the fact cert may not match "token" isn't necessarily an issue.
> But it's definitely an issue for the key.

Some might argue that it's an obvious bug if
PK11_FindCertsFromNickname("token:...") returns an object such that
cert->slot doesn't match the "token". Why in $DEITY's name is it even
*looking* elsewhere? Does it go off and do its O(n²) enumeration of all
those thousands of certs in my corporate addressbook (for example),
when it was explicitly told to look *elsewhere*?

Regardless of the existing/historical behaviour of the nickname API and
whether we can 'fix' that 'bug', I think we can *certainly* declare
that a new PK11_FindCertsFromUri() function MUST only return objects
such that cert->slot matches the slot which was identified by the URI,
if a slot was specified. Never the same cert from elsewhere.

That basically covers your needs, at least as far as the new API is
concerned, doesn't it? It means that you *can* just use cert->slot to
find the key.


> > And if you find any app shipped in Fedora which *doesn't* support it,
> > please do file a bug.
>
> Since I don't use Fedora, that is unlikely. The Linux we support is 
> either RHEL, or OEL which is some RH fork, not quite sure from what 
> tree. Dev is mostly done on OEL.

It's coming to RHEL (that being part of Fedora's raison d'être).

So there will (hopefully soon) come a time when it is appropriate to
file RHEL bugs against any tool which accepts certs from a file (via
command line or config file, etc.), and which *doesn't* also accept
PKCS#11 URIs in place of the filename. And which doesn't automatically
load the PKCS#11 tokens listed for it in the system's (and/or user's)
p11-kit configuration.

In fact I think the Red Hat folks have already started cloning some of
the open Fedora bugs, against RHEL.

> > Yeah, but solving it for PKCS#11 is still a very big step forward for
> > usability. On Linux platforms it still gives us *consistent* access to
> > a key either in a hardware token, or in a software token like GNOME-
> > keyring's or even the NSS user database in ~/.pki/nssdb (although
> > there's more work to be done before that's easy).
> > 
> Yeah, AFAIK Firefox/Thunderbird still don't use DB in the user's 
> directory. Also, they still don't use the sqlite DB.

Yeah. Chrome manages to use sql:$HOME/.pki/nssdb, but unfortunately
still doesn't manage to use sql:/etc/pki/nssdb when nsssysinit.so is
set up. There is basically *nothing* that gets this right. Partly
because there's no clear answer about what is "right".

Evolution basically *greps* /etc/pki/nssdb/pkcs11.txt to see if
nsssysinit.so is enabled there, and uses sql:/etc/pki/nssdb or
sql:$HOME/.pki/nssdb accordingly. Which is just horrid. It basically
gets the right behaviour, but I can't call it the "right thing to do".

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

[Julien Pierre]

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 same cert can
exist in multiple tokens, but there can only be one CERTCertificate*
pointer for all of them, the only way to resolve the issue would be
for the lookup function to return something other than just
CERTCertificate* alone. PK11_ListCerts does that.

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 with unpredictable contents of cert->slot?

It depends on the argument to PK11_ListCerts .

typedef enum {
 PK11CertListUnique = 0, /* get one instance of all certs */
 PK11CertListUser = 1,   /* get all instances of user certs */
 PK11CertListRootUnique = 2, /* get one instance of CA certs 
without a private key.

  * deprecated. Use PK11CertListCAUnique
  */
 PK11CertListCA = 3, /* get all instances of CA certs */
 PK11CertListCAUnique = 4,   /* get one instance of CA certs */
 PK11CertListUserUnique = 5, /* get one instance of user certs */
 PK11CertListAll = 6 /* get all instances of all certs */
} PK11CertListType;

The cert->slot is still random. But you will get multiple cert list 
entries with the same CERTCertificate*, but a different appData, if you 
use the value that don't have "Unique" in the name.



OK, but you have the cert in your hand; it doesn't matter where it came
from as long as it's the right one. Hell, in OpenConnect I support
modes where the cert is in a file and only the key is in PKCS#11 or
TPM. Who *cares* where the cert came from?

It's only the *key* which really needs to be found in the right place,
since you have to *use* it from there, right?
In theory, yes, the slot for the key is what matters. The problem is if 
you use cert->slot to look for the key (or even a NULL slot, to search 
all slots).
You might end up with the "wrong" key object. Unlike for 
CERTCertificate, identical keys in multiple tokens don't share a single 
SECKEYPrivateKey object.
Of course, since the private key may not be extractable, it's not really 
possible to compare private keys between tokens. But you could match 
them by public key.
Fortunately, that is not an issue here, but the behavior is still 
confusing since it's different than for DER certs.


I believe there can be multiple SECKEYPublicKeyStr objects also, even if 
they are identical public keys, but not 100% sure.


I understand why 'key may not match the "token" in the original lookup'
might matter. Not clear why the others would matter — are those really
requirements that we should try to fulfil?
Well, the fact cert may not match "token" isn't necessarily an issue. 
But it's definitely an issue for the key.



I'd combine those final three into a single string. It can be a
filename (perhaps starting with 'file:'), it can be a PKCS#11 URI
starting with 'pkcs11:', or it can be another form, which can happily
include subject/issuer/serial in some combination.

But yes, that makes a certain amount of sense.

I'm glad :)



I plead ignorance with TPMs. Is there a technical reasons why you
couldn't manipulate TPM objects as PKCS#11 objects ?

I forget the precise details but it's to do with the different PINs and
the management thereof, IIRC. The model isn't directly compatible.

Thanks.

Yeah, it's a separate engine. Working on fixing that :)

And if you find any app shipped in Fedora which *doesn't* support it,
please do file a bug.
Since I don't use Fedora, that is unlikely. The Linux we support is 
either RHEL, or OEL which is some RH fork, not quite sure from what 
tree. Dev is mostly done on OEL.

Yeah, but solving it for PKCS#11 is still a very big step forward for
usability. On Linux platforms it still gives us *consistent* access to
a key either in a hardware token, or in a software token like GNOME-
keyring's or even the NSS user database in ~/.pki/nssdb (although
there's more work to be done before that's easy).

Yeah, AFAIK Firefox/Thunderbird still don't use DB in the user's 
directory. Also, they still don't use the sqlite DB.
Most server apps want to have a separate DB, also, in their own 
location, not the home dir.


Julien

--
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 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 there can only be one CERTCertificate*
> pointer for all of them, the only way to resolve the issue would be
> for the lookup function to return something other than just
> CERTCertificate* alone. PK11_ListCerts does that.

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 with unpredictable contents of cert->slot?

> > Hm, purely for finding the *cert*, why doesn't the token: prefix
> > resolve that?
> The token: prefix is only used as a starting point for the lookup.
> But if the same DER cert exists in multiple tokens, then the value of
> CERTCertificate->slot pointer is unpredictable.
> It may or may not match what was used during the lookup. Same issue
> for the nickname field.

OK, but you have the cert in your hand; it doesn't matter where it came
from as long as it's the right one. Hell, in OpenConnect I support
modes where the cert is in a file and only the key is in PKCS#11 or
TPM. Who *cares* where the cert came from?

It's only the *key* which really needs to be found in the right place,
since you have to *use* it from there, right?

> Basically, what it comes down to, is that if you use the following
> sequence :
> cert = PK11_FindCertFromNickname("token:subject")
> key PK11_FindKeyByCert(cert);
> 
> Your cert and key may not match the "token" in the original lookup
> string. cert->slot and key->slot may not match.

I understand why 'key may not match the "token" in the original lookup'
might matter. Not clear why the others would matter — are those really
requirements that we should try to fulfil?

> Ultimately, when you are searching for a user cert, usually you want
> to locate the private key at the same time. It makes sense to combine
> the lookup for both.
> Some generic (non-PKCS#11 specific) lookup function to uniquely
> identify a cert and key could look like :
> bool FindCertAndKey(Cert** outCert, Key** outKey, const char*
> reqdSubject, const char* optionalIssuer, const char* optionalSerial);
> And if you want to make it PKCS#11 specific, add some sort of
> identifier for the module and/or token.

I'd combine those final three into a single string. It can be a
filename (perhaps starting with 'file:'), it can be a PKCS#11 URI
starting with 'pkcs11:', or it can be another form, which can happily
include subject/issuer/serial in some combination.

But yes, that makes a certain amount of sense.

> I plead ignorance with TPMs. Is there a technical reasons why you
> couldn't manipulate TPM objects as PKCS#11 objects ?

I forget the precise details but it's to do with the different PINs and
the management thereof, IIRC. The model isn't directly compatible.

> I'm pretty sure the PKCS#11 support in OpenSSL is optional, and many
> apps don't use it.

Yeah, it's a separate engine. Working on fixing that :)

And if you find any app shipped in Fedora which *doesn't* support it,
please do file a bug.

>  NSS is the one that stands out in terms of requiring it - something
> that wasn't always true. In a world where many vendors no longer
> provide PKCS#11 libraries for their devices, the value of PKCS#11 has
> diminished. And of course, there are other kinds of keystores like
> JKS, etc.

Yeah, but solving it for PKCS#11 is still a very big step forward for
usability. On Linux platforms it still gives us *consistent* access to
a key either in a hardware token, or in a software token like GNOME-
keyring's or even the NSS user database in ~/.pki/nssdb (although
there's more work to be done before that's easy).

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

[Julien Pierre]

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(), perhaps we can make sure that
> PK11_FindCertsFromUri() doesn't have the same problems for you.

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 there can only be one CERTCertificate* pointer for all of them, the 
only way to resolve the issue would be for the lookup function to return 
something other than just CERTCertificate* alone. PK11_ListCerts does that.


> Some applications use PK11_FindCertFromNickname, and others don't.
> The API call is really treacherous in what it does, and the results are 
> really not well-defined in ambiguous cases - for example, if a cert and 
> key exists in multiple tokens.

>Hm, purely for finding the *cert*, why doesn't the token: prefix
>resolve that?

The token: prefix is only used as a starting point for the lookup.
But if the same DER cert exists in multiple tokens, then the value of 
CERTCertificate->slot pointer is unpredictable.
It may or may not match what was used during the lookup. Same issue for the 
nickname field.

>Hm. I see you making an explicit attempt to find a private key in the
>*same* token that the cert came from, and I understand the need for
>that. What I'm missing though, is the reason you can't use
>PK11_FindCertsFromNickname() to find the *cert*. I'm missing the
>difference in behaviour that your servnss_get_cert_from_nickname() has.

The difference that servnss_get_cert_from_nickname has is that it uses 
PK11_ListCerts, and checks the nickname against the certlist's entry's appData 
field.
PK11_FindsCertsFromNickname doesn't work the same way. Also, the optional 
arguments to servnss_get_cert_from_nickname let it determine whether to search 
for user certs or non-user certs, and whether to pass in a pre-existing cert 
list or not, as PK11_ListCerts is an expensive call.

Even if the cert lookup function ultimately returns a CERTCertificate in this 
case, you still need to find the corresponding key. It's possible for the cert 
and key to live in different tokens. That wouldn't be the intended usage, so we 
forbid it. If you use PK11_FindKeyByCert

Basically, what it comes down to, is that if you use the following sequence :
cert = PK11_FindCertFromNickname("token:subject")
key PK11_FindKeyByCert(cert);

Your cert and key may not match the "token" in the original lookup string.
cert->slot and key->slot may not match.

And both of these slots could differ from the PK11SlotInfo that matches the 
"token" of the original lookup.
The goal of the code I wrote was to ensure that the cert and key in the 
intended device were used, even when multiple copies existed.

Even if you use the alternate sequence :
cert = PK11_FindCertFromNickname("token:subject")
slot = cert->slot
key PK11_FindKeyByCertInSlot(cert, cert->slot);

It's no better, since cert->slot may not match "token".

The code I wrote properly allows, for example the use of multiple HSMs or SSL 
accelerators from different vendors within one process, for different virtual 
servers, in combination with the softoken. It may be convoluted, but this was 
actually tested. I believe the code is also used as part of the admin UI that 
manages among other things, trust flags for certs.

Ultimately, when you are searching for a user cert, usually you want to locate 
the private key at the same time. It makes sense to combine the lookup for both.
Some generic (non-PKCS#11 specific) lookup function to uniquely identify a cert 
and key could look like :
bool FindCertAndKey(Cert** outCert, Key** outKey, const char* reqdSubject, 
const char* optionalIssuer, const char* optionalSerial);
And if you want to make it PKCS#11 specific, add some sort of identifier for 
the module and/or token.

>(Well, there's the TPM, and GnuTLS has a 'tpm:…' identifier string
>which references objects there. And TPM really *doesn't* fit well into
>the PKCS#11 model. So yeah, perhaps I might one day find myself trying
>to standardise a 'TPM URI' and ensure that it's supported consistently.
>But that day isn't imminent :)

I plead ignorance with TPMs. Is there a technical reasons why you couldn't 
manipulate TPM objects as PKCS#11 objects ?

>The scope of what I'm doing here, across GnuTLS, OpenSSL and NSS, is
>"where objects are identified in a PKCS#11 store, they can be
>identified by a RFC7512 identifier string instead of just some random
>home-grown application-specific or crypto-library-specific form."

I'm pretty sure the PKCS#11 support in OpenSSL is optional, and many apps don't 
use it. NSS is the one that stands out in terms of requiring it - 

Re: RFC7512 PKCS#11 URI support

[David Woodhouse]

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 identify an object of any single type.
> Even if it did, you would still need to uniquely identify the token 
> first, and combine it with one or more of those other attributes.
> Seems like the PKCS#11 URI support is supposed to be that unique ID.
> So, you need a string like :
> token_identifier : pkcs_uri

Nono, the PKCS#11 URI also allows you to specify the token by its
attributes too. Apologies for omitting that information.

> > So I'd *expect* your users to put a PKCS#11 URI into your server config
> > file. That is the *standard* form for identifying such objects. And I'd
> > expect them to file a bug if it doesn't work.
>
> It would only be a bug if the application claimed to comply with that 
> RC, which obviously can't be the case for applications that predate it.

The English language needs a new noun, to cover "a missing expected
feature which some consider a bug because it *shouldn't* be missing,
but which in the historical context some would prefer to call a new
feature." :)

Let's not get hung up on the terminology — whether you call it a bug or
a feature is all about context. And timing.

> > 
> > It's that bug which we're trying to fix, by making it easy (and in most
> > cases a no-op) for NSS-using applications to do the Right Thing. Just
> > like it's trivial with GnuTLS and relatively easy with OpenSSL (now
> > that I've mostly fixed OpenSSL's ENGINE_PKCS11).
>
> Well, it isn't going to be a no-op. 

I won't be a no-op for you. Thanks for the coherent and specific
explanation. However, it *will* be a no-op for a number of other
applications, just as I understand the historical addition of the
'token:' part was. The user-provided strings are just passed through
from config file or command line, and the application didn't even need
to notice.


> I think it would be best to have a new, well-defined API to 
> uniquely identify a cert, rather than try to fit the new scheme into
> existing APIs that run into ambiguity and sometimes make strange and
> unexpected choices, choices that may not be what the application
> expects.

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(), perhaps we can make sure that
PK11_FindCertsFromUri() doesn't have the same problems for you.

I do think it *also* makes sense to extend PK11_FindCertsFromNickname()
to accept the PKCS#11 URI though, so that it *can* be a no-op for a
large number of applications.

> Some applications use PK11_FindCertFromNickname, and others don't.
> The API call is really treacherous in what it does, and the results are 
> really not well-defined in ambiguous cases - for example, if a cert and 
> key exists in multiple tokens.

Hm, purely for finding the *cert*, why doesn't the token: prefix
resolve that?

> For this reason, in iPlanet web server, I wrote an alternate version of 
> this call that better suits the needs of the application.  This is 
> really old code, maybe 15 years or so.
> 
> You take a look at it at :
> https://github.com/jvirkki/heliod/blob/master/src/server/base/sslconf.cpp#L175
> https://github.com/jvirkki/heliod/blob/master/src/server/base/servnss.cpp#L860
> 
> Gory details, I know, but the point was to deal the possibility of keys 
> and certs in multiple tokens, and the CERTCertificate's unique slot 
> pointer pointing to a different slot than requested in the 
> token:nickname string, if the private key in several places.

Hm. I see you making an explicit attempt to find a private key in the
*same* token that the cert came from, and I understand the need for
that. What I'm missing though, is the reason you can't use
PK11_FindCertsFromNickname() to find the *cert*. I'm missing the
difference in behaviour that your servnss_get_cert_from_nickname() has.

> Of note, also, is that not all applications are strictly PKCS#11 
> exclusive. Certs and keys can sometimes live in other stores that are 
> not managed by PKCS#11 module. Not in NSS applications, mind you, but 
> such applications are out there.
>
> ...
> 
> I'm not completely sure if an RFC is the right place to try to dictate 
> the needs of applications, to be honest. But if there is going to be a 
> standard, IMO, at least, it should account for the possibility that 
> cert/keystores other than PKCS#11 exist.

All true (including the elided parts). But let's solve one thing at a
time :)

The RFC doesn't dictate the needs of applications. All it does is
define a standard identifier string for referencing PKCS#11 objects.

In the case where the key store *is* PKCS#11, having a standard way to

Re: RFC7512 PKCS#11 URI support

[Julien Pierre]

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 token:subject - still does not
uniquely identify a certificate.

... 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 identify an object of any single type.
Even if it did, you would still need to uniquely identify the token 
first, and combine it with one or more of those other attributes.

Seems like the PKCS#11 URI support is supposed to be that unique ID.
So, you need a string like :
token_identifier : pkcs_uri

And have the CKA_CLASS be implicitly set to certificate, and then the 
application can just look for the corresponding private key, in the same 
token - .


But you would still have to define the format of the string this way in 
your application . It could be two separate strings, one for token and 
one for ID, or a combination string, or something else.
The existing usage for the nickname string in those apps is not defined 
that way, though. Trying to change it may result in unexpected behavior.





)


The idea of the changes we're making (in NSS and elsewhere) is that
regardless of which crypto library is being used, users should be able
to specify certs/keys/etc. by their PKCS#11 URI in a manner which is
consistent across *all* applications.

So I'd *expect* your users to put a PKCS#11 URI into your server config
file. That is the *standard* form for identifying such objects. And I'd
expect them to file a bug if it doesn't work.
It would only be a bug if the application claimed to comply with that 
RC, which obviously can't be the case for applications that predate it.


It's that bug which we're trying to fix, by making it easy (and in most
cases a no-op) for NSS-using applications to do the Right Thing. Just
like it's trivial with GnuTLS and relatively easy with OpenSSL (now
that I've mostly fixed OpenSSL's ENGINE_PKCS11).
Well, it isn't going to be a no-op. I think it would be best to have a 
new, well-defined API to uniquely identify a cert, rather than try to 
fit the new scheme into existing APIs that run into ambiguity and 
sometimes make strange and unexpected choices, choices that may not be 
what the application expects.

Some applications use PK11_FindCertFromNickname, and others don't.
The API call is really treacherous in what it does, and the results are 
really not well-defined in ambiguous cases - for example, if a cert and 
key exists in multiple tokens.
For this reason, in iPlanet web server, I wrote an alternate version of 
this call that better suits the needs of the application.  This is 
really old code, maybe 15 years or so.


You take a look at it at :
https://github.com/jvirkki/heliod/blob/master/src/server/base/sslconf.cpp#L175
https://github.com/jvirkki/heliod/blob/master/src/server/base/servnss.cpp#L860

Gory details, I know, but the point was to deal the possibility of keys 
and certs in multiple tokens, and the CERTCertificate's unique slot 
pointer pointing to a different slot than requested in the 
token:nickname string, if the private key in several places.
So, regardless of what changes you make to PK11_FindCertFromNickname or 
not, it's not going to make this scheme work in iWS (or OTD 11g).
The proper way would be a new API, explicitly defined, and for 
applications to make proper use of it, and define the string fields in 
their config files appropriate to their own needs. I'm speaking as both 
application developer and former NSS developer, here.
Of note, also, is that not all applications are strictly PKCS#11 
exclusive. Certs and keys can sometimes live in other stores that are 
not managed by PKCS#11 module. Not in NSS applications, mind you, but 
such applications are out there.
PKCS#11, and the layers on top of it, is inefficient in terms of 
runtime. Most accelerator vendors, and even some HSM vendors, have 
completely given up support for PKCS#11 for this reason. IMO, trying to 
design a "universal" configuration string in a world where not all 
applications are PKCS#11 is doomed to fail. OTD 12c for example does not 
use NSS and does not support PKCS#11, and has moved away from the 
token:nickname string. It uses PKCS#12 wallets as keystores, and a 
triplet of "subject:issuer:serial" as the identifier for certs and keys. 
Only subject is required, issuer and serial are optional. Unlike 
PK11_FindCertFromNickname, if there is any ambiguity, the server does 
not choose an arbitrary cert and key based on guesses of the library, 
but instead fails to come up and asks the administrator to correct the 
ambiguity by uniquely identifying the cert and key it actually wants to 
use (and it lists all of them if log is verbose, also). PKCS#11 support 
may 

Re: RFC7512 PKCS#11 URI support

[David Woodhouse]

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

This sounds like it's fairly much the use case that we are thinking of,
when we suggest that APIs like PK11_FindCertFromNickname() should start
to accept RFC7512 identifiers (aka PKCS#11 URIs) too.

Firstly, don't get confused by the term 'URI'. It's not "go download
your cert/key from the Internet". It's just a string identifying which
object should be used, from which existing token. (It's a URN, not a
URL. But really, that whole can of worms is best avoided, so think of
it just as an 'identifier string').

It's basically identical in scope to the existing 'token:nickname'
string. Except for the fact 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.

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

(I say "mostly" because it doesn't include CKA_SERIAL_NUMBER which you
asked for. I discussed that with the author of RFC7512 (your colleague)
a while ago; see
http://mozilla.6506.n7.nabble.com/NSS-support-for-RFC7512-PKCS-11-URIs-td339011.html#a33925
)


The idea of the changes we're making (in NSS and elsewhere) is that
regardless of which crypto library is being used, users should be able
to specify certs/keys/etc. by their PKCS#11 URI in a manner which is
consistent across *all* applications.

So I'd *expect* your users to put a PKCS#11 URI into your server config
file. That is the *standard* form for identifying such objects. And I'd
expect them to file a bug if it doesn't work.

It's that bug which we're trying to fix, by making it easy (and in most
cases a no-op) for NSS-using applications to do the Right Thing. Just
like it's trivial with GnuTLS and relatively easy with OpenSSL (now
that I've mostly fixed OpenSSL's ENGINE_PKCS11).

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

I don't think you really have — it cuts to the heart of what we're
actually trying to do here.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



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

[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

Re: RFC7512 PKCS#11 URI support

[Ryan Sleevi]

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 be able to provide without disappearing into handwaving and
> hyperbole. So I'll take that as a 'no'. Thanks anyway.

David, are such remarks necessary? Do you believe they help creative a
positive community around NSS development? If you disagree, you can
disagree and say so. There are plenty of positive ways to do so, and
so such remarks are entirely unnecessary and contribute to a toxic
environment. There are plenty of perfectly professional ways to
disagree, but you don't seem interested in them.

I understand and appreciate that you want the standard to be "Show me
the code." But that's not the standard we set. If it was, there are
plenty of changes that NSS could have done that would have broken Red
Hat's customers - but we intentionally chose to take the path of least
breakage and risk, because that's what having a public, stable API is
about.

It's one thing to disagree, it's another to be unnecessarily rude and
dismissive. I do hope you can see the difference, and might think more
carefully about the type of behaviour you're encouraging by
practicing.
-- 
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: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 started returning
PKCS#11 URIs to applications where they expect nicknames — but not once
did you give a straightforward example of a *specific* *problem* which
would be caused by PK11_FindCertsFromNickname() accepting a PKCS#11
URI. Even in the case of applications which *do* accept unconstrained
user input, and *don't* treat it as opaque.

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 be able to provide without disappearing into handwaving and
hyperbole. So I'll take that as a 'no'. Thanks anyway.

-- 
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 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 working".
>
> What's missing from your argument is the bit where you explain why it's
> *bad* for an explicitly user-entered PKCS#11 URI to suddenly start
> working. That was, after all, the *point* of suggesting that the
> existing functions should be changed to accept such.

I've already tried to explain this several times to you. I don't feel
there's anything more useful to contribute. I'm not sure if you don't
understand, or you're not convinced, but in either event, I have
neither the time nor energy to continue to try to convince you,
especially when you seem fundamentally opposed to exploring or
articulating the reasons why not to pursue alternatives.

There are plenty of useful features we've introduced that are opt-in
by default, especially when their enablement leads to observable
changes. This is even true of security-relevant changes, due to the
potential to cause unexpected harm. You clearly don't seem interested
in taking a conservative or responsible choice - such as allowing
applications that wish to support PKCS#11 URIs to opt-in.

In any event, there's nothing more to say here, I remain opposed to
this change, and I feel I've given you enough good faith, in spite of
the original belligerence, in this to have made an attempt to explain
to you those reasons and concerns.
-- 
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 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.
> 
> If we can't agree on that, then it's no surprise that you don't agree
> with or appreciate the objections, but I'm not sure what more can be
> said, or needs to be said. It seems we've reached an ideological
> impasse.

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

What's missing from your argument is the bit where you explain why it's
*bad* for an explicitly user-entered PKCS#11 URI to suddenly start
working. That was, after all, the *point* of suggesting that the
existing functions should be changed to accept such.

-- 
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 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 you any kind of nonsense.

And if you try to filter out that non-sense - for example, relying on
that format - you end up with bad results. If you try to act upon that
user data, on the assumption it follows the format - you end up with
bad results.

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.

If we can't agree on that, then it's no surprise that you don't agree
with or appreciate the objections, but I'm not sure what more can be
said, or needs to be said. It seems we've reached an ideological
impasse.
-- 
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 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
> > actually does something useful.
> No, sorry David, that's not how we've done stuff in NSS.
> 
> When it has an observable difference, when it breaks the contract
> previously provided, we prefer not to do so.
> 
> The contract that NSS has lived by is that applications have had to
> know about the token:nickname vs nickname rule in the APIs. When you
> get a nickname for a cert, depending on the function used, you may or
> may not have to add the token. If you don't, you get bad results.

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 you any kind of nonsense.

> So we've had an API contract that the nicknames input to this function
> have a syntax and format, because applications have to be aware of how
> to construct it. Because applications have to be aware of how to
> construct it, applications also have to be aware of how to deconstruct
> it.

Many applications don't, and just pass the nickname provided by the
user into NSS to select a certificate. Those are the cases which would
benefit from having PK11_FindCertsFromNickname transparently take a
PKCS#11 URI. The application automatically starts accepting the
standard form for specifying PKCS#11 objects. Yay!

Other applications may do this kind of deconstruction, and those
applications explicitly *don't* support PKCS#11 URIs; only NSS
nicknames. for the user to enter a PKCS#11 URI into their configuration
would be an error. It would look like a nickname referencing a token
named 'pkcs11', which almost certainly doesn't exist.

I'm having difficulty imagining what the problem is though. Let's
assume that a user *does* provide a PKCS#11 URI to one of the latter
class of applications, which really does want a nickname. Either the
application will fail to parse it (or say "there is no token named
'pkcs11'") and won't pass it to NSS at all, in which case nothing
harmful has happened. Or the application passes it to NSS anyway, and
it works as the user presumably intended. In which case nothing harmful
has happened.

Where's the problem?

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

When it has an observable difference, when it breaks the contract
previously provided, we prefer not to do so.

The contract that NSS has lived by is that applications have had to
know about the token:nickname vs nickname rule in the APIs. When you
get a nickname for a cert, depending on the function used, you may or
may not have to add the token. If you don't, you get bad results.

So we've had an API contract that the nicknames input to this function
have a syntax and format, because applications have to be aware of how
to construct it. Because applications have to be aware of how to
construct it, applications also have to be aware of how to deconstruct
it.

For example, it's required when importing certs that you don't
duplicate a nickname. So code that imports certs (such as from PFX
files) needs to be able to handle nickname collisions, so it needs to
be able to construct them. Introducing an overloading syntax of
PKCS#11 URIs could also lead to issues there (there's the
CERT_MakeCANickname function, but that doesn't handle the
token:nickname construct). A public API example is
SEC_PKCS12DecoderValidateBags.

This is why I'm arguing that "nickname" is not 'opaque' - you have to
know about the construction to get proper API behaviour - especially
because two public APIs, CERT_FindCertByNickname and
PK11_FindCertFromNickname, will return different results depending on
the construction. PK11_FindCertFromNickname will *only* search that
token, and only return *that* cert, while CERT_FindCertByNickname will
potentially return temporary/in-memory certs if you don't include the
token qualifier.

>
> And the latter is what we're talking about here. If you provide a
> PKCS#11 URI as the 'nickname', that will *fail* right now. And the
> proposal is that such a call will no longer fail.

I'm aware. And in doing so, you're breaking the API contract as to
what the format is to this function. If this was meant to be an opaque
format, and applications were "doing the wrong thing" by reaching into
it, you could make an argument that they were doing it wrong, it was
always opaque, and that it's fine to break them.

However, you can't just go change the format. API compatibility is
more than just ABI compatibility - it's about whether the
preconditions and postconditions hold. And allowing the input to be
different breaks the API preconditions as to what format the nickname
will be in, and those preconditions have indeed propagated into
NSS-using applications.
-- 
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 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 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.

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.

And the latter is what we're talking about here. If you provide a
PKCS#11 URI as the 'nickname', that will *fail* right now. And the
proposal is that such a call will no longer fail.

(I'd have to check the nickname rules, but there might be a corner case
where you have a token named 'pkcs11' and a carefully-contrived
nickname which actually makes it a full URI. Which is easily handled
simply by saying that the original NSS form takes precedence. Or indeed
that *whenever* a token is named 'pkcs11' the PKCS#11 URI parsing is
disabled. It's a contrived case anyway).

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

[David Woodhouse]

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 ask for one with a new API — or unless you take untrusted
> > input from the user or an editable config file, of course.
> Exactly so. You fail to realize this as a change, but it's exactly that.
> 
> > 
> > I certainly don't see how it could cause you to display such URIs
> > directly to the user, as you suggest.
> So tell me, what do you expect an application to do that displays the
> results from parsing such a configuration (for example, it reads from
> a config file "token:nickname", parses that value, and displays GUI
> for "token" and "nickname")? Is your belief that this is not an
> acceptable usage of the NSS API, and not a guarantee of the NSS API
> contract? Then just say that, and we can have a productive
> conversation. But it should be terribly simple, and not require any
> creativity or imagination, to see how such a scheme would be broken in
> the introduction of "pkcs11:token=Foo;object=bar;" - the UI would
> result in the token of "pkcs11" and the 'nickname' of
> 'token=Foo;object=bar".

In the case you describe, the user might *already* enter a PKCS#11 URI
instead of a nickname. Take a look at cURL, for example — with open
bugs for the NSS-built version, because it doesn't take certificate
specifiers in that form when the GnuTLS-built version *does*. Those
bugs were filed because people are *already* trying to feed PKCS#11
URIs to NSS applications, and NSS is failing to work.

So what actually happens? Yes, if we parse the token:nickname and
display it to the user as you describe, then we'll display something
odd. Always true, before or after my proposed changes.

My proposed changes would make no difference to that cosmetic issue;
what they *would* do is make the PKCS#11 URI specified by the user
actually *work* instead of failing.

So your cosmetic argument above, while true, is not particularly
interesting. It is *just* cosmetic, and exists already. (And not in
Chrome, as far as I'm aware. Or indeed anywhere in reality. Feel free
to contract me, but with references only).

I'm more interested in whether there's a case where we *wouldn't* want
NSS to actually work. After all, if the user gets to specify arbitrary
strings to identify the certificates they want you to use, why would
you not honour that?

That's why I asked you for specifics about the "filtering" that you do.
Which I note you failed to provide.

But even so, unless you were going to permit the user to specify *any*
object in a token named 'pkcs11', I don't see how the filtering comes
to any harm either.

-- 
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 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 from the user or an editable config file, of course.

Exactly so. You fail to realize this as a change, but it's exactly that.

> I certainly don't see how it could cause you to display such URIs
> directly to the user, as you suggest.

So tell me, what do you expect an application to do that displays the
results from parsing such a configuration (for example, it reads from
a config file "token:nickname", parses that value, and displays GUI
for "token" and "nickname")? Is your belief that this is not an
acceptable usage of the NSS API, and not a guarantee of the NSS API
contract? Then just say that, and we can have a productive
conversation. But it should be terribly simple, and not require any
creativity or imagination, to see how such a scheme would be broken in
the introduction of "pkcs11:token=Foo;object=bar;" - the UI would
result in the token of "pkcs11" and the 'nickname' of
'token=Foo;object=bar".
-- 
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 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.

If we can't agree on these first principles, there's no point in
discussing Chrome's behaviour, because it simply builds upon them.
-- 
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 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 nickname.
> 
> This is basic, so I'm not sure why you're suggesting it doesn't change.

My understanding is that in your environment there are only *ever* the
traditional nicknames. There are no PKCS#11 URIs. So your filtering
doesn't need to change, does it? Can you provide a specific reference
to the filtering that you do, and what it achieves? Your description is
still insufficiently specific for me to understand the failure mode
you're concerned about.

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?

FWIW a PKCS#11 URI will always start with 'pkcs11:', so the only
prospect for collision is if there is a token whose name is 'pkcs11'.
Which is both unlikely, and easily handled in a manner which gives
precedence to the original 'token:nickname' format.

> > ... which would cause us to display such URIs directly to the user.
> > 
> > No. As repeatedly stated, we were *only* talking about allowing
> > functions like PK11_FindCertsFromNickname() to accept a RFC7512
> > identifier (PKCS#11 URI) in *addition* to the existing NSS nickname
> > form. There is *no* way that such a change could possibly have the
> > effect you describe.
> 
> See above. I just described to you how it can and would happen.

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 from the user or an editable config file, of course.

I certainly don't see how it could cause you to display such URIs
directly to the user, as you suggest.

> > Separately, we would also want to add new functions to obtain the
> > RFC7512 identifier for a given object. But obviously those *couldn't*
> > overload the existing functions to get nicknames; that would be silly.
> 
> And yet it would do exactly that, when indirected through a persistence
> layer, which is part of the justification for this change. If the "get the
> nickname from this config" returns a URI, which was explicitly part of the
> justification for his change, 

...                            (Reference please)

What we said was that we want applications (and libraries) like cURL to
Just Work if they are provided with a standard PKCS#11 URI on their
command line (or in their config file) in place of the existing NSS-
specific nickname. 

Yes, if the user can edit your config files and *introduce* arbitrary
strings of their own choice, then you might see a PKCS#11 URI.
Otherwise, you'll never see one.

This whole thing should basically be a no-op for a purely GUI program
like the browser. You'll *never* see a PKCS#11 URI, you'll never even
have cause to notice that PK11_FindCertsFromNickname() *would* have
accepted one, if you were to pass it one. Because you won't.

You enumerate objects and obtain their (traditional) nickname as you do
so, and as the user selects them in a GUI. If you do store the string
in a persistent fashion, that's still the NSS nickname, never a PKCs#11
URI. You basically shouldn't *notice* the change. It isn't for you. The
design goal is basically that you shouldn't notice it.

>  then it very much is a
>  change of a "get the nickname" function.

Again, please be specific. What, exactly, is it that you think is going
to break? A worked example with function names, please. Preferably with
a specific reference to the existing source code.

-- 
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 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 you telling a deliberate untruth.


Then you can realize there are dozens of ways to state that in a more
productive, less combative tone. Although you seem to believe the ends
justified the means.


> > Chrome has logic to preparse the nickname, which NSS does have an
> > internal format for, because it can affect how we present and how we
> > search. In some APIs, you need to prefix the nickname with the token
> > name, while  simultaneously, for our UI needs, we need to filter out
> > the token name before showing it to the user.
>
> None of which is proposed to change.


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

This is basic, so I'm not sure why you're suggesting it doesn't change.

>
> No. As repeatedly stated, we were *only* talking about allowing
> functions like PK11_FindCertsFromNickname() to accept a RFC7512
> identifier (PKCS#11 URI) in *addition* to the existing NSS nickname
> form. There is *no* way that such a change could possibly have the
> effect you describe.


See above. I just described to you how it can and would happen.

>
> Separately, we would also want to add new functions to obtain the
> RFC7512 identifier for a given object. But obviously those *couldn't*
> overload the existing functions to get nicknames; that would be silly.


And yet it would do exactly that, when indirected through a persistence
layer, which is part of the justification for this change. If the "get the
nickname from this config" returns a URI, which was explicitly part of the
justification for his change, then it very much is a change of a "get the
nickname" function.


> > 


Seriously? You're being extremely unhelpful David. Do you really think this
positively contributes? You're actively trying to needle, which is entirely
unhelpful to your goal.

>
> Regardless of tone, please try to pay attention to the actual issues,
> and make sure that you're not arguing against a straw man.


Please take your own advice into consideration before replying.
-- 
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 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
> > statement was false, and design accordingly.
> >
> > I certainly can't see how it could have any basis in reality.

> Those sort of statements don't encourage productive discussion -
> "You're a liar and I will ignore you and break you if you don't do
> what I want, because I don't understand". This will be my last reply,
> given that. I would hope in the future you might be more helpful in
> tone and tenor.

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 you telling a deliberate untruth.

While I thank you for your advice on tone, I had already tried asking
you to elaborate, and that had failed. This one elicited a response
fairly promptly :)

> Chrome has logic to preparse the nickname, which NSS does have an
> internal format for, because it can affect how we present and how we
> search. In some APIs, you need to prefix the nickname with the token
> name, while  simultaneously, for our UI needs, we need to filter out
> the token name before showing it to the user.

None of which is proposed to change.

> Introducing the URI code in the existing functions would be breaking
> NSS's implicit and explicit API contracts, and would cause us to
> display such URIs directly to the user.

No. As repeatedly stated, we were *only* talking about allowing
functions like PK11_FindCertsFromNickname() to accept a RFC7512
identifier (PKCS#11 URI) in *addition* to the existing NSS nickname
form. There is *no* way that such a change could possibly have the
effect you describe.

Separately, we would also want to add new functions to obtain the
RFC7512 identifier for a given object. But obviously those *couldn't*
overload the existing functions to get nicknames; that would be silly.

> 

If I could give my own advice on how to communicate, to reciprocate the
favour — I am *actively* trying to find nuggets of anything helpful or
correct in your responses, rather than just ignoring you — but I'm
finding it hard.

Regardless of tone, please try to pay attention to the actual issues,
and make sure that you're not arguing against a straw man. In this
case, not for the first time, you seem to be arguing against something
that wasn't even being proposed. It would help if you would be
*specific* about any objections you have, rather than making it take
weeks to work out what your misconception is. Otherwise, it just comes
across as wilful obstructionism. Like when you spent ages telling me
that I didn't understand the Chrome security model, and eventually we
managed to work out that you'd ignored the bit in my *first* message
where I explicitly acknowledge that we'd want NSS_NoDB_Init() to do the
right thing, and you were wrong about that all along too.

Thanks.

-- 
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 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 it could have any basis in reality.

Those sort of statements don't encourage productive discussion - "You're a
liar and I will ignore you and break you if you don't do what I want,
because I don't understand". This will be my last reply, given that. I
would hope in the future you might be more helpful in tone and tenor.

Chrome has logic to preparse the nickname, which NSS does have an internal
format for, because it can affect how we present and how we search. In some
APIs, you need to prefix the nickname with the token name, while
simultaneously, for our UI needs, we need to filter out the token name
before showing it to the user.

Introducing the URI code in the existing functions would be breaking NSS's
implicit and explicit API contracts, and would cause us to display such
URIs directly to the user. This is, in my view, unacceptable as a
contribution.

I tried to productively encourage you to a path that won't break, and that
adheres to NSS's guarantees of stability, but it seems you actively desire
to change the behavior of existing APIs for NSS users.
-- 
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 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
> > (filtering or setting the token via parsing or adding to the token name,
> > respectively). This would definitely break Chrome's use of the API, and
> > for that, I think it should be an unacceptable change as it is not backwards
> > compatible.
> 
> Please could you explain the breakage? This should only change behaviour
> if you provide a "nickname" which happens to be a valid PKCS#11 URI to the
> PK11_FindCertFromNickname() function. Does Chrome do that, and depend on
> the failure that it gets? Otherwise, how could anything break?

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 it could have any basis in reality.

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

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

> NOT to use URIs as URIs

Is this a typo?

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

[Ryan Sleevi]

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, making a conscious decision NOT
>> to use URIs as URIs.
>>
>
> Could you clarify this statement?
>
> > NOT to use URIs as URIs
>
> Is this a typo?
>
> --
> John
>

No, it is not a typo.

Firefox, Chrome, and other browsers have been focused on
https://url.spec.whatwg.org as the IETF spec is inadequate and overbroad
and does not reflect the real world.

There's more to that story, but that's the simple answer.
-- 
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 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 distro is better" pissing match.


> For fun I tried removing it
> recently on OpenSuSE, Fedora and Ubuntu — in all cases it basically
> wanted to remove most of the distro. Running 'dnf remove p11-kit' won't
> even play any more on Fedora. It just tells me that would require
> removing systemd and dnf itself, and tells me 'no'.
>
> So my proposal that on platforms where p11-kit exists, NSS should just
> link to it. But also, to avoid having to build and ship a separate
> library on platforms which didn't already have it, I think we should
> *import* the URI handling code from libp11-kit. That is mostly isolated
> to one file, of 1305 lines which compiles to roughly 10KiB of code
> under Linux/x86_64.
>
> Does that seem like the correct approach?


I disagree that this seems like a wise or balanced tradeoff to fork this
file. The lessons of SQLite show this just increases maintenance costs and
leads to divergence. I respond to this more below.


> The other open question, although it doesn't block the work at the
> start of the project, is whether we should be extending
> PK11_FindCertFromNickname() to accept RFC7512 URIs or whether we should
> *only* accept URIs in a new function.


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,
respectively). This would definitely break Chrome's use of the API, and for
that, I think it should be an unacceptable change as it is not backwards
compatible.

On the topic itself, of support PKCS#11 URIs, I remain opposed, and I would
appreciate Richard's take on it. For Chrome, such a feature would have been
useless for our Windows and Mac ports, and *is* useless for our iOS and
ChromeOS ports. Further, we would not expose this functionality for our
Linux port even if it existed, due to cross-platform considerations. 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.
Anne on the Mozilla side has been working that effort, and can probably
speak more to that effort.

I would much rather that if this is introduced, it is done so behind a
compile time flag, and it's interactions with NSS as a whole kept as a
minimum. I understand and appreciate why Fedora/RHEL distros are interested
in this, but I don't believe it's something that Chrome would want, and I
don't believe it's likely something Firefox would want to ship when it
packages NSS, especially on non-Linux platforms.
-- 
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]

> 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,
> respectively). This would definitely break Chrome's use of the API, and
> for
> that, I think it should be an unacceptable change as it is not backwards
> compatible.

Please could you explain the breakage? This should only change behaviour
if you provide a "nickname" which happens to be a valid PKCS#11 URI to the
PK11_FindCertFromNickname() function. Does Chrome do that, and depend on
the failure that it gets? Otherwise, how could anything break?


> I would much rather that if this is introduced, it is done so behind a
> compile time flag, and it's interactions with NSS as a whole kept as a
> minimum. I understand and appreciate why Fedora/RHEL distros are
> interested
> in this, but I don't believe it's something that Chrome would want, and I
> don't believe it's likely something Firefox would want to ship when it
> packages NSS, especially on non-Linux platforms.

I can live with that. On platforms without p11-kit, the functions can be
absent or stubs which return failure.


-- 
dwmw2

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