[lamps] Re: [EXTERNAL] Implied vs. explicit signature digest in PKCS#7 and CMS

[Mike Ounsworth <[e-mail]>]

Hi Viktor,

This is just a quick opinion, not a well-researched answer, but I don’t really see a problem here. I don’t see a need for consistency across algorithm OIDs, as long as each signature algorithm has a spec and that spec clearly defines the behaviour for that signature algorithm.

For example:

RFC9814: SLH-DSA in CMS says:

the digestAlgorithm identifier SHOULD match the hash function used in the SLH-DSA tree (as shown in the list below).
…
The hash functions defined in [FIPS180<https://doi.org/10.6028/NIST.FIPS.180-4>] and [FIPS202<https://doi.org/10.6028/NIST.FIPS.202>] MUST be supported for use with the variants of SLH-DSA as shown below:
      id-slh-dsa-sha2-128s:  SHA-256
      id-slh-dsa-sha2-128f:  SHA-256
      id-slh-dsa-sha2-192s:  SHA-512
      id-slh-dsa-sha2-192f:  SHA-512
      id-slh-dsa-sha2-256s:  SHA-512
      id-slh-dsa-sha2-256f:  SHA-512
      id-slh-dsa-shake-128s: SHAKE128 with 256-bit output
      id-slh-dsa-shake-128f: SHAKE128 with 256-bit output
      id-slh-dsa-shake-192s: SHAKE256 with 512-bit output
      id-slh-dsa-shake-192f: SHAKE256 with 512-bit output
      id-slh-dsa-shake-256s: SHAKE256 with 512-bit output
      id-slh-dsa-shake-256f: SHAKE256 with 512-bit output

That means the obvious digest function is MTI, but it does not forbid using different ones.

That document does not specify the use of HashSLH-DSA in CMS. Maybe another document does, but I am not aware of it.



And draft-ietf-lamps-cms-ml-dsa-06 says:

SHA-512 [FIPS180<https://doi.org/10.6028/nist.fips.180-4>] MUST be supported for use with the variants of ML-DSA in this document.
…
However, other hash functions MAY also be supported; in particular, SHAKE256 SHOULD be supported, as this is the digest algorithm used internally in ML-DSA.


That document does not specify the use of HashML-DSA in CMS. Maybe another document does, but I am not aware of it.



So to my reading, at least on those two examples (SLH-DSA and ML-DSA), it is sufficiently well specified.

---
Mike Ounsworth

From: Viktor Dukhovni <[e-mail]>
Sent: Thursday, July 24, 2025 3:02 AM
To: [e-mail]
Subject: [EXTERNAL] [lamps] Implied vs. explicit signature digest in PKCS#7 and CMS

The signature algorithm OID in the signerInfo signed attributes of PKCS#7 and CMS may in the case of RSA and DSA be digest agnostic, specifying just the public key algorithm, even though a digest is ultimately used to perform the signature. 


The signature algorithm OID in the signerInfo signed attributes of

PKCS#7 and CMS may in the case of RSA and DSA be digest agnostic,

specifying just the public key algorithm, even though a digest is

ultimately used to perform the signature.



This is a result of having a choice between:



        id-dsa                  x9 1



      and any of:



        id-dsa-with-sha1        x9 3

        id-dsa-with-sha224      nistAlgorithms 3 1

        id-dsa-with-sha256      nistAlgorithms 3 2

        id-dsa-with-sha384      nistAlgorithms 3 3

        id-dsa-with-sha512      nistAlgorithms 3 4

        id-dsa-with-sha3-224    nistAlgorithms 3 5

        id-dsa-with-sha3-256    nistAlgorithms 3 6

        id-dsa-with-sha3-384    nistAlgorithms 3 7

        id-dsa-with-sha3-512    nistAlgorithms 3 8



      where:



        x9                      iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4)

        nistAlgorithms          joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)



    or, similarly, between:



        rsaEncryption                       pkcs-1 1



      and any of:



        sha1WithRSAEncryption               pkcs-1 5

        sha256WithRSAEncryption             pkcs-1 11

        sha384WithRSAEncryption             pkcs-1 12

        sha512WithRSAEncryption             pkcs-1 13

        sha224WithRSAEncryption             pkcs-1 14

        id-rsassa-pkcs1-v1-5-with-sha3-224  nistAlgorithms 3 13

        id-rsassa-pkcs1-v1-5-with-sha3-256  nistAlgorithms 3 14

        id-rsassa-pkcs1-v1-5-with-sha3-384  nistAlgorithms 3 15

        id-rsassa-pkcs1-v1-5-with-sha3-512  nistAlgorithms 3 16

        id-RSASSA-PSS-SHAKE128              pkix algorithms(6) 30

        id-RSASSA-PSS-SHAKE256              pkix algorithms(6) 31



      where:



        pkcs-1                  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1

        pkix                    iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)

        nistAlgorithms          joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)



More recent algorithms in CMS are often "pure" variants, that don't

employ a digest.  This necessitates an implementation kludge, where for

the non-specific RSA and DSA OIDs the signed attributes are implicitly

signed with the same digest algorithm as the data payload, while with

the pure algorithms no digest is used.



On the other hand, with the RSA/DSA algorithm OIDs that do imply a

specific digest, there is then a possible conflict between the algorithm

used to hash the data payload and that used as part of the signature.



Do PKCS#7 and/or CMS allow RSA or DSA signatures whose digest differs

from the data payload digest?



Are there any other algorithms where signature algorithm OID might fail

to explicitly indicate the "prehash" digest used?



Are the rules different for ECDSA?  (There seems to have once been a



    ansi-X9-62              iso(1) member-body(2) us(840) 10045

    ecdsa-with-Recommended  id-ecSigType recommended(2)



but even that's ultimately a specific hash that aligns with the key

size, and it seems that this OID never gained much traction).



Another way to ask the question, is whether an implementation should

hardcode which algorithms don't prehash the signed attributes (EdDSA,

SLH-DSA, ML-DSA, ...), or which do (and implicitly use the content

digest algorithm) (RSA and DSA). And also when it is OK for the two

signed attribute prehash algorithm (if applicable) to differ from the

data content digest algorithm.



--

    Viktor.  🇺🇦 Слава Україні!



_______________________________________________

Spasm mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.