Network Working Group                                        R. HousleyRequest for Comments: 2630                                       SPYRUSCategory: Standards Track                                     June 1999                      Cryptographic Message SyntaxStatus of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (1999).  All Rights Reserved.Abstract   This document describes the Cryptographic Message Syntax.  This   syntax is used to digitally sign, digest, authenticate, or encrypt   arbitrary messages.   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5   as specified in RFC 2315 [PKCS#7].  Wherever possible, backward   compatibility is preserved; however, changes were necessary to   accommodate attribute certificate transfer and key agreement   techniques for key management.Housley                     Standards Track                     [Page 1]RFC 2630              Cryptographic Message Syntax             June 1999Table of Contents   1   Introduction .................................................  4   2   General Overview .............................................  4   3   General Syntax ...............................................  5   4   Data Content Type ............................................  5   5   Signed-data Content Type .....................................  6       5.1  SignedData Type .........................................  7       5.2  EncapsulatedContentInfo Type ............................  8       5.3  SignerInfo Type .........................................  9       5.4  Message Digest Calculation Process ...................... 11       5.5  Message Signature Generation Process .................... 12       5.6  Message Signature Verification Process .................. 12   6   Enveloped-data Content Type .................................. 12       6.1  EnvelopedData Type ...................................... 14       6.2  RecipientInfo Type ...................................... 15            6.2.1  KeyTransRecipientInfo Type ....................... 16            6.2.2  KeyAgreeRecipientInfo Type ....................... 17            6.2.3  KEKRecipientInfo Type ............................ 19       6.3  Content-encryption Process .............................. 20       6.4  Key-encryption Process .................................. 20   7   Digested-data Content Type ................................... 21   8   Encrypted-data Content Type .................................. 22   9   Authenticated-data Content Type .............................. 23       9.1  AuthenticatedData Type .................................. 23       9.2  MAC Generation .......................................... 25       9.3  MAC Verification ........................................ 26   10  Useful Types ................................................. 27       10.1  Algorithm Identifier Types ............................. 27             10.1.1  DigestAlgorithmIdentifier ...................... 27             10.1.2  SignatureAlgorithmIdentifier ................... 27             10.1.3  KeyEncryptionAlgorithmIdentifier ............... 28             10.1.4  ContentEncryptionAlgorithmIdentifier ........... 28             10.1.5  MessageAuthenticationCodeAlgorithm ............. 28       10.2  Other Useful Types ..................................... 28             10.2.1  CertificateRevocationLists ..................... 28             10.2.2  CertificateChoices ............................. 29             10.2.3  CertificateSet ................................. 29             10.2.4  IssuerAndSerialNumber .......................... 30             10.2.5  CMSVersion ..................................... 30             10.2.6  UserKeyingMaterial ............................. 30             10.2.7  OtherKeyAttribute .............................. 30Housley                     Standards Track                     [Page 2]RFC 2630              Cryptographic Message Syntax             June 1999   11  Useful Attributes ............................................ 31       11.1  Content Type ........................................... 31       11.2  Message Digest ......................................... 32       11.3  Signing Time ........................................... 32       11.4  Countersignature ....................................... 34   12  Supported Algorithms ......................................... 35       12.1  Digest Algorithms ...................................... 35             12.1.1  SHA-1 .......................................... 35             12.1.2  MD5 ............................................ 35       12.2  Signature Algorithms ................................... 36             12.2.1  DSA ............................................ 36             12.2.2  RSA ............................................ 36       12.3  Key Management Algorithms .............................. 36             12.3.1  Key Agreement Algorithms ....................... 36                     12.3.1.1  X9.42 Ephemeral-Static Diffie-Hellman. 37             12.3.2  Key Transport Algorithms ....................... 38                     12.3.2.1  RSA .................................. 39             12.3.3  Symmetric Key-Encryption Key Algorithms ........ 39                     12.3.3.1  Triple-DES Key Wrap .................. 40                     12.3.3.2  RC2 Key Wrap ......................... 41      12.4  Content Encryption Algorithms ........................... 41            12.4.1  Triple-DES CBC .................................. 42            12.4.2  RC2 CBC ......................................... 42      12.5  Message Authentication Code Algorithms .................. 42            12.5.1  HMAC with SHA-1 ................................. 43      12.6  Triple-DES and RC2 Key Wrap Algorithms .................. 43            12.6.1  Key Checksum .................................... 44            12.6.2  Triple-DES Key Wrap ............................. 44            12.6.3  Triple-DES Key Unwrap ........................... 44            12.6.4  RC2 Key Wrap .................................... 45            12.6.5  RC2 Key Unwrap .................................. 46   Appendix A:  ASN.1 Module ........................................ 47   References ....................................................... 55   Security Considerations .......................................... 56   Acknowledgments .................................................. 58   Author's Address ................................................. 59   Full Copyright Statement ......................................... 60Housley                     Standards Track                     [Page 3]RFC 2630              Cryptographic Message Syntax             June 19991  Introduction   This document describes the Cryptographic Message Syntax.  This   syntax is used to digitally sign, digest, authenticate, or encrypt   arbitrary messages.   The Cryptographic Message Syntax describes an encapsulation syntax   for data protection.  It supports digital signatures, message   authentication codes, and encryption.  The syntax allows multiple   encapsulation, so one encapsulation envelope can be nested inside   another.  Likewise, one party can digitally sign some previously   encapsulated data.  It also allows arbitrary attributes, such as   signing time, to be signed along with the message content, and   provides for other attributes such as countersignatures to be   associated with a signature.   The Cryptographic Message Syntax can support a variety of   architectures for certificate-based key management, such as the one   defined by the PKIX working group.   The Cryptographic Message Syntax values are generated using ASN.1   [X.208-88], using BER-encoding [X.209-88].  Values are typically   represented as octet strings.  While many systems are capable of   transmitting arbitrary octet strings reliably, it is well known that   many electronic-mail systems are not.  This document does not address   mechanisms for encoding octet strings for reliable transmission in   such environments.2  General Overview   The Cryptographic Message Syntax (CMS) is general enough to support   many different content types.  This document defines one protection   content, ContentInfo.  ContentInfo encapsulates a single identified   content type, and the identified type may provide further   encapsulation.  This document defines six content types: data,   signed-data, enveloped-data, digested-data, encrypted-data, and   authenticated-data.  Additional content types can be defined outside   this document.   An implementation that conforms to this specification must implement   the protection content, ContentInfo, and must implement the data,   signed-data, and enveloped-data content types.  The other content   types may be implemented if desired.   As a general design philosophy, each content type permits single pass   processing using indefinite-length Basic Encoding Rules (BER)   encoding.  Single-pass operation is especially helpful if content is   large, stored on tapes, or is "piped" from another process.  Single-Housley                     Standards Track                     [Page 4]RFC 2630              Cryptographic Message Syntax             June 1999   pass operation has one significant drawback: it is difficult to   perform encode operations using the Distinguished Encoding Rules   (DER) [X.509-88] encoding in a single pass since the lengths of the   various components may not be known in advance.  However, signed   attributes within the signed-data content type and authenticated   attributes within the authenticated-data content type require DER   encoding.  Signed attributes and authenticated attributes must be   transmitted in DER form to ensure that recipients can verify a   content that contains one or more unrecognized attributes.  Signed   attributes and authenticated attributes are the only CMS data types   that require DER encoding.3  General Syntax   The Cryptographic Message Syntax (CMS) associates a content type   identifier with a content.  The syntax shall have ASN.1 type   ContentInfo:      ContentInfo ::= SEQUENCE {        contentType ContentType,        content [0] EXPLICIT ANY DEFINED BY contentType }      ContentType ::= OBJECT IDENTIFIER   The fields of ContentInfo have the following meanings:      contentType indicates the type of the associated content.  It is      an object identifier; it is a unique string of integers assigned      by an authority that defines the content type.      content is the associated content.  The type of content can be      determined uniquely by contentType.  Content types for data,      signed-data, enveloped-data, digested-data, encrypted-data, and      authenticated-data are defined in this document.  If additional      content types are defined in other documents, the ASN.1 type      defined should not be a CHOICE type.4  Data Content Type   The following object identifier identifies the data content type:      id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }   The data content type is intended to refer to arbitrary octet   strings, such as ASCII text files; the interpretation is left to the   application.  Such strings need not have any internal structureHousley                     Standards Track                     [Page 5]RFC 2630              Cryptographic Message Syntax             June 1999   (although they could have their own ASN.1 definition or other   structure).   The data content type is generally encapsulated in the signed-data,   enveloped-data, digested-data, encrypted-data, or authenticated-data   content type.5  Signed-data Content Type   The signed-data content type consists of a content of any type and   zero or more signature values.  Any number of signers in parallel can   sign any type of content.   The typical application of the signed-data content type represents   one signer's digital signature on content of the data content type.   Another typical application disseminates certificates and certificate   revocation lists (CRLs).   The process by which signed-data is constructed involves the   following steps:      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 "message digest."      2.  For each signer, the message digest is digitally signed using      the signer's private key.