OASIS PKCS 11 TC

THALES GROUP LIMITED DISTRIBUTION to email recipients

Hi,

I started to write up response to the IETF group about what we discussed today to get some early feedback from them but hit a bit of a problem with the C_Wrap/C_Unwrap use case.  I'll put a big caveat on what I send over there that it is pre-draft and is subject to change.

Here is what I have so far.

Currently we define a CKA_VALUE attribute for ML-DSA and ML-KEM private keys that contains the encoded private key value as defined in FIPS 203 and FIPS 204.  Based on today's discussion, we will be adding an additional attribute CKA_SEED that will store the seed(s) values.  This attribute will be 32-bytes for ML-DSA and 64-bytes for ML-KEM.   I don't think there is any need to have the two ML-KEM seeds stored as two separate attributes. IETF is treating them the same.

When an ML-KEM or ML-DSA private key is generated using C_GenerateKeyPair, both CKA_VALUE and CKA_SEED attributes will be populated.

The CKA_SEED attribute is a sensitive attribute just like CKA_VALUE.  The ability to read CKA_SEED via the C_GetAttributeValue API depends on the key's attributes and any vendor specific security policies of the token.  So if CKA_VALUE can be read, CKA_SEED can be read.

When creating a ML-KEM or ML-DSA private key object using C_CreateObject, an application will be able to specify only CKA_VALUE, only CKA_SEED, or both CKA_VALUE and CKA_SEED. The reasoning for the flexibility in this use case is to support use-cases where an application ONLY has the encoded private key and does not have a seed, or only has a seed.  This allows them to still be able to create the object in the token and use it.  If an application creates a private key with out a CKA_SEED, then the CKA_SEED attribute will not be populated on the private key.  This should be fine as any application that is creating private keys without a seed shouldn't expect/need to read back the seed.  And if only the SEED is provided, a token could recompute the expanded key immediately or on depend, depending on their internal design.

But I'm still struggling with the C_Wrap/C_Unwrap use-case though. Currently when wrapping/unwrapping private keys, we only support PKCS#8 formatted private keys. IETF hasn't finalized on their plans yet.  I would say they are in the early stages at best.  The initial proposal is something like this:

ML-*PrivateKeySeed ::= OCTET STRING (SIZE X) -- X is 32 for ML-DSA and 64 for ML-KEM

ML-*PrivateKeyFull ::= OCTET STRING

ML-*PrivateKey ::= CHOICE {
          ML-*PrivateKeySeed,
      [0] ML-*PrivateKeyFull }

(where ML-* means ML-DSA or ML-KEM)

And they define the default/preferred format as being ML-*PrivateKeySeed.  So we are saying that for C_UnwrapKey, we can support both formats similar to how we support them for C_CreateObject.  But for C_WrapKey we don't have a deterministic way to define what is returned other than to say that we always use ML-*PrivateKeySeed if we can, otherwise we use ML-*PrivateKeyFull.  T

Is this how we want to proceed?

THALES GROUP LIMITED DISTRIBUTION to email recipients

Hi,

I started to write up response to the IETF group about what we discussed today to get some early feedback from them but hit a bit of a problem with the C_Wrap/C_Unwrap use case.  I'll put a big caveat on what I send over there that it is pre-draft and is subject to change.

Here is what I have so far.

Currently we define a CKA_VALUE attribute for ML-DSA and ML-KEM private keys that contains the encoded private key value as defined in FIPS 203 and FIPS 204.  Based on today's discussion, we will be adding an additional attribute CKA_SEED that will store the seed(s) values.  This attribute will be 32-bytes for ML-DSA and 64-bytes for ML-KEM.   I don't think there is any need to have the two ML-KEM seeds stored as two separate attributes. IETF is treating them the same.

When an ML-KEM or ML-DSA private key is generated using C_GenerateKeyPair, both CKA_VALUE and CKA_SEED attributes will be populated.

The CKA_SEED attribute is a sensitive attribute just like CKA_VALUE.  The ability to read CKA_SEED via the C_GetAttributeValue API depends on the key's attributes and any vendor specific security policies of the token.  So if CKA_VALUE can be read, CKA_SEED can be read.

When creating a ML-KEM or ML-DSA private key object using C_CreateObject, an application will be able to specify only CKA_VALUE, only CKA_SEED, or both CKA_VALUE and CKA_SEED. The reasoning for the flexibility in this use case is to support use-cases where an application ONLY has the encoded private key and does not have a seed, or only has a seed.  This allows them to still be able to create the object in the token and use it.  If an application creates a private key with out a CKA_SEED, then the CKA_SEED attribute will not be populated on the private key.  This should be fine as any application that is creating private keys without a seed shouldn't expect/need to read back the seed.  And if only the SEED is provided, a token could recompute the expanded key immediately or on depend, depending on their internal design.

But I'm still struggling with the C_Wrap/C_Unwrap use-case though. Currently when wrapping/unwrapping private keys, we only support PKCS#8 formatted private keys. IETF hasn't finalized on their plans yet.  I would say they are in the early stages at best.  The initial proposal is something like this:

ML-*PrivateKeySeed ::= OCTET STRING (SIZE X) -- X is 32 for ML-DSA and 64 for ML-KEM

ML-*PrivateKeyFull ::= OCTET STRING

ML-*PrivateKey ::= CHOICE {
          ML-*PrivateKeySeed,
      [0] ML-*PrivateKeyFull }

(where ML-* means ML-DSA or ML-KEM)

And they define the default/preferred format as being ML-*PrivateKeySeed.  So we are saying that for C_UnwrapKey, we can support both formats similar to how we support them for C_CreateObject.  But for C_WrapKey we don't have a deterministic way to define what is returned other than to say that we always use ML-*PrivateKeySeed if we can, otherwise we use ML-*PrivateKeyFull.  T

Is this how we want to proceed?

THALES GROUP LIMITED DISTRIBUTION to email recipients

Hi,

I started to write up response to the IETF group about what we discussed today to get some early feedback from them but hit a bit of a problem with the C_Wrap/C_Unwrap use case.  I'll put a big caveat on what I send over there that it is pre-draft and is subject to change.

Here is what I have so far.

Currently we define a CKA_VALUE attribute for ML-DSA and ML-KEM private keys that contains the encoded private key value as defined in FIPS 203 and FIPS 204.  Based on today's discussion, we will be adding an additional attribute CKA_SEED that will store the seed(s) values.  This attribute will be 32-bytes for ML-DSA and 64-bytes for ML-KEM.   I don't think there is any need to have the two ML-KEM seeds stored as two separate attributes. IETF is treating them the same.

When an ML-KEM or ML-DSA private key is generated using C_GenerateKeyPair, both CKA_VALUE and CKA_SEED attributes will be populated.

The CKA_SEED attribute is a sensitive attribute just like CKA_VALUE.  The ability to read CKA_SEED via the C_GetAttributeValue API depends on the key's attributes and any vendor specific security policies of the token.  So if CKA_VALUE can be read, CKA_SEED can be read.

When creating a ML-KEM or ML-DSA private key object using C_CreateObject, an application will be able to specify only CKA_VALUE, only CKA_SEED, or both CKA_VALUE and CKA_SEED. The reasoning for the flexibility in this use case is to support use-cases where an application ONLY has the encoded private key and does not have a seed, or only has a seed.  This allows them to still be able to create the object in the token and use it.  If an application creates a private key with out a CKA_SEED, then the CKA_SEED attribute will not be populated on the private key.  This should be fine as any application that is creating private keys without a seed shouldn't expect/need to read back the seed.  And if only the SEED is provided, a token could recompute the expanded key immediately or on depend, depending on their internal design.

But I'm still struggling with the C_Wrap/C_Unwrap use-case though. Currently when wrapping/unwrapping private keys, we only support PKCS#8 formatted private keys. IETF hasn't finalized on their plans yet.  I would say they are in the early stages at best.  The initial proposal is something like this:

ML-*PrivateKeySeed ::= OCTET STRING (SIZE X) -- X is 32 for ML-DSA and 64 for ML-KEM

ML-*PrivateKeyFull ::= OCTET STRING

ML-*PrivateKey ::= CHOICE {
          ML-*PrivateKeySeed,
      [0] ML-*PrivateKeyFull }

(where ML-* means ML-DSA or ML-KEM)

And they define the default/preferred format as being ML-*PrivateKeySeed.  So we are saying that for C_UnwrapKey, we can support both formats similar to how we support them for C_CreateObject.  But for C_WrapKey we don't have a deterministic way to define what is returned other than to say that we always use ML-*PrivateKeySeed if we can, otherwise we use ML-*PrivateKeyFull.  T

Is this how we want to proceed?

THALES GROUP LIMITED DISTRIBUTION to email recipients

Thanks for those corrections Bob. I think I missed those points on the call.  Kids and supper.

And thanks Simo for that editorial fix.

I've added some responses below.

THALES GROUP LIMITED DISTRIBUTION to email recipients

Hi,

I started to write up response to the IETF group about what we discussed today to get some early feedback from them but hit a bit of a problem with the C_Wrap/C_Unwrap use case.  I'll put a big caveat on what I send over there that it is pre-draft and is subject to change.

Here is what I have so far.

Currently we define a CKA_VALUE attribute for ML-DSA and ML-KEM private keys that contains the encoded private key value as defined in FIPS 203 and FIPS 204.  Based on today's discussion, we will be adding an additional attribute CKA_SEED that will store the seed(s) values.  This attribute will be 32-bytes for ML-DSA and 64-bytes for ML-KEM.   I don't think there is any need to have the two ML-KEM seeds stored as two separate attributes. IETF is treating them the same.

When an ML-KEM or ML-DSA private key is generated using C_GenerateKeyPair, both CKA_VALUE and CKA_SEED attributes will be populated.

The CKA_SEED attribute is a sensitive attribute just like CKA_VALUE.  The ability to read CKA_SEED via the C_GetAttributeValue API depends on the key's attributes and any vendor specific security policies of the token.  So if CKA_VALUE can be read, CKA_SEED can be read.

When creating a ML-KEM or ML-DSA private key object using C_CreateObject, an application will be able to specify only CKA_VALUE, only CKA_SEED, or both CKA_VALUE and CKA_SEED. The reasoning for the flexibility in this use case is to support use-cases where an application ONLY has the encoded private key and does not have a seed, or only has a seed.  This allows them to still be able to create the object in the token and use it.  If an application creates a private key with out a CKA_SEED, then the CKA_SEED attribute will not be populated on the private key.  This should be fine as any application that is creating private keys without a seed shouldn't expect/need to read back the seed.  And if only the SEED is provided, a token could recompute the expanded key immediately or on depend, depending on their internal design.

But I'm still struggling with the C_Wrap/C_Unwrap use-case though. Currently when wrapping/unwrapping private keys, we only support PKCS#8 formatted private keys. IETF hasn't finalized on their plans yet.  I would say they are in the early stages at best.  The initial proposal is something like this:

ML-*PrivateKeySeed ::= OCTET STRING (SIZE X) -- X is 32 for ML-DSA and 64 for ML-KEM

ML-*PrivateKeyFull ::= OCTET STRING

ML-*PrivateKey ::= CHOICE {
          ML-*PrivateKeySeed,
      [0] ML-*PrivateKeyFull }

(where ML-* means ML-DSA or ML-KEM)

And they define the default/preferred format as being ML-*PrivateKeySeed.  So we are saying that for C_UnwrapKey, we can support both formats similar to how we support them for C_CreateObject.  But for C_WrapKey we don't have a deterministic way to define what is returned other than to say that we always use ML-*PrivateKeySeed if we can, otherwise we use ML-*PrivateKeyFull.  T

Is this how we want to proceed?