1. Multiple Signatures in CMS Russ Housley IETF 66, Montreal, Canada

2. Goal Change the processing in CMS to ensure that it accommodates transition from one signature algorithm to another one S/MIME Mechanism: the originator generates two signatures (one with the old algorithm and one with the new algorithm), and the recipient considers the message valid if either one of the signatures validates

3. ASN.1 Syntax Reminder (1 of 2) SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos } SignerInfos ::= SET OF SignerInfo

4. ASN.1 Syntax Reminder (2 of 2) SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } SignerIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier [0] SubjectKeyIdentifier }

5. One Signature Fred: RSA with SHA-1

6. Two Signatures Fred: RSA with SHA-256 Fred: RSA with SHA-1

7. Four Signatures Gary: RSA with SHA-256 Gary: ECDSA with SHA-256 Fred: RSA with SHA-256 Fred: RSA with SHA-1

8. Five Signatures Irene: RSA with SHA-256 Harry: RSA with SHA-1 Gary: ECDSA with SHA-256 Fred: RSA with SHA-256 Earl: DSA with SHA-1

9. draft-ietf-smime-cms-mult-sign-00 The text in the current draft is not quite right. It says: When more than one signature is present, the successful validation of any one of these signatures ought to be treated as a successful validation of the signed-data content type. The primary reason is that signers may include separate signatures for different communities of recipients. For example, the signed-data content type might include signatures generated with the RSA signature algorithm and with the ECDSA signature algorithm. This allows recipients to verify one algorithm or the other.

10. Proposed Way Forward Proposed replacement text: When more than one signature is present, the successful validation of one of signature associated with each signer ought to be treated as a successful validation of the signed-data content type. However, there are some application environments where all of the included signatures must be valid. Support of different communities of recipients is the primary reason that signers choose to include more than one signature. For example, the signed-data content type might include signatures generated with the RSA signature algorithm and with the ECDSA signature algorithm. This allows recipients to verify one algorithm or the other.

11. Discussion! Questions?