It seems to be common-practice for a signature protocol to include the algorithmID and params (if any) in the data being signed.
- 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?
- 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.
- 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).
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?