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
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
