Multiple Signatures in Cryptographic Message Syntax (CMS)
Extracted elements (25)
The attribute was designed to be computable before any signatures are applied, to identify individual signatures, and to contain enough information to resist collision, preimage, and second preimage attacks. This requires hashing the signedAttrs of the referenced SignerInfo rather than just referencing it by index.
The multiple-signatures attribute protects against downgrade attacks where an attacker removes all SignerInfo structures except the one using a successfully attacked algorithm. Without this attribute, removal of a SignerInfo is undetectable and does not render the remaining signature invalid.
The multiple-signatures attribute provides pointers to parallel signatures by the same signer, in contrast to the countersignature attribute which provides serial signatures. It is not intended to sign over an existing signature but to cross-link simultaneous SignerInfo objects at the same level.
The SignAttrsHash hashes the complete signedAttrs of the referenced SignerInfo rather than hashing only the body, because the signed attributes include algorithm identifiers and the message digest, providing cross-binding that is computationally harder to attack than the body hash alone due to additional structure and shorter length.
Applications may skip the step of grouping SignerInfo objects by signer identity, treating each SignerInfo as fully independent. However, such applications must be aware that algorithm rollover will not work correctly in this case.
For nested SignedData objects (e.g., workflow or S/MIME with ESS features), evaluation policy may differ: a workflow application may consider only the outermost signature, while an S/MIME application may strip outer signatures that fail validation and rely solely on the innermost valid originator signature.
When combining multiple SignerInfo objects from the same signer, applications must specify how signer identity is matched if subject name or subject alternative names are ambiguous. S/MIME applications may consider two SignerInfo objects from the same identity if the same rfc822Name appears in either the subject name or subject alt name.
A signer SHOULD include the digest algorithm in SignedData.digestAlgorithms and SHOULD add certificates sufficient for path validation from a recognized root, if not already present.
During signature verification, for every SignerInfo to be considered complete, the number of MultipleSignatures AttributeValue(s) present MUST equal the number of SignerInfo objects for that signer less one, and each hash value MUST match the output of the message digest calculation over the referenced SignerInfo's signedAttrs.
The algID field within SignAttrsHash MUST match the digest algorithm for the SignerInfo in which this multiple-signatures attribute value is placed.
The cert field (ESSCertIDv2) MUST be present if the bodyHashAlg and signAlg fields in the multiple-signatures attributes of two SignerInfo objects are identical, so that the certificate can disambiguate which SignerInfo is being referenced.
The multiple-signatures attribute MUST be a signed attribute; it cannot appear as an unsigned attribute.
The signer MUST include the multiple-signatures attribute in the signedAttrs of each SignerInfo when using this mechanism.
When generating SignedData, a signer MUST indicate the CMS version, MUST include encapContentInfo (shared by all signers), MUST retain existing signerInfo objects, and MUST include their own signerInfo object(s).
SignerInfo evaluation has three independent components: (1) cryptographic math verification (success, failure, or cannot evaluate), (2) certificate path validation per RFC 5280 yielding success/failure/indeterminate/warning, and (3) application and local policy compliance on SignerInfo contents such as mandatory signed attributes or algorithm requirements.
The multiple-signatures attribute (OID id-aa-multipleSignatures, pkcs9.id-aa.51) is a signed CMS attribute that each SignerInfo uses to cross-reference all other SignerInfo objects produced by the same signer. For N signatures by one signer, each SignerInfo contains N-1 attribute values.
The multiple-signatures signed attribute generation procedure requires a two-pass process: first place all other signed attributes and add the multiple-signatures attributes with a zero-length hash, then compute the correct hash values for each SignerInfo and replace the placeholders. This ensures the attribute is computable before final signing.
The document assigns OID id-aa-multipleSignatures (iso.member-body.us.rsadsi.pkcs.pkcs9.id-aa.51) for the multiple-signatures CMS signed attribute type within the PKCS#9 id-aa arc.
If hashing and signing are performed by different entities, the signing entity must ensure the hash comes from a trustworthy source. Using multiple hashes with different algorithms partially mitigates the risk of a malicious hash provider.
Local policy and application context greatly affect signature validation outcomes. A signature considered valid in one context may fail in another, because policy may impose additional requirements on algorithm strength, certificate path, or mandatory attributes.
Signed attributes must not be accepted from third parties for inclusion in a signer's signedAttrs, because the attributes describe the signature being applied. Third-party meta-information must be attached via a separate signature and countersignature, not by injecting attributes into another signer's structure.
The multiple-signatures attribute cannot protect against scenarios where all algorithms used by a signer have been cryptographically broken, because a verifier cannot determine that no collision exists satisfying all the algorithms simultaneously.
Signature evaluation proceeds in three ordered stages: (1) evaluate each SignerInfo object independently yielding math success/failure/indeterminate, certificate path success/failure/indeterminate/warning, and policy compliance; (2) combine SignerInfo results per signer by taking the best result; (3) combine per-signer results across signers by taking the worst result.
MultipleSignatures is an ASN.1 SEQUENCE containing: bodyHashAlg (DigestAlgorithmIdentifier of the referenced SignerInfo), signAlg (SignatureAlgorithmIdentifier of the referenced SignerInfo), signAttrsHash (SignAttrsHash SEQUENCE), and cert (ESSCertIDv2, OPTIONAL) identifying the certificate used in the referenced SignerInfo.
SignAttrsHash is an ASN.1 SEQUENCE containing algID (DigestAlgorithmIdentifier) and hash (OCTET STRING). The algID must match the digest algorithm of the SignerInfo that contains this attribute value, and hash holds the hash of the referenced SignerInfo's signedAttrs.