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 [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
