On 2/14/23 2:18 PM, JOHNSON Darren wrote: Hi Iâve added some questions/comments inline below in response to your comments. And here I have some additional questions/comments I had.  1)  I know this is an early draft, but there are grammatical mistakes (or just inconsistencies) where you added âand key encapsulation and key decapsulationâ. I sure this wasnât the your main focus for the draft. It's a draft toward voting on (once we've handled all the comments). Identify typos and mistakes are definitely worthwhile. as for the above text, the whole sentence with changes reads: It supports single-part encryption and decryption; single-part signatures and verification with and without message recovery; key wrapping and key unwrapping; and key encapsulation and key decapsulation. It's already unweildly, and my only goal was to add key encapsulation and key decapsulation I'm definitely open to suggestions on how to improve it. 2)  ECDH/DH. should we be more specific about the format of the returned public keys? Weâve had issues related to this in the paste. This may apply to some of the other KEM mechanisms too. I've added text that the ciphertext == public key is the same format as the public key in C_DeriveKey for this mechanism. Other KEMs are explicit in their spec what the format of ciphertext is. 3)  Kyber a.  Why did you choose to include wrap/unwrap using Kyber.CPAPKE yet exclude encrypt/decrypt? Its limitations? complexity? or you didnât see a need for it? It's really defined as a key wrap. it's security to wrap arbitrary data isn't as strong. If there is a need to I could include encrypt/decrypt. (There is a convenience case for using encrypt/decrypt... when you just want to token to do the math for you but not hold the key, I'm not sure if a lot of new protocols will add the key wrap version to them, though). b.  should the CKA_VALUE attribute really be a Big Integer? shouldnât it be a byte array given that it is a compressed and encoded polynomial? Good point, yes. c.  section 1.4.4, CKA_BASE and CKA_PRIME are used. I assume this is a type. Yup, a typo it should be CKA_PARAMETER_SET  And finally, below are other questions I received from various people at Thales. I didnât have time to review them internally with them. - (1.4.1 Definitions): Why introduce new CK_KYBER_PARAMETER_SET_TYPE (CKP_KYBER512, CKP_KYBER768, CKP_KYBER1024) attribute? I like it... but, why introduce this new parameter if we can reuse CKA_VALUE_LEN just like Symmetric keys do to determine strength (i.e. AES: 16, 24, 32)? Parameter sets are 1) not the same as key lengths, and 2) do not have unique key lengths. These values are tied to the public and private keys since the keys are uniquely generated with a parameter set (and must only be used in that parameter set). Think of them as 'curves' in ECC. In this spec I've updated it to make it clear only ROUND3 is defined now. In the future, when the NIST SPEC is out I'll include the SP 800 versions of this. I've renamed the CKP_KYBERxxx parameter set to include _ROUND3 to make it clear the difference between them and the final set.  - (1.4.2 Kyber public key objects): The Kyber public key should have the CKA_ENCAPSULATE attribute set during creation. Just like the private key template has CKA_DECAPSULATE: {CKA_ENCAPSULATE, &true, sizeof(true)},  - (1.4.3 Kyber private key objects): The statement below does NOT match the example attribute template. It DOES contain CKA_PARAMETER_SET Note that when generating a Kyber private key, the parameter set is not specified in the keyâs template . This is because Kyber private keys are only generated as part of a Kyber key pair, and the parameter set for the pair is specified in the template for the Kyber public key. [DJ] The example was for âcreating a private keyâ, which implies C_CreateObject. With that in mind, I think the sample code is valid?  CK_ATTRIBUTE template[] = { {CKA_CLASS, &class, sizeof(class)}, {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, {CKA_TOKEN, &true, sizeof(true)}, {CKA_LABEL, label, sizeof(label)-1}, {CKA_SUBJECT, subject, sizeof(subject)}, {CKA_ID, id, sizeof(id)}, {CKA_SENSITIVE, &true, sizeof(true)}, {CKA_DECAPSULATE, &true, sizeof(true)}, {CKA_PARAMETER_SET, ¶m_set, sizeof(param_set)}, {CKA_VALUE, value, sizeof(value)}  In my opinion, the parameter_set attribute should be on both public and private key attribute templates.  - (1.4.4 Kyber key pair generation): What are CKA_PRIMEâ and âCKA_BASE attributes used to generate a new private key? The library (liboqs) we use to generate Kyber keys does NOT require such attributes. [DJ] I assume this is a typo or copy-paste error.   From:
pkcs11@lists.oasis-open.org <
pkcs11@lists.oasis-open.org> On Behalf Of Robert Relyea Sent: Tuesday, January 31, 2023 7:09 PM 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. [DJ] I assume you are suggesting that we should stick with the C_xxxKey convention? I was implying it, but I haven't gotten any feedback on which to do. currently it's without the 'Key'. 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. [DJ] You mean TPM right? just making sure there isnât something else Iâm not aware of. yes, TPM 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). [DJ] I agree. That might make it easier to leverage things like CKA_ALLOWED_MECHANISMS. This is different than the feedback I got in the meeting. I've left it the same for now, but I'm up for changing it. 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. [DJ] Given that the keys are not identical, they probably need their own key type and mechanism. Either that, or some other way to identify the key. CKA_KEY_GEN_MECHANISM would help, but wouldnât work well for unwrapped keys. 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). [DJ] I had the same thoughts. I canât see any clean way to manage this. 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  Â