Re: [pkcs11] KEM Comments

[Robert Relyea <rrelyea@redhat.com>]

On 5/10/23 7:35 AM, Jonathan Schulze-Hewett wrote:

I seem to be having trouble receiving all emails sent via the reflector. In particular, Bobâs donât come through for some reason. I apologize if anyone else has mentioned these.

Â

1. I prefer C_Encapsulate and C_Decapsulate over C_EncapsulateKey/C_DecapsulateKey. My understanding is that the value encapsulated, and the value output from decapsulation, should not be directly used as a key.

    Yup, they only generate keys.
    Â

1. pkcs11_kem_algs_draft2.pdf section 1.4.3, pkcs11_pq_sig_algs_2 sections 1.1.3, 1.2.3, and 1.3.3: Our applications start most operations in PKCS#11 with a certificate. They then attempt to find a private key on the device matching the certificate. For RSA this can be done by extracting the public key information from the certificate and then finding a RSA private key with matching public key information. For ECC, itâs a mess because thereâs nothing linking the public key to the private key other than the seldom used, and optional, CKA_PUBLIC_KEY_INFO. Please include enough information in the private key object for an application to find it with only the public key.

NSS also does everything based on the certificate. It does the private/public key matching with CKA_ID. The certificate, public key and private key should all have the same CKA_ID for NSS to be able to find the private key. NSS does not care what the CKA_ID is in this case.

In the provisioning case, NSS expects the CKA_ID of the private and public key to be a SHA1 hash of a public key component (Modulus for RSA, Value for most other public keys). NSS extracts the public key component from the cert, hashes it than tries to look up the keys by CKA_ID. (NOTE: this is why CKA_ID needs to be writable after create because NSS explicitly sets it after keygen.. it can't before because it doesn't know the public value. This is also why we created CKA_UNIQUE_ID, because there is a need to have a unique, token specific, persistent ID for each object in the token, and CKA_ID can not meet that requirement and still function in this way).

We should probably document these cases in the profiles document. (actually I think at least part of this is documented in the 'publicly readable keys' profile.

1. Iâm probably in the minority, but I prefer pkcs11_pq_sig_verify_multi_1âs approach.

    At this stage, you are in the majority since I haven't gotten any
    other feedback yet;). I personally lean towards it as an option
    (it's easier to back port, and the only real issue is we have the
    signature twice and have to decide what to do if they don't match).

Â

Sincerely,

Jonathan