Cryptographic Message Syntax (CMS) Multiple Signer Clarification
updates
- rfc-3852 — Cryptographic Message Syntax (CMS)
Extracted elements (10)
During algorithm transitions (e.g., from RSA with SHA-1 to RSA with SHA-256), a signer can sign content with both older and newer algorithms so each recipient can find an acceptable signature regardless of their state in the transition.
Support of different communities of recipients is the primary reason signers choose to include more than one signature. For example, if some recipients support RSA and others ECDSA, the signer can generate two signatures so each recipient can validate one.
When a collection of signerInfos represents more than one signature, successful validation of one signature from a given signer ought to be treated as a successful signature by that signer; however, some application environments may require other rules.
All implementations MUST gracefully handle unimplemented signature algorithms when they are encountered, since not all implementations support every possible signature algorithm.
All implementations MUST gracefully handle unimplemented versions of SignerInfo, since each signer can employ a different digital signature technique and future specifications could update the syntax.
When more than one signature is present, the successful validation of one signature associated with a given signer is usually treated as a successful signature by that signer. Applications that employ a different rule must specify those rules explicitly.
Where simple matching of the signer identifier is not sufficient to determine whether signatures were generated by the same signer, the application specification must describe how to determine which signatures were generated by the same signer.
The CMS SignedData protected content type allows multiple digital signatures via the signerInfos collection, which is a collection of per-signer information and MAY contain any number of elements, including zero.
The signer's public key is referenced either by an issuer distinguished name along with an issuer-specific serial number, or by a subject key identifier that uniquely identifies the certificate containing the public key.
The clarified replacement text reduces the likelihood of interoperability errors during the transition from MD5 and SHA-1 to stronger one-way hash functions or to better signature algorithms.