The issue is more complex than presented. :-(
The idea is to say that a message is correctly signed by a given
signer, if one of the signatures
from the *same* signer computed using a different signature
algorithm is valid.
In the same section from RFC 3852, just above we have:
" The process by which signed-data is constructed involves the
1. For each signer, a message digest, or hash value, is computed
on the content with a signer-specific message-digest algorithm.
If the signer is signing any information other than the
content, the message digest of the content and the other
information are digested with the signer's message digest
algorithm (see Section 5.4), and the result becomes the
2. For each signer, the message digest is digitally signed using
the signer's private key.
3. For each signer, the signature value and other signer-specific
information are collected into a SignerInfo value, as defined
in Section 5.3. Certificates and CRLs for each signer, and
those not corresponding to any signer, are collected in this
4. The message digest algorithms for all the signers and the
SignerInfo values for all the signers are collected together
with the content into a SignedData value, as defined in Section
We should have a similar construct for verification, but we don't.
When CMS was first adopted by the S/MIME WG, we decided to keep the
specification as close to the structure of PKCS #7 v1.5 as
possible. The idea was to make it easy for one to determine the
differences. I see no reason why this discussion ought to change
It should start with:
The process by which signed-data is verified involves the
1. For each SignerInfo present in SignerInfos ...
The exercise is more difficult than it looks, because unless
ESSCertID is being used,
it is not possible to know for sure that a signature is from the same signer.
I recognize that this is true. That is the reason that the proposed
text points to the application that is using CMS to help when the sid
field is not sufficient.