OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [pkcs11] Groups - Post Quantum Signatures V4 Comments


THALES GROUP LIMITED DISTRIBUTION to email recipients

 

Hi,

I just wanted to confirm some details with this proposal.  As well as add some minor editorial comments.

 

FIPS 204 defines pre-hashing for ML-DSA.  We didn’t want to include that in the spec?

 

FIPS 204 defines both random and deterministic variants.  Don’t we want to have those defined separately in the spec? There are use cases where one may want a deterministic signature, as well as use case where one may want a randomized signature.

 

CKA_VALUE for CKK_ML_DSA public key is defined as a “Big Integer”.  But FIPS 204 defines it as an encoded value.  So shouldn’t it be a “Byte Array”?  The question/comment applies to CKA_VALUE for the ML-DSA private key as well.

 

For Falcon, both public and private keys are encoded values as well.  The proposal states that the CK_VALUE attribute for the public and private keys are a “Big Integer”.  Shouldn’t they be “Byte Array”?

 

I spent a lot of time on SLH-DSA, but I have the same question about the CKA_VALUE for the public and private keys.  Shouldn’t they be “Byte Array”?  They both contain multiple values.

Also, FIPS 205 defines both random and deterministic variations of SLH-DSA.  We didn’t want those called out separately in the spec either?

 

Thanks

Darren

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]