Re: RFC7512 PKCS#11 URI support

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

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