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 reference an object is a massive improvement. Previously, there were too many different and bizarre schemes¹. Doing the same kind of standardisation for other key stores is perfectly possible, but out of scope for me right now, and especially in the context of NSS as you note. And it's less of a problem for other key stores anyway, because they don't have quite such a *wild* disparity of users as PKCS#11, and thus they don't have *so* many different ways of identifying objects therein. (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 :) 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." -- dwmw2 ¹ Some of which are shown at or linked from https://fedoraproject.org/wiki/PackagingDrafts/SSLCertificateHandling?rd=PackagingDrafts/PKCS11#Problem_statement
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
