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