Re: RFC7512 PKCS#11 URI support

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

-- 
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto