Groups - Kem Algorithms uploaded

[Robert Relyea<rrelyea@redhat.com>]

        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