[lamps] Re: [lamps-wg/draft-composite-sigs] Composite signs CMS and [I-D.salter-lamps-cms-ml-dsa] compliance (Issue #110)

[Ben S3 <[e-mail]>]

Hi Piotr,

Just to clarify a point that may address some of this (assuming I’ve understood you correctly):

draft-ietf-lamps-cms-ml-dsa currently specifies that SHA-512 must be _supported_, but it doesn’t mandate that SHA-512 must be _used_ (indeed, the same sentence specifies “however, other hash functions MAY also be supported”). So you can use ML-DSA with another digest algorithm if you like, it’s just that (conformant) implementations need to also support SHA-512 for compatibility purposes.

Best,
Ben

From: Piotr Popis <piotr.popis=[e-mail]>
Sent: 04 March 2025 12:32
To: 'Klaußner, Jan' <[e-mail]>; 'Mike Ounsworth' <[e-mail]>; 'John Gray' <[e-mail]>
Cc: [e-mail]
Subject: [lamps] Re: [lamps-wg/draft-composite-sigs] Composite signs CMS and [I-D.salter-lamps-cms-ml-dsa] compliance (Issue #110)

Hey All
I'm afraid the issue of composite signatures and CMS needs to be discussed in more detail.

I think there is agreement to maintain compatibility with other standards, including RFC 8419 (CMS in EdDSA), [draft-ietf-lamps-cms-ml-dsa] and RFC 8933 (the same digest algorithm is used for messageDigest as for signedAttrs).

In the absence of signed attributes, we have the PURE version of ML-DSA, i.e. without an "external" digest function and according to section 3.3 of [draft-ietf-lamps-cms-ml-dsa] the algorithm specified in the digestAlgorithm field has no meaning (even if it were SHA512). The digestAlgorithm field in this case only applies to the traditional component and it is reasonable to ask whether the authors of [composite-signs] always provide for the SHA512 algorithm identifier in such a situation, as suggested by version 4? In my opinion, these should be the digest algorithm identifier according to Table 2 for the traditional component, and in addition for Ed25519 and Ed448 the identifiers SHA512 and SHAKE256 respectively – see section 3.2 of RFC 8419.

In the case of signed attributes, the messageDigest must be calculated and according to section 11.2 of RFC 5652 the message digest is computed using the signer's message digest algorithm (the digestAlgorithm field of the SignerInfo sequence). According to [draft-ietf-lamps-cms-ml-dsa] for ML-DSA it must be SHA512, but should the same algorithm be used for the traditional component? Again, in my opinion, algorithms other than SHA512 should also be allowed for the traditional component.

To sum up: different hash algorithms should be allowed for ML-DSA and the traditional component and it must be specified in the document that the OID indicated in the digestAlgorithm field of the SignerInfo sequence applies only to the traditional algorithm, because for ML-DSA it is always SHA512 (when there are signed attributes), or the external hash function is not used with ML-DSA (when there are no signed attributes). Hence, in chapter 8.2 there should be a table, suggested by me in issue 110, where the indicated hash functions apply to the traditional component:

      +-----------------------------------+----------------+
      | Composite Signature AlgorithmID   | digestAlgorithm|
      |                                   |(for traditional|
      |                                   | component)     |
      +-----------------------------------+----------------+
      | id-MLDSA44-RSA2048-PSS            | SHA256         |
      +-----------------------------------+----------------+
      | id-MLDSA44-RSA2048-PKCS15         | SHA256         |
      +-----------------------------------+----------------+
      | id-MLDSA44-Ed25519                | SHA512         |
      +-----------------------------------+----------------+
      | id-MLDSA44-ECDSA-P256             | SHA256         |
      +-----------------------------------+----------------+
      | id-MLDSA65-RSA3072-PSS            | SHA256         |
      +-----------------------------------+----------------+
      | id-MLDSA65-RSA3072-PKCS15         | SHA256         |
      +-----------------------------------+----------------+
      | id-MLDSA65-RSA4096-PSS            | SHA384         |
      +-----------------------------------+----------------+
      | id-MLDSA65-RSA4096-PKCS15         | SHA384         |
      +-----------------------------------+----------------+
      | id-MLDSA65-ECDSA-P256             | SHA256         |
      +-----------------------------------+----------------+
      | id-MLDSA65-ECDSA-P384             | SHA384         |
      +-----------------------------------+----------------+
      | id-MLDSA65-ECDSA-brainpoolP256r1  | SHA256         |
      +-----------------------------------+----------------+
      | id-MLDSA65-Ed25519                | SHA512         |
      +-----------------------------------+----------------+
      | id-MLDSA87-ECDSA-P384             | SHA384         |
      +-----------------------------------+----------------+
      | id-MLDSA87-ECDSA-brainpoolP384r1  | SHA384         |
      +-----------------------------------+----------------+
      | id-MLDSA87-Ed448                  | SHAKE256       |
      +-----------------------------------+----------------+
      | id-MLDSA87-RSA4096-PSS            | SHA384         |
      +-----------------------------------+----------------+

It seems that in CMS we have a problem with the fact that in SignedData in the SignerInfo sequence we have one digestAlgorithm field, which indicates the digest function, and at the same time in the composite signature we will probably have two digest functions (see table 2). Maybe we should consider introducing special OIDs to indicate a pair of digest algorithms, if - according to table 2 - there was an algorithm other than SHA512 for the traditional component?

Whether or not the content of chapter 8 is changed, it seems that table 11 must be changed.

I suggest considering reopening issue 110, or a completely new issue concerning chapter 8 "Use in CMS".

Regards - Piotr Popis


From: janklaussner <[e-mail]>
Sent: Friday, February 28, 2025 8:39 PM
To: lamps-wg/draft-composite-sigs <[e-mail]>
Cc: PiotrPopis <[e-mail]>; Mention <[e-mail]>
Subject: Re: [lamps-wg/draft-composite-sigs] Composite signs CMS and [I-D.salter-lamps-cms-ml-dsa] compliance (Issue #110)


@PiotrPopis<https://github.com/PiotrPopis>, @Honzaik<https://github.com/Honzaik> ,
thanks for pointing out the misaligment to draft-ietf-lamps-cms-ml-dsa<https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/>.

I agree that we need to feed the unhashed content to Composite-ML-DSA.Sign(). However, I do not get why you want to describe the handling for the ML-DSA and traditional algorithm separately. For an CMS application there is only one interface -the composite one- that controls both component algorithms.

As for the digestAlgorithm, the recent draft-ietf-lamps-cms-ml-dsa-02 changed the recommendation. Now SHA-512 MUST be supported for all versions of ML-DSA. Hence I would not follow your proposal but instead bump the hash for ML-DSA-44 to SHA-512.

—
Reply to this email directly, view it on GitHub<https://github.com/lamps-wg/draft-composite-sigs/issues/110#issuecomment-2691414617>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BLIOPUWIECSNYK53CGYY2D32SC3OXAVCNFSM6AAAAABW2ERNKWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJRGQYTINRRG4>.
You are receiving this because you were mentioned.Message ID: <lamps-wg/draft-composite-sigs/issues/110/[e-mail]<mailto:lamps-wg/draft-composite-sigs/issues/110/[e-mail]>>
[Image removed by sender. janklaussner]janklaussner left a comment (lamps-wg/draft-composite-sigs#110)<https://github.com/lamps-wg/draft-composite-sigs/issues/110#issuecomment-2691414617>

@PiotrPopis<https://github.com/PiotrPopis>, @Honzaik<https://github.com/Honzaik> ,
thanks for pointing out the misaligment to draft-ietf-lamps-cms-ml-dsa<https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/>.

I agree that we need to feed the unhashed content to Composite-ML-DSA.Sign(). However, I do not get why you want to describe the handling for the ML-DSA and traditional algorithm separately. For an CMS application there is only one interface -the composite one- that controls both component algorithms.

As for the digestAlgorithm, the recent draft-ietf-lamps-cms-ml-dsa-02 changed the recommendation. Now SHA-512 MUST be supported for all versions of ML-DSA. Hence I would not follow your proposal but instead bump the hash for ML-DSA-44 to SHA-512.

—
Reply to this email directly, view it on GitHub<https://github.com/lamps-wg/draft-composite-sigs/issues/110#issuecomment-2691414617>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BLIOPUWIECSNYK53CGYY2D32SC3OXAVCNFSM6AAAAABW2ERNKWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJRGQYTINRRG4>.
You are receiving this because you were mentioned.Message ID: <lamps-wg/draft-composite-sigs/issues/110/[e-mail]<mailto:lamps-wg/draft-composite-sigs/issues/110/[e-mail]>>