RE: [pkcs11] Groups - Kem Algorithms uploaded

Hi Bob,

I noticed the following wording that needs updates:

Occurrences of C_Encaspulate/C_Decaspulate, C_Decapslate, C_Encapsulated/C_Decapsulated, C_Enapsulate, Decapsulte across the 2 proposals
Proposal KEM Algorithms, section 1.4.2 Kyber public key objects: I suggest to include the attribute {CKA_ENCAPSULATE, &true, sizeof(true)} in the example
Proposal KEM Algorithms, section 1.4.3 Kyber private key objects: remove attribute {CKA_PARAMETER_SET, &param_set, sizeof(param_set)} from the example, as per definition the parameter set is not specified in the private key template

I have no additional topics for discussion than the ones you already brought up.

Best regards,

Dieter

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Robert Relyea
Sent: Wednesday, February 1, 2023 1:09 AM
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Groups - Kem Algorithms uploaded

Submitter's message
General decisions in this and the KEM API proposal which bear more discussion:

1) I called the new functions C_Encapsulate and C_Decapsulate rather than C_EncapsulateKey and C_DecapsulateKey. It might make sence to go with the former as it matches C_WrapKey, C_UnwrapKey, and C_DeriveKey.
2) I added C_Encapsulate/C_Decapsulate definitions several existing mechanisms: CKM_RSA_PKCS, CKM_RSA_OAEP, CKM_RSA_X509, CKM_ECDH_DERIVE, CKM_ECDH_COFACTOR_DERIVE, CKM_DH_DERIVE, CKM_DH_X9_42_DERIVE.
I didn't add C_Encapsulate/C_Decapsulate definitions for any of the RSA TPS mechanisms. The seemed pretty specific for TPS.
I didn't add C_Encapsulate/C_Decapsulate definitions for any of the ECDH/DH variants which use 2 keys (They don't really map to KEMS).
I added CKM_RSA_X509 KEM as the NIST RSASVE. It might make since, to define a separate mechanism fro RSASVE (which is KEM only).
3) For Kyber, I defined a single mechanism and key type and the Parameter set is an attribute of the key. I defined the parameter set as a PKCS #11 constant and not a set of parameters since the security of Kyber is tightly tied to getting the parameters correct (and it avoids issues we have with using parameterized curves in ECC).
I also defined the mechanism as providing Kyber.CPAPKE if used with wrap/unwrap. Should this really be a separate mechanism. The private key in Kyber CPAPKE is a subset of the CCAKEM private key. The public keys are identical. It's possible NIST will not define a public CPAPKE interface, but just define it as a primitive used to build CCAKEM.
Kyber key lengths are a bit a a mash. I chose the public key length as key length specified in C_MECHANISM_INFO, and set it's length to bytes (which is different than our existing public key algorithms, but consistent with all the new Post Quantum algorithm documentation).
I did not define any of the 90s Parameter sets (though everything is specified in a way that adding future parameter sets would not be difficult). it's even possible we could define experimental Parameter sets that match the Round 3 Proposal.
We could also define the parameter sets as an oid, and push the definition back to x509/ansi.
-- Mr. Robert Relyea

Document Name: Kem Algorithms

Description
Algorithms that can use the new Kem APIs
Download Latest Revision
Public Download Link

Submitter: Mr. Robert Relyea
Group: OASIS PKCS 11 TC
Folder: Working Drafts
Date submitted: 2023-01-31 16:09:14

pkcs11 message