In RFC5652, Cryptographic Message Syntax (CMS), section 5.3. SignerInfo Type, there's a digestAlgorithm field that has values like id-sha256, id-sha1, etc.
In that same RFC, section 5.1. SignedData Type there's a digestAlgorithms field that in my testing generally has as many entries in it as there are SignerInfo's.
My question is... why is the digestAlgorithm field being specified in two places? It seems unnecessarily redundant.
As 5.1 says (redacted and emphasis added):
digestAlgorithms ... is intended to list the message digest algorithms employed by all of the signers, in any order, to facilitate one-pass signature verification. Implementations MAY fail to validate signatures that use a digest algorithm that is not included in this set. ...
In other words, a receiver/verifier can start from the beginning of the message and:
read digestAlgorithms and set up contexts for those algorithms
read encapContentInfo and run the data, which can be quite large depending on the digest(s) e.g. 2^64 for SHA-1, through the digest algorithm, or algorithms in parallel, and at the same time also store and/or process and/or relay the data as desired; or if "detached" obtain the data from somewhere else and similarly run it through the digest(s) and maybe other use.
read certificates and crls if present and keep them handy if desired and not too large and not duplicating data already available locally; can discard them if desired, conditional on being able to re-fetch them if and when needed using things like LDAP or AIA (including OCSP)
read signerInfos and for each one (of interest) select the correct already-computed digest and use it, plus the signedAttrs if used, to verify the signature, without going back to the data
Although not so clearly stated, this is also the reason many (not all!) structures in CMS are specified as BER, which can at the sender's choice use indefinite-length encoding, instead of DER, which cannot.
