Is there any cryptographic reason to sign over the signature algID and params?

Question

It seems to be common-practice for a signature protocol to include the algorithmID and params (if any) in the data being signed.

For example:

• RSA PKCS#1 v1.5 includes the digest alg in the data being signed. See RFC 2318 section 10.1.2.
• JWT / JWS includes "protected headers" in the data being signed (which under most JWS serialization schemes includes the alg ids). See RFC 7515 section 5.1.
• XMLDSig includes a SignedInfo, which includes a SignatureMethod, in the signed content. See W3C xmldsig sec 5.4.
• PGP v4 includes the public-key algorithm and hash algorithm in the signed data. See RFC 4880 section 5.2.3.
• X.509 TBSCertificate includes the signature alg and params. See RFC 5280 sec 4.1.
• CMS added an extension via RFC 6211 specifically to address algorithm substitution attacks by explicitly including the digestAlgorithm and signatureAlgorithm signed content.

The only counter-examples I could find are that signature primitives since PKCS#1 v1.5 don't seem to do this anymore (and I think also ECSDA, but didn't find citation), and older versions of protocols that have since "fixed" this "problem".

• DSA (FIPS 1866-4 section 4.6) does not explicitly include the hash alg id in the signed content.
• RSA-PSS (see RFC 3447)
• PGP v3 does not hash over the public-key algorithm or hash algorithm (but was updated in v4 to do so). See RFC 4880 section 5.2.2.
• The original CMS did not sign over the message-disest attribute. See RFC 5652 section 5.4. This was later fixed with the extension defined in RFC6211, see above.

---

But why is it needed?

Reference:

• RFC 6211: Schaad, J. Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute. RFC 6211, DOI 10.17487/RFC6211, April 2011,< http://www. rfc-editor. org/info/rfc6211, 2011

In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. ... This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process.

However ...

Reference:

• Kaliski, Burton S. "On hash function firewalls in signature schemes." Cryptographers’ Track at the RSA Conference. Springer, Berlin, Heidelberg, 2002.

Note that identifying the hash function in the message itself is not enough; it is likely as easy for an opponent to control the identifier as any other part of a message when forging a signature.

Which, yes, of course, if the attacker is manipulating the signed content through a forgery attack, then you can't rely on the integrity of the signed content (d'uh).

---

Question

So, my question boils down to: all of these specs go to a fair amount of effort to protect the signature alg and params inside the signed content. Why? Is there any security reason to do this? Is there anything cryptographically wrong with a fully-detached signature which does not include any signature metadata in the signed content?

Answer 1

all of these specs go to a fair amount of effort to protect the signature alg and params inside the signed content. Why?

Because

1. In many cases, signature alg and params are positively needed to prevent attack. That's the case for X.509 signature alg and params in a certificate that describe what algorithms and parameters the certified public key is intended to be used with (rather than what signature alg and param certifies the certificate). If that signature alg and params were not certified, whatever gives this information could be changed. At the very least that would invoke behaviors not analyzed from a security standpoint, in practice often leading to attack: downgrade to a legacy protocol; DSA public key passed an RSA one, and factored by an adversary, then used to sign.
2. Case 1 tends to include a lot of situations where alg and params are functionally needed to automatically select alg and params. Everyone likes when things just work, and are secure.
3. Danger only comes when signature alg and params describe how their own integrity is protected, and there's nothing else that securely does such description. That's the genuine pitfall the question's Kaliski&Burton quote is about. It's not common AFAIK (Update: self-reference does occur in X.509 certificates. However AFAIK that's never a security issue, because the signature alg and params are redundantly specified in the certification's authority certificate, or because the certificate is self-signed thus inherently trusted). There's >750 words in ISO/IEC 9796-2:2010 sections 6c thru 6e (not in the linked preview) dealing with that potential issue.
4. Signature alg and params do help diagnostic when something does not work, including in case 3 (but as a corollary of Murphy's law, they are missing when most needed).
5. In some cases including 3, the practice of including signature alg and params at least plausibly improves security by forcing magic constants that implementations check. Arguably, that applies to RSASSA-PKCS1-v1_5 (which, when using common hashes, lacks a convincing security reduction under Chosen Message Attack).
6. If things are safe without signature alg and params, and the signature alg and param are actually checked, then their addition is unlikely to harm security; at worse, it gives an unwarranted feeling of extra security.
7. Standard designers think signature alg and params is best security practice, and that's true except in case 3 (but again, that mistake is not so common). With time, this has the potential to become a universal if circular argument.

I just don't known enough about CMS to tell if the efforts in RFC 6211 are needed, useful, or sufficient. Fortunately, that's not directly asked!

---

Is there any cryptographic reason to sign over the signature algID and params (used to make the signature)

Not if the signature scheme is secure (EUF-CMA). In theory, it could help some less than perfect signature scheme by adding redundancy to a signed message (see 5) if said signature algID and params are checked; or further weaken such weak scheme by allowing more leeway in the message, if they are not. I don't know a practical case where that makes a significant difference.