Meta note about OASIS's tools. Can we turn off all the garbage the reflector adds? It makes it hard to respond to emails with context...
(sigh).
Hi,
Here are some more comments/questions on this draft.
??
I'm not sure it makes sense to map X509 to RSASVE. They are two are very different operations. In fact, X509 is much closer to RSAEP and RSADP.?? Wouldn't a new mechanism for RSAVE be better?
I'm agnostic about this. I asked in our meeting when I presented whether there sould be a new mechanism or should 509 me
For ECDH and ECDH-C, we have at two key generation mechanisms. Which one is used to generate the ephemeral key pair??? It is probably a bit of a religious debate, so shouldn't that be something controlled by the caller?
Are you saying we have two CKM__XXX mechanisms for C_GenerateKeyPair or two ways of generating a key pair from the CKM_ECDH_XXX mechanism (C_GenerateKeyPair and C_EncapsulateKey). I presume you mean the latter. If you mean the former, can you specify the two CKM_XXX mechanisms.
In the former case, C_GenerateKeyPair is used to generate an ephermal key pair as usual. C_EncapsulateKey may generate a key pair internally, but it returns a symetric key (result of a CKM_ECDH_DERIVE operation) and a cipher text (which happens to be a ECDH public key, but that is 'opaque' to the application). There is no access to ephemeral private key, which is discarded once the derive completes. It's meant to 'plug in' to a KEM based higher level API... so
Party A: Generate a KeyPair (possibly Ephermal). Send Public key (likely signed).
Party B: Uses public key to encapsulate a key (get back a key and cipher text). Send cipher text to party A.
Party A: decapsulates cipher text with private key. Gets key.
In this case for ECDH encapsulate generates and ECDH key internally, uses the private key to generate the encapsulated key and returns the public key as the cipher text. The private key is discarded.
Applications can still to the explicit KEX with ECDH for protocols that require knowledge that we are actually doing a KEX. In that case both sides would do the keypair gen because the second side may need to do something special with the private key in the future. (Signal, for instance, does this to get some extended properties of the KEX that KEM doesn't have).
??
For the three DH variants (ECDH, PKCS#3 and X9.42), you state that no public key is passed in the mechanism parameter.?? But this results in a far less efficient flow, especially if the public key is ephemeral.?? Now the public key must be created as an object, used, then deleted.?? I think this is similar to a question I raised with the KEM APIs.?? The "only" way to use the API is with the create+encapsulate+delete workflow.?? This results in a lot of overhead, especially for network attached devices.?? I suppose one reason for this (at least for ECC and DH), is that you need the key object to get the domain/curve parameter?
No, this is how all KEMs work. You encapsulate using the public key and decapsulate using the private key. It maintains the same workflow as every other KEM. You do the exact same thing today with RSA when you wrap (you import the public key and then you wrap).
If you know you are doing a KEX, you can continue to use Derive. I'm not replacing that, I've defining what these mechanisms mean when you pass them to a KEM. The KEM for the DH variants should work just like all the other KEMS.
I suppose the only alternative would be to require an encoded public key to be passed in that includes the parameters/oid/identifier.
Or adjust the API to allow either a handle or a serialize key to be provided.
Then we need to define a serialized key for every operation mechanism.
??
For ML-KEM, the internal functions (K-PKE.Encrypt, K-PK.Decrypt, ML-KEM.Encapsulate, ML-KEM.Decapsulate) defined in FIPS 203 all return fixed length output.?? But the draft4 talks about the length of the key (or CKA_VALUE_LEN) controlling the output and mentions an internal KDF.?? Given that the output is fixed length, is that even possible?
The final key needs to be the length of the underlying symetric operation. At the final step of the KDF we need the key to be whatever we are going to use to encrypt.
??
This raises another topic that I thought was raised before.?? Shouldn't there be a mechanism parameter for ML-KEM so that allows a KDF to be defined? One of our main use cases will be ML-KEM+KDF.
Isn't the KDF defined internally in the spec? If not then yes, we will need to add a KDF mechanism (which is where the output key length would come into play).
??
Thanks
Darren
------------------------------
Darren Johnson
THALES
------------------------------
Original Message:
Sent: 3/27/2024 8:54:00 PM
From: Darren Johnson
Subject: pkcs11_kem_algs_draft4 comments
Hi,
Here are some more comments/questions on this draft.
I'm not sure it makes sense to map X509 to RSASVE. They are two are very different operations. In fact, X509 is much closer to RSAEP and RSADP. Wouldn't a new mechanism for RSAVE be better?
For ECDH and ECDH-C, we have at two key generation mechanisms. Which one is used to generate the ephemeral key pair? It is probably a bit of a religious debate, so shouldn't that be something controlled by the caller?
For the three DH variants (ECDH, PKCS#3 and X9.42), you state that no public key is passed in the mechanism parameter. But this results in a far less efficient flow, especially if the public key is ephemeral. Now the public key must be created as an object, used, then deleted. I think this is similar to a question I raised with the KEM APIs. The "only" way to use the API is with the create+encapsulate+delete workflow. This results in a lot of overhead, especially for network attached devices. I suppose one reason for this (at least for ECC and DH), is that you need the key object to get the domain/curve parameter?
I suppose the only alternative would be to require an encoded public key to be passed in that includes the parameters/oid/identifier.
Or adjust the API to allow either a handle or a serialize key to be provided.
For ML-KEM, the internal functions (K-PKE.Encrypt, K-PK.Decrypt, ML-KEM.Encapsulate, ML-KEM.Decapsulate) defined in FIPS 203 all return fixed length output. But the draft4 talks about the length of the key (or CKA_VALUE_LEN) controlling the output and mentions an internal KDF. Given that the output is fixed length, is that even possible?
This raises another topic that I thought was raised before. Shouldn't there be a mechanism parameter for ML-KEM so that allows a KDF to be defined? One of our main use cases will be ML-KEM+KDF.
Thanks
Darren
------------------------------
Darren Johnson
THALES
------------------------------