FindKeyPair assumes that the public and private keys have the same labels (YubiKey)

[DanGe42]

I have a YubiKey 5 Nano, which I provision using yubico-piv-tool. For reasons, we generate our key pair with openssl, and then use yubico-piv-tool --slot=9a --action=import-certificate --input=path/to/public.crt and yubico-piv-tool --slot=9a --action=import-key --input=path/to/private.pem to import the public and private keys.

This CLI tool appears to set its own hard-coded labels; there might or might not be a Good Reason for that. Either way, it sets the labels of the private key and the public key to "Private key for PIV Authentication" and "Public key for PIV Authentication", respectively, though it keeps the object IDs of the keys equal. (This is documented here)

This vendor decision breaks the assumption in makeKeyPair that the private and public keys must have the same labels. This means that even if I happen to know that, for example, the ID of both keys is [1], calling ctx.FindKeyPair([]byte{1}, nil) will return nil, nil. (If I comment a few lines out of the findKeys helper earlier in that file, FindKeyPair is able to retrieve a valid key pair.) Unfortunately, this issue can be hard to diagnose because this block within FindKeyPairsWithAttributes swallows the error indicating that it couldn't find the public key.

If this is useful information, I'm using the PKCS11 shared module (libykcs11.dylib on my Mac) that comes bundled with yubico-piv-tool.

I'm fairly new to this PKCS#11 world, so I don't know if this is an overly-strict assumption, if the vendor (Yubico) made an unconventional decision, or if my team has an unconventional workflow.

[DanGe42]

Closing this. Some time between August 2020 and now, things have changed, I've learned a bit more about how the standard works, and I've noticed that there's something in makeKeyPair that retries the public key lookup with only the ID if it cannot find an exact match with both ID and label. From my testing on a YubiKey and SoftHSM, FindKeyPair works now.