diff options
Diffstat (limited to 'doc/rfc/rfc2630.txt')
| -rw-r--r-- | doc/rfc/rfc2630.txt | 3363 |
1 files changed, 3363 insertions, 0 deletions
diff --git a/doc/rfc/rfc2630.txt b/doc/rfc/rfc2630.txt new file mode 100644 index 0000000..940094f --- /dev/null +++ b/doc/rfc/rfc2630.txt @@ -0,0 +1,3363 @@ + + + + + + +Network Working Group R. Housley +Request for Comments: 2630 SPYRUS +Category: Standards Track June 1999 + + + Cryptographic Message Syntax + +Status 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 1999 + + +Table 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 .............................. 30 + + + + + + + + + +Housley 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 ......................................... 60 + + + + + + + + + + + + + + +Housley Standards Track [Page 3] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +1 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 structure + + + + +Housley 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. + + 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 step. + + 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 5.1. + + A recipient independently computes the message digest. This message + digest and the signer's public key are used to verify the signature + value. 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 signer's certificate may be included + in the SignedData certificates field. + + + + +Housley Standards Track [Page 6] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + This section is divided into six parts. The first part describes the + top-level type SignedData, the second part describes + EncapsulatedContentInfo, the third part describes the per-signer + information type SignerInfo, and the fourth, fifth, and sixth parts + describe the message digest calculation, signature generation, and + signature verification processes, respectively. + +5.1 SignedData Type + + The following object identifier identifies the signed-data content + type: + + id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } + + The signed-data content type shall have ASN.1 type SignedData: + + SignedData ::= SEQUENCE { + version CMSVersion, + digestAlgorithms DigestAlgorithmIdentifiers, + encapContentInfo EncapsulatedContentInfo, + certificates [0] IMPLICIT CertificateSet OPTIONAL, + crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, + signerInfos SignerInfos } + + DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier + + SignerInfos ::= SET OF SignerInfo + + The fields of type SignedData have the following meanings: + + version is the syntax version number. If no attribute + certificates are present in the certificates field, the + encapsulated content type is id-data, and all of the elements of + SignerInfos are version 1, then the value of version shall be 1. + Alternatively, if attribute certificates are present, the + encapsulated content type is other than id-data, or any of the + elements of SignerInfos are version 3, then the value of version + shall be 3. + + digestAlgorithms is a collection of message digest algorithm + identifiers. There may be any number of elements in the + collection, including zero. Each element identifies the message + digest algorithm, along with any associated parameters, used by + one or more signer. The collection is intended to list the + message digest algorithms employed by all of the signers, in any + order, to facilitate one-pass signature verification. The message + digesting process is described in Section 5.4. + + + +Housley Standards Track [Page 7] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + encapContentInfo is the signed content, consisting of a content + type identifier and the content itself. Details of the + EncapsulatedContentInfo type are discussed in section 5.2. + + certificates is a collection of certificates. It is intended that + the set of certificates be sufficient to contain chains from a + recognized "root" or "top-level certification authority" to all of + the signers in the signerInfos field. There may be more + certificates than necessary, and there may be certificates + sufficient to contain chains from two or more independent top- + level certification authorities. There may also be fewer + certificates than necessary, if it is expected that recipients + have an alternate means of obtaining necessary certificates (e.g., + from a previous set of certificates). As discussed above, if + attribute certificates are present, then the value of version + shall be 3. + + crls is a collection of certificate revocation lists (CRLs). It + is intended that the set contain information sufficient to + determine whether or not the certificates in the certificates + field are valid, but such correspondence is not necessary. There + may be more CRLs than necessary, and there may also be fewer CRLs + than necessary. + + signerInfos is a collection of per-signer information. There may + be any number of elements in the collection, including zero. The + details of the SignerInfo type are discussed in section 5.3. + +5.2 EncapsulatedContentInfo Type + + The content is represented in the type EncapsulatedContentInfo: + + EncapsulatedContentInfo ::= SEQUENCE { + eContentType ContentType, + eContent [0] EXPLICIT OCTET STRING OPTIONAL } + + ContentType ::= OBJECT IDENTIFIER + + The fields of type EncapsulatedContentInfo have the following + meanings: + + eContentType is an object identifier that uniquely specifies the + content type. + + eContent is the content itself, carried as an octet string. The + eContent need not be DER encoded. + + + + + +Housley Standards Track [Page 8] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + The optional omission of the eContent within the + EncapsulatedContentInfo field makes it possible to construct + "external signatures." In the case of external signatures, the + content being signed is absent from the EncapsulatedContentInfo value + included in the signed-data content type. If the eContent value + within EncapsulatedContentInfo is absent, then the signatureValue is + calculated and the eContentType is assigned as though the eContent + value was present. + + In the degenerate case where there are no signers, the + EncapsulatedContentInfo value being "signed" is irrelevant. In this + case, the content type within the EncapsulatedContentInfo value being + "signed" should be id-data (as defined in section 4), and the content + field of the EncapsulatedContentInfo value should be omitted. + +5.3 SignerInfo Type + + Per-signer information is represented in the type SignerInfo: + + 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 } + + SignedAttributes ::= SET SIZE (1..MAX) OF Attribute + + UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute + + Attribute ::= SEQUENCE { + attrType OBJECT IDENTIFIER, + attrValues SET OF AttributeValue } + + AttributeValue ::= ANY + + SignatureValue ::= OCTET STRING + + The fields of type SignerInfo have the following meanings: + + version is the syntax version number. If the SignerIdentifier is + the CHOICE issuerAndSerialNumber, then the version shall be 1. If + + + +Housley Standards Track [Page 9] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + the SignerIdentifier is subjectKeyIdentifier, then the version + shall be 3. + + sid specifies the signer's certificate (and thereby the signer's + public key). The signer's public key is needed by the recipient + to verify the signature. SignerIdentifier provides two + alternatives for specifying the signer's public key. The + issuerAndSerialNumber alternative identifies the signer's + certificate by the issuer's distinguished name and the certificate + serial number; the subjectKeyIdentifier identifies the signer's + certificate by the X.509 subjectKeyIdentifier extension value. + + digestAlgorithm identifies the message digest algorithm, and any + associated parameters, used by the signer. The message digest is + computed on either the content being signed or the content + together with the signed attributes using the process described in + section 5.4. The message digest algorithm should be among those + listed in the digestAlgorithms field of the associated SignerData. + + signedAttributes is a collection of attributes that are signed. + The field is optional, but it must be present if the content type + of the EncapsulatedContentInfo value being signed is not id-data. + Each SignedAttribute in the SET must be DER encoded. Useful + attribute types, such as signing time, are defined in Section 11. + If the field is present, it must contain, at a minimum, the + following two attributes: + + A content-type attribute having as its value the content type + of the EncapsulatedContentInfo value being signed. Section + 11.1 defines the content-type attribute. The content-type + attribute is not required when used as part of a + countersignature unsigned attribute as defined in section 11.4. + + A message-digest attribute, having as its value the message + digest of the content. Section 11.2 defines the message-digest + attribute. + + signatureAlgorithm identifies the signature algorithm, and any + associated parameters, used by the signer to generate the digital + signature. + + signature is the result of digital signature generation, using the + message digest and the signer's private key. + + unsignedAttributes is a collection of attributes that are not + signed. The field is optional. Useful attribute types, such as + countersignatures, are defined in Section 11. + + + + +Housley Standards Track [Page 10] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + The fields of type SignedAttribute and UnsignedAttribute have the + following meanings: + + attrType indicates the type of attribute. It is an object + identifier. + + attrValues is a set of values that comprise the attribute. The + type of each value in the set can be determined uniquely by + attrType. + +5.4 Message Digest Calculation Process + + The message digest calculation process computes a message digest on + either the content being signed or the content together with the + signed attributes. In either case, the initial input to the message + digest calculation process is the "value" of the encapsulated content + being signed. Specifically, the initial input is the + encapContentInfo eContent OCTET STRING to which the signing process + is applied. Only the octets comprising the value of the eContent + OCTET STRING are input to the message digest algorithm, not the tag + or the length octets. + + The result of the message digest calculation process depends on + whether the signedAttributes field is present. When the field is + absent, the result is just the message digest of the content as + described above. When the field is present, however, the result is + the message digest of the complete DER encoding of the + SignedAttributes value contained in the signedAttributes field. + Since the SignedAttributes value, when present, must contain the + content type and the content message digest attributes, those values + are indirectly included in the result. The content type attribute is + not required when used as part of a countersignature unsigned + attribute as defined in section 11.4. A separate encoding of the + signedAttributes field is performed for message digest calculation. + The IMPLICIT [0] tag in the signedAttributes field is not used for + the DER encoding, rather an EXPLICIT SET OF tag is used. That is, + the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] + tag, is to be included in the message digest calculation along with + the length and content octets of the SignedAttributes value. + + When the signedAttributes field is absent, then only the octets + comprising the value of the signedData encapContentInfo eContent + OCTET STRING (e.g., the contents of a file) are input to the message + digest calculation. This has the advantage that the length of the + content being signed need not be known in advance of the signature + generation process. + + + + + +Housley Standards Track [Page 11] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + Although the encapContentInfo eContent OCTET STRING tag and length + octets are not included in the message digest calculation, they are + still protected by other means. The length octets are protected by + the nature of the message digest algorithm since it is + computationally infeasible to find any two distinct messages of any + length that have the same message digest. + +5.5 Message Signature Generation Process + + The input to the signature generation process includes the result of + the message digest calculation process and the signer's private key. + The details of the signature generation depend on the signature + algorithm employed. The object identifier, along with any + parameters, that specifies the signature algorithm employed by the + signer is carried in the signatureAlgorithm field. The signature + value generated by the signer is encoded as an OCTET STRING and + carried in the signature field. + +5.6 Message Signature Verification Process + + The input to the signature verification process includes the result + of the message digest calculation process and the signer's public + key. The recipient may obtain the correct public key for the signer + by any means, but the preferred method is from a certificate obtained + from the SignedData certificates field. The selection and validation + of the signer's public key may be based on certification path + validation (see [PROFILE]) as well as other external context, but is + beyond the scope of this document. The details of the signature + verification depend on the signature algorithm employed. + + The recipient may not rely on any message digest values computed by + the originator. If the signedData signerInfo includes + signedAttributes, then the content message digest must be calculated + as described in section 5.4. For the signature to be valid, the + message digest value calculated by the recipient must be the same as + the value of the messageDigest attribute included in the + signedAttributes of the signedData signerInfo. + +6 Enveloped-data Content Type + + The enveloped-data content type consists of an encrypted content of + any type and encrypted content-encryption keys for one or more + recipients. The combination of the encrypted content and one + encrypted content-encryption key for a recipient is a "digital + envelope" for that recipient. Any type of content can be enveloped + for an arbitrary number of recipients using any of the three key + management techniques for each recipient. + + + + +Housley Standards Track [Page 12] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + The typical application of the enveloped-data content type will + represent one or more recipients' digital envelopes on content of the + data or signed-data content types. + + Enveloped-data is constructed by the following steps: + + 1. A content-encryption key for a particular content-encryption + algorithm is generated at random. + + 2. The content-encryption key is encrypted for each recipient. + The details of this encryption depend on the key management + algorithm used, but three general techniques are supported: + + key transport: the content-encryption key is encrypted in the + recipient's public key; + + key agreement: the recipient's public key and the sender's + private key are used to generate a pairwise symmetric key, then + the content-encryption key is encrypted in the pairwise + symmetric key; and + + symmetric key-encryption keys: the content-encryption key is + encrypted in a previously distributed symmetric key-encryption + key. + + 3. For each recipient, the encrypted content-encryption key and + other recipient-specific information are collected into a + RecipientInfo value, defined in Section 6.2. + + 4. The content is encrypted with the content-encryption key. + Content encryption may require that the content be padded to a + multiple of some block size; see Section 6.3. + + 5. The RecipientInfo values for all the recipients are collected + together with the encrypted content to form an EnvelopedData value + as defined in Section 6.1. + + A recipient opens the digital envelope by decrypting one of the + encrypted content-encryption keys and then decrypting the encrypted + content with the recovered content-encryption key. + + This section is divided into four parts. The first part describes + the top-level type EnvelopedData, the second part describes the per- + recipient information type RecipientInfo, and the third and fourth + parts describe the content-encryption and key-encryption processes. + + + + + + +Housley Standards Track [Page 13] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +6.1 EnvelopedData Type + + The following object identifier identifies the enveloped-data content + type: + + id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } + + The enveloped-data content type shall have ASN.1 type EnvelopedData: + + EnvelopedData ::= SEQUENCE { + version CMSVersion, + originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, + recipientInfos RecipientInfos, + encryptedContentInfo EncryptedContentInfo, + unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } + + OriginatorInfo ::= SEQUENCE { + certs [0] IMPLICIT CertificateSet OPTIONAL, + crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } + + RecipientInfos ::= SET OF RecipientInfo + + EncryptedContentInfo ::= SEQUENCE { + contentType ContentType, + contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, + encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } + + EncryptedContent ::= OCTET STRING + + UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute + + The fields of type EnvelopedData have the following meanings: + + version is the syntax version number. If originatorInfo is + present, then version shall be 2. If any of the RecipientInfo + structures included have a version other than 0, then the version + shall be 2. If unprotectedAttrs is present, then version shall be + 2. If originatorInfo is absent, all of the RecipientInfo + structures are version 0, and unprotectedAttrs is absent, then + version shall be 0. + + originatorInfo optionally provides information about the + originator. It is present only if required by the key management + algorithm. It may contain certificates and CRLs: + + certs is a collection of certificates. certs may contain + originator certificates associated with several different key + + + +Housley Standards Track [Page 14] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + management algorithms. certs may also contain attribute + certificates associated with the originator. The certificates + contained in certs are intended to be sufficient to make chains + from a recognized "root" or "top-level certification authority" + to all recipients. However, certs may contain more + certificates than necessary, and there may be certificates + sufficient to make chains from two or more independent top- + level certification authorities. Alternatively, certs may + contain fewer certificates than necessary, if it is expected + that recipients have an alternate means of obtaining necessary + certificates (e.g., from a previous set of certificates). + + crls is a collection of CRLs. It is intended that the set + contain information sufficient to determine whether or not the + certificates in the certs field are valid, but such + correspondence is not necessary. There may be more CRLs than + necessary, and there may also be fewer CRLs than necessary. + + recipientInfos is a collection of per-recipient information. + There must be at least one element in the collection. + + encryptedContentInfo is the encrypted content information. + + unprotectedAttrs is a collection of attributes that are not + encrypted. The field is optional. Useful attribute types are + defined in Section 11. + + The fields of type EncryptedContentInfo have the following meanings: + + contentType indicates the type of content. + + contentEncryptionAlgorithm identifies the content-encryption + algorithm, and any associated parameters, used to encrypt the + content. The content-encryption process is described in Section + 6.3. The same content-encryption algorithm and content-encryption + key is used for all recipients. + + encryptedContent is the result of encrypting the content. The + field is optional, and if the field is not present, its intended + value must be supplied by other means. + + The recipientInfos field comes before the encryptedContentInfo field + so that an EnvelopedData value may be processed in a single pass. + +6.2 RecipientInfo Type + + Per-recipient information is represented in the type RecipientInfo. + RecipientInfo has a different format for the three key management + + + +Housley Standards Track [Page 15] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + techniques that are supported: key transport, key agreement, and + previously distributed symmetric key-encryption keys. Any of the + three key management techniques can be used for each recipient of the + same encrypted content. In all cases, the content-encryption key is + transferred to one or more recipient in encrypted form. + + RecipientInfo ::= CHOICE { + ktri KeyTransRecipientInfo, + kari [1] KeyAgreeRecipientInfo, + kekri [2] KEKRecipientInfo } + + EncryptedKey ::= OCTET STRING + +6.2.1 KeyTransRecipientInfo Type + + Per-recipient information using key transport is represented in the + type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo + transfers the content-encryption key to one recipient. + + KeyTransRecipientInfo ::= SEQUENCE { + version CMSVersion, -- always set to 0 or 2 + rid RecipientIdentifier, + keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, + encryptedKey EncryptedKey } + + RecipientIdentifier ::= CHOICE { + issuerAndSerialNumber IssuerAndSerialNumber, + subjectKeyIdentifier [0] SubjectKeyIdentifier } + + The fields of type KeyTransRecipientInfo have the following meanings: + + version is the syntax version number. If the RecipientIdentifier + is the CHOICE issuerAndSerialNumber, then the version shall be 0. + If the RecipientIdentifier is subjectKeyIdentifier, then the + version shall be 2. + + rid specifies the recipient's certificate or key that was used by + the sender to protect the content-encryption key. The + RecipientIdentifier provides two alternatives for specifying the + recipient's certificate, and thereby the recipient's public key. + The recipient's certificate must contain a key transport public + key. The content-encryption key is encrypted with the recipient's + public key. The issuerAndSerialNumber alternative identifies the + recipient's certificate by the issuer's distinguished name and the + certificate serial number; the subjectKeyIdentifier identifies the + recipient's certificate by the X.509 subjectKeyIdentifier + extension value. + + + + +Housley Standards Track [Page 16] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + keyEncryptionAlgorithm identifies the key-encryption algorithm, + and any associated parameters, used to encrypt the content- + encryption key for the recipient. The key-encryption process is + described in Section 6.4. + + encryptedKey is the result of encrypting the content-encryption + key for the recipient. + +6.2.2 KeyAgreeRecipientInfo Type + + Recipient information using key agreement is represented in the type + KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will + transfer the content-encryption key to one or more recipient that + uses the same key agreement algorithm and domain parameters for that + algorithm. + + KeyAgreeRecipientInfo ::= SEQUENCE { + version CMSVersion, -- always set to 3 + originator [0] EXPLICIT OriginatorIdentifierOrKey, + ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, + keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, + recipientEncryptedKeys RecipientEncryptedKeys } + + OriginatorIdentifierOrKey ::= CHOICE { + issuerAndSerialNumber IssuerAndSerialNumber, + subjectKeyIdentifier [0] SubjectKeyIdentifier, + originatorKey [1] OriginatorPublicKey } + + OriginatorPublicKey ::= SEQUENCE { + algorithm AlgorithmIdentifier, + publicKey BIT STRING } + + RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey + + RecipientEncryptedKey ::= SEQUENCE { + rid KeyAgreeRecipientIdentifier, + encryptedKey EncryptedKey } + + KeyAgreeRecipientIdentifier ::= CHOICE { + issuerAndSerialNumber IssuerAndSerialNumber, + rKeyId [0] IMPLICIT RecipientKeyIdentifier } + + RecipientKeyIdentifier ::= SEQUENCE { + subjectKeyIdentifier SubjectKeyIdentifier, + date GeneralizedTime OPTIONAL, + other OtherKeyAttribute OPTIONAL } + + SubjectKeyIdentifier ::= OCTET STRING + + + +Housley Standards Track [Page 17] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + The fields of type KeyAgreeRecipientInfo have the following meanings: + + version is the syntax version number. It shall always be 3. + + originator is a CHOICE with three alternatives specifying the + sender's key agreement public key. The sender uses the + corresponding private key and the recipient's public key to + generate a pairwise key. The content-encryption key is encrypted + in the pairwise key. The issuerAndSerialNumber alternative + identifies the sender's certificate, and thereby the sender's + public key, by the issuer's distinguished name and the certificate + serial number. The subjectKeyIdentifier alternative identifies + the sender's certificate, and thereby the sender's public key, by + the X.509 subjectKeyIdentifier extension value. The originatorKey + alternative includes the algorithm identifier and sender's key + agreement public key. Permitting originator anonymity since the + public key is not certified. + + ukm is optional. With some key agreement algorithms, the sender + provides a User Keying Material (UKM) to ensure that a different + key is generated each time the same two parties generate a + pairwise key. + + keyEncryptionAlgorithm identifies the key-encryption algorithm, + and any associated parameters, used to encrypt the content- + encryption key in the key-encryption key. The key-encryption + process is described in Section 6.4. + + recipientEncryptedKeys includes a recipient identifier and + encrypted key for one or more recipients. The + KeyAgreeRecipientIdentifier is a CHOICE with two alternatives + specifying the recipient's certificate, and thereby the + recipient's public key, that was used by the sender to generate a + pairwise key-encryption key. The recipient's certificate must + contain a key agreement public key. The content-encryption key is + encrypted in the pairwise key-encryption key. The + issuerAndSerialNumber alternative identifies the recipient's + certificate by the issuer's distinguished name and the certificate + serial number; the RecipientKeyIdentifier is described below. The + encryptedKey is the result of encrypting the content-encryption + key in the pairwise key-encryption key generated using the key + agreement algorithm. + + The fields of type RecipientKeyIdentifier have the following + meanings: + + subjectKeyIdentifier identifies the recipient's certificate by the + X.509 subjectKeyIdentifier extension value. + + + +Housley Standards Track [Page 18] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + date is optional. When present, the date specifies which of the + recipient's previously distributed UKMs was used by the sender. + + other is optional. When present, this field contains additional + information used by the recipient to locate the public keying + material used by the sender. + +6.2.3 KEKRecipientInfo Type + + Recipient information using previously distributed symmetric keys is + represented in the type KEKRecipientInfo. Each instance of + KEKRecipientInfo will transfer the content-encryption key to one or + more recipients who have the previously distributed key-encryption + key. + + KEKRecipientInfo ::= SEQUENCE { + version CMSVersion, -- always set to 4 + kekid KEKIdentifier, + keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, + encryptedKey EncryptedKey } + + KEKIdentifier ::= SEQUENCE { + keyIdentifier OCTET STRING, + date GeneralizedTime OPTIONAL, + other OtherKeyAttribute OPTIONAL } + + The fields of type KEKRecipientInfo have the following meanings: + + version is the syntax version number. It shall always be 4. + + kekid specifies a symmetric key-encryption key that was previously + distributed to the sender and one or more recipients. + + keyEncryptionAlgorithm identifies the key-encryption algorithm, + and any associated parameters, used to encrypt the content- + encryption key with the key-encryption key. The key-encryption + process is described in Section 6.4. + + encryptedKey is the result of encrypting the content-encryption + key in the key-encryption key. + + The fields of type KEKIdentifier have the following meanings: + + keyIdentifier identifies the key-encryption key that was + previously distributed to the sender and one or more recipients. + + date is optional. When present, the date specifies a single key- + encryption key from a set that was previously distributed. + + + +Housley Standards Track [Page 19] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + other is optional. When present, this field contains additional + information used by the recipient to determine the key-encryption + key used by the sender. + +6.3 Content-encryption Process + + The content-encryption key for the desired content-encryption + algorithm is randomly generated. The data to be protected is padded + as described below, then the padded data is encrypted using the + content-encryption key. The encryption operation maps an arbitrary + string of octets (the data) to another string of octets (the + ciphertext) under control of a content-encryption key. The encrypted + data is included in the envelopedData encryptedContentInfo + encryptedContent OCTET STRING. + + The input to the content-encryption process is the "value" of the + content being enveloped. Only the value octets of the envelopedData + encryptedContentInfo encryptedContent OCTET STRING are encrypted; the + OCTET STRING tag and length octets are not encrypted. + + Some content-encryption algorithms assume the input length is a + multiple of k octets, where k is greater than one. For such + algorithms, the input shall be padded at the trailing end with + k-(lth mod k) octets all having value k-(lth mod k), where lth is + the length of the input. In other words, the input is padded at + the trailing end with one of the following strings: + + 01 -- if lth mod k = k-1 + 02 02 -- if lth mod k = k-2 + . + . + . + k k ... k k -- if lth mod k = 0 + + The padding can be removed unambiguously since all input is padded, + including input values that are already a multiple of the block size, + and no padding string is a suffix of another. This padding method is + well defined if and only if k is less than 256. + +6.4 Key-encryption Process + + The input to the key-encryption process -- the value supplied to the + recipient's key-encryption algorithm -- is just the "value" of the + content-encryption key. + + Any of the three key management techniques can be used for each + recipient of the same encrypted content. + + + + +Housley Standards Track [Page 20] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +7 Digested-data Content Type + + The digested-data content type consists of content of any type and a + message digest of the content. + + Typically, the digested-data content type is used to provide content + integrity, and the result generally becomes an input to the + enveloped-data content type. + + The following steps construct digested-data: + + 1. A message digest is computed on the content with a message- + digest algorithm. + + 2. The message-digest algorithm and the message digest are + collected together with the content into a DigestedData value. + + A recipient verifies the message digest by comparing the message + digest to an independently computed message digest. + + The following object identifier identifies the digested-data content + type: + + id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } + + The digested-data content type shall have ASN.1 type DigestedData: + + DigestedData ::= SEQUENCE { + version CMSVersion, + digestAlgorithm DigestAlgorithmIdentifier, + encapContentInfo EncapsulatedContentInfo, + digest Digest } + + Digest ::= OCTET STRING + + The fields of type DigestedData have the following meanings: + + version is the syntax version number. If the encapsulated content + type is id-data, then the value of version shall be 0; however, if + the encapsulated content type is other than id-data, then the + value of version shall be 2. + + digestAlgorithm identifies the message digest algorithm, and any + associated parameters, under which the content is digested. The + message-digesting process is the same as in Section 5.4 in the + case when there are no signed attributes. + + + + +Housley Standards Track [Page 21] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + encapContentInfo is the content that is digested, as defined in + section 5.2. + + digest is the result of the message-digesting process. + + The ordering of the digestAlgorithm field, the encapContentInfo + field, and the digest field makes it possible to process a + DigestedData value in a single pass. + +8 Encrypted-data Content Type + + The encrypted-data content type consists of encrypted content of any + type. Unlike the enveloped-data content type, the encrypted-data + content type has neither recipients nor encrypted content-encryption + keys. Keys must be managed by other means. + + The typical application of the encrypted-data content type will be to + encrypt the content of the data content type for local storage, + perhaps where the encryption key is a password. + + The following object identifier identifies the encrypted-data content + type: + + id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } + + The encrypted-data content type shall have ASN.1 type EncryptedData: + + EncryptedData ::= SEQUENCE { + version CMSVersion, + encryptedContentInfo EncryptedContentInfo, + unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } + + The fields of type EncryptedData have the following meanings: + + version is the syntax version number. If unprotectedAttrs is + present, then version shall be 2. If unprotectedAttrs is absent, + then version shall be 0. + + encryptedContentInfo is the encrypted content information, as + defined in Section 6.1. + + unprotectedAttrs is a collection of attributes that are not + encrypted. The field is optional. Useful attribute types are + defined in Section 11. + + + + + + +Housley Standards Track [Page 22] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +9 Authenticated-data Content Type + + The authenticated-data content type consists of content of any type, + a message authentication code (MAC), and encrypted authentication + keys for one or more recipients. The combination of the MAC and one + encrypted authentication key for a recipient is necessary for that + recipient to verify the integrity of the content. Any type of + content can be integrity protected for an arbitrary number of + recipients. + + The process by which authenticated-data is constructed involves the + following steps: + + 1. A message-authentication key for a particular message- + authentication algorithm is generated at random. + + 2. The message-authentication key is encrypted for each + recipient. The details of this encryption depend on the key + management algorithm used. + + 3. For each recipient, the encrypted message-authentication key + and other recipient-specific information are collected into a + RecipientInfo value, defined in Section 6.2. + + 4. Using the message-authentication key, the originator computes + a MAC value on the content. If the originator is authenticating + any information in addition to the content (see Section 9.2), a + message digest is calculated on the content, the message digest of + the content and the other information are authenticated using the + message-authentication key, and the result becomes the "MAC + value." + +9.1 AuthenticatedData Type + + The following object identifier identifies the authenticated-data + content type: + + id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) + ct(1) 2 } + + + + + + + + + + + +Housley Standards Track [Page 23] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + The authenticated-data content type shall have ASN.1 type + AuthenticatedData: + + AuthenticatedData ::= SEQUENCE { + version CMSVersion, + originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, + recipientInfos RecipientInfos, + macAlgorithm MessageAuthenticationCodeAlgorithm, + digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, + encapContentInfo EncapsulatedContentInfo, + authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, + mac MessageAuthenticationCode, + unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } + + AuthAttributes ::= SET SIZE (1..MAX) OF Attribute + + UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute + + MessageAuthenticationCode ::= OCTET STRING + + The fields of type AuthenticatedData have the following meanings: + + version is the syntax version number. It shall be 0. + + originatorInfo optionally provides information about the + originator. It is present only if required by the key management + algorithm. It may contain certificates, attribute certificates, + and CRLs, as defined in Section 6.1. + + recipientInfos is a collection of per-recipient information, as + defined in Section 6.1. There must be at least one element in the + collection. + + macAlgorithm is a message authentication code (MAC) algorithm + identifier. It identifies the MAC algorithm, along with any + associated parameters, used by the originator. Placement of the + macAlgorithm field facilitates one-pass processing by the + recipient. + + digestAlgorithm identifies the message digest algorithm, and any + associated parameters, used to compute a message digest on the + encapsulated content if authenticated attributes are present. The + message digesting process is described in Section 9.2. Placement + of the digestAlgorithm field facilitates one-pass processing by + the recipient. If the digestAlgorithm field is present, then the + authenticatedAttributes field must also be present. + + + + + +Housley Standards Track [Page 24] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + encapContentInfo is the content that is authenticated, as defined + in section 5.2. + + authenticatedAttributes is a collection of authenticated + attributes. The authenticatedAttributes structure is optional, + but it must be present if the content type of the + EncapsulatedContentInfo value being authenticated is not id-data. + If the authenticatedAttributes field is present, then the + digestAlgorithm field must also be present. Each + AuthenticatedAttribute in the SET must be DER encoded. Useful + attribute types are defined in Section 11. If the + authenticatedAttributes field is present, it must contain, at a + minimum, the following two attributes: + + A content-type attribute having as its value the content type + of the EncapsulatedContentInfo value being authenticated. + Section 11.1 defines the content-type attribute. + + A message-digest attribute, having as its value the message + digest of the content. Section 11.2 defines the message-digest + attribute. + + mac is the message authentication code. + + unauthenticatedAttributes is a collection of attributes that are + not authenticated. The field is optional. To date, no attributes + have been defined for use as unauthenticated attributes, but other + useful attribute types are defined in Section 11. + +9.2 MAC Generation + + The MAC calculation process computes a message authentication code + (MAC) on either the message being authenticated or a message digest + of message being authenticated together with the originator's + authenticated attributes. + + If authenticatedAttributes field is absent, the input to the MAC + calculation process is the value of the encapContentInfo eContent + OCTET STRING. Only the octets comprising the value of the eContent + OCTET STRING are input to the MAC algorithm; the tag and the length + octets are omitted. This has the advantage that the length of the + content being authenticated need not be known in advance of the MAC + generation process. + + If authenticatedAttributes field is present, the content-type + attribute (as described in Section 11.1) and the message-digest + attribute (as described in section 11.2) must be included, and the + input to the MAC calculation process is the DER encoding of + + + +Housley Standards Track [Page 25] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + authenticatedAttributes. A separate encoding of the + authenticatedAttributes field is performed for message digest + calculation. The IMPLICIT [2] tag in the authenticatedAttributes + field is not used for the DER encoding, rather an EXPLICIT SET OF tag + is used. That is, the DER encoding of the SET OF tag, rather than of + the IMPLICIT [2] tag, is to be included in the message digest + calculation along with the length and content octets of the + authenticatedAttributes value. + + The message digest calculation process computes a message digest on + the content being authenticated. The initial input to the message + digest calculation process is the "value" of the encapsulated content + being authenticated. Specifically, the input is the encapContentInfo + eContent OCTET STRING to which the authentication process is applied. + Only the octets comprising the value of the encapContentInfo eContent + OCTET STRING are input to the message digest algorithm, not the tag + or the length octets. This has the advantage that the length of the + content being authenticated need not be known in advance. Although + the encapContentInfo eContent OCTET STRING tag and length octets are + not included in the message digest calculation, they are still + protected by other means. The length octets are protected by the + nature of the message digest algorithm since it is computationally + infeasible to find any two distinct messages of any length that have + the same message digest. + + The input to the MAC calculation process includes the MAC input data, + defined above, and an authentication key conveyed in a recipientInfo + structure. The details of MAC calculation depend on the MAC + algorithm employed (e.g., HMAC). The object identifier, along with + any parameters, that specifies the MAC algorithm employed by the + originator is carried in the macAlgorithm field. The MAC value + generated by the originator is encoded as an OCTET STRING and carried + in the mac field. + +9.3 MAC Verification + + The input to the MAC verification process includes the input data + (determined based on the presence or absence of the + authenticatedAttributes field, as defined in 9.2), and the + authentication key conveyed in recipientInfo. The details of the MAC + verification process depend on the MAC algorithm employed. + + The recipient may not rely on any MAC values or message digest values + computed by the originator. The content is authenticated as + described in section 9.2. If the originator includes authenticated + attributes, then the content of the authenticatedAttributes is + authenticated as described in section 9.2. For authentication to + succeed, the message MAC value calculated by the recipient must be + + + +Housley Standards Track [Page 26] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + the same as the value of the mac field. Similarly, for + authentication to succeed when the authenticatedAttributes field is + present, the content message digest value calculated by the recipient + must be the same as the message digest value included in the + authenticatedAttributes message-digest attribute. + +10 Useful Types + + This section is divided into two parts. The first part defines + algorithm identifiers, and the second part defines other useful + types. + +10.1 Algorithm Identifier Types + + All of the algorithm identifiers have the same type: + AlgorithmIdentifier. The definition of AlgorithmIdentifier is + imported from X.509 [X.509-88]. + + There are many alternatives for each type of algorithm listed. For + each of these five types, Section 12 lists the algorithms that must + be included in a CMS implementation. + +10.1.1 DigestAlgorithmIdentifier + + The DigestAlgorithmIdentifier type identifies a message-digest + algorithm. Examples include SHA-1, MD2, and MD5. A message-digest + algorithm maps an octet string (the message) to another octet string + (the message digest). + + DigestAlgorithmIdentifier ::= AlgorithmIdentifier + +10.1.2 SignatureAlgorithmIdentifier + + The SignatureAlgorithmIdentifier type identifies a signature + algorithm. Examples include DSS and RSA. A signature algorithm + supports signature generation and verification operations. The + signature generation operation uses the message digest and the + signer's private key to generate a signature value. The signature + verification operation uses the message digest and the signer's + public key to determine whether or not a signature value is valid. + Context determines which operation is intended. + + SignatureAlgorithmIdentifier ::= AlgorithmIdentifier + + + + + + + + +Housley Standards Track [Page 27] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +10.1.3 KeyEncryptionAlgorithmIdentifier + + The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption + algorithm used to encrypt a content-encryption key. The encryption + operation maps an octet string (the key) to another octet string (the + encrypted key) under control of a key-encryption key. The decryption + operation is the inverse of the encryption operation. Context + determines which operation is intended. + + The details of encryption and decryption depend on the key management + algorithm used. Key transport, key agreement, and previously + distributed symmetric key-encrypting keys are supported. + + KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier + +10.1.4 ContentEncryptionAlgorithmIdentifier + + The ContentEncryptionAlgorithmIdentifier type identifies a content- + encryption algorithm. Examples include Triple-DES and RC2. A + content-encryption algorithm supports encryption and decryption + operations. The encryption operation maps an octet string (the + message) to another octet string (the ciphertext) under control of a + content-encryption key. The decryption operation is the inverse of + the encryption operation. Context determines which operation is + intended. + + ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier + +10.1.5 MessageAuthenticationCodeAlgorithm + + The MessageAuthenticationCodeAlgorithm type identifies a message + authentication code (MAC) algorithm. Examples include DES-MAC and + HMAC. A MAC algorithm supports generation and verification + operations. The MAC generation and verification operations use the + same symmetric key. Context determines which operation is intended. + + MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier + +10.2 Other Useful Types + + This section defines types that are used other places in the + document. The types are not listed in any particular order. + +10.2.1 CertificateRevocationLists + + The CertificateRevocationLists type gives a set of certificate + revocation lists (CRLs). It is intended that the set contain + information sufficient to determine whether the certificates and + + + +Housley Standards Track [Page 28] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + attribute certificates with which the set is associated are revoked + or not. However, there may be more CRLs than necessary or there may + be fewer CRLs than necessary. + + The CertificateList may contain a CRL, an Authority Revocation List + (ARL), a Delta Revocation List, or an Attribute Certificate + Revocation List. All of these lists share a common syntax. + + CRLs are specified in X.509 [X.509-97], and they are profiled for use + in the Internet in RFC 2459 [PROFILE]. + + The definition of CertificateList is imported from X.509. + + CertificateRevocationLists ::= SET OF CertificateList + +10.2.2 CertificateChoices + + The CertificateChoices type gives either a PKCS #6 extended + certificate [PKCS#6], an X.509 certificate, or an X.509 attribute + certificate [X.509-97]. The PKCS #6 extended certificate is + obsolete. PKCS #6 certificates are included for backward + compatibility, and their use should be avoided. The Internet profile + of X.509 certificates is specified in the "Internet X.509 Public Key + Infrastructure: Certificate and CRL Profile" [PROFILE]. + + The definitions of Certificate and AttributeCertificate are imported + from X.509. + + CertificateChoices ::= CHOICE { + certificate Certificate, -- See X.509 + extendedCertificate [0] IMPLICIT ExtendedCertificate, + -- Obsolete + attrCert [1] IMPLICIT AttributeCertificate } + -- See X.509 and X9.57 + +10.2.3 CertificateSet + + The CertificateSet type provides a set of certificates. It is + intended that the set be sufficient to contain chains from a + recognized "root" or "top-level certification authority" to all of + the sender certificates with which the set is associated. However, + there may be more certificates than necessary, or there may be fewer + than necessary. + + The precise meaning of a "chain" is outside the scope of this + document. Some applications may impose upper limits on the length of + a chain; others may enforce certain relationships between the + subjects and issuers of certificates within a chain. + + + +Housley Standards Track [Page 29] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + CertificateSet ::= SET OF CertificateChoices + +10.2.4 IssuerAndSerialNumber + + The IssuerAndSerialNumber type identifies a certificate, and thereby + an entity and a public key, by the distinguished name of the + certificate issuer and an issuer-specific certificate serial number. + + The definition of Name is imported from X.501 [X.501-88], and the + definition of CertificateSerialNumber is imported from X.509 + [X.509-97]. + + IssuerAndSerialNumber ::= SEQUENCE { + issuer Name, + serialNumber CertificateSerialNumber } + + CertificateSerialNumber ::= INTEGER + +10.2.5 CMSVersion + + The Version type gives a syntax version number, for compatibility + with future revisions of this document. + + CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } + +10.2.6 UserKeyingMaterial + + The UserKeyingMaterial type gives a syntax for user keying material + (UKM). Some key agreement algorithms require UKMs to ensure that a + different key is generated each time the same two parties generate a + pairwise key. The sender provides a UKM for use with a specific key + agreement algorithm. + + UserKeyingMaterial ::= OCTET STRING + +10.2.7 OtherKeyAttribute + + The OtherKeyAttribute type gives a syntax for the inclusion of other + key attributes that permit the recipient to select the key used by + the sender. The attribute object identifier must be registered along + with the syntax of the attribute itself. Use of this structure + should be avoided since it may impede interoperability. + + OtherKeyAttribute ::= SEQUENCE { + keyAttrId OBJECT IDENTIFIER, + keyAttr ANY DEFINED BY keyAttrId OPTIONAL } + + + + + +Housley Standards Track [Page 30] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +11 Useful Attributes + + This section defines attributes that may be used with signed-data, + enveloped-data, encrypted-data, or authenticated-data. The syntax of + Attribute is compatible with X.501 [X.501-88] and RFC 2459 [PROFILE]. + Some of the attributes defined in this section were originally + defined in PKCS #9 [PKCS#9], others were not previously defined. The + attributes are not listed in any particular order. + + Additional attributes are defined in many places, notably the S/MIME + Version 3 Message Specification [MSG] and the Enhanced Security + Services for S/MIME [ESS], which also include recommendations on the + placement of these attributes. + +11.1 Content Type + + The content-type attribute type specifies the content type of the + ContentInfo value being signed in signed-data. The content-type + attribute type is required if there are any authenticated attributes + present. + + The content-type attribute must be a signed attribute or an + authenticated attribute; it cannot be an unsigned attribute, an + unauthenticated attribute, or an unprotectedAttribute. + + The following object identifier identifies the content-type + attribute: + + id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } + + Content-type attribute values have ASN.1 type ContentType: + + ContentType ::= OBJECT IDENTIFIER + + A content-type attribute must have a single attribute value, even + though the syntax is defined as a SET OF AttributeValue. There must + not be zero or multiple instances of AttributeValue present. + + The SignedAttributes and AuthAttributes syntaxes are each defined as + a SET OF Attributes. The SignedAttributes in a signerInfo must not + include multiple instances of the content-type attribute. Similarly, + the AuthAttributes in an AuthenticatedData must not include multiple + instances of the content-type attribute. + + + + + + + +Housley Standards Track [Page 31] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +11.2 Message Digest + + The message-digest attribute type specifies the message digest of the + encapContentInfo eContent OCTET STRING being signed in signed-data + (see section 5.4) or authenticated in authenticated-data (see section + 9.2). For signed-data, the message digest is computed using the + signer's message digest algorithm. For authenticated-data, the + message digest is computed using the originator's message digest + algorithm. + + Within signed-data, the message-digest signed attribute type is + required if there are any attributes present. Within authenticated- + data, the message-digest authenticated attribute type is required if + there are any attributes present. + + The message-digest attribute must be a signed attribute or an + authenticated attribute; it cannot be an unsigned attribute or an + unauthenticated attribute. + + The following object identifier identifies the message-digest + attribute: + + id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } + + Message-digest attribute values have ASN.1 type MessageDigest: + + MessageDigest ::= OCTET STRING + + A message-digest attribute must have a single attribute value, even + though the syntax is defined as a SET OF AttributeValue. There must + not be zero or multiple instances of AttributeValue present. + + The SignedAttributes syntax is defined as a SET OF Attributes. The + SignedAttributes in a signerInfo must not include multiple instances + of the message-digest attribute. + +11.3 Signing Time + + The signing-time attribute type specifies the time at which the + signer (purportedly) performed the signing process. The signing-time + attribute type is intended for use in signed-data. + + The signing-time attribute may be a signed attribute; it cannot be an + unsigned attribute, an authenticated attribute, or an unauthenticated + attribute. + + + + + +Housley Standards Track [Page 32] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + The following object identifier identifies the signing-time + attribute: + + id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } + + Signing-time attribute values have ASN.1 type SigningTime: + + SigningTime ::= Time + + Time ::= CHOICE { + utcTime UTCTime, + generalizedTime GeneralizedTime } + + Note: The definition of Time matches the one specified in the 1997 + version of X.509 [X.509-97]. + + Dates between 1 January 1950 and 31 December 2049 (inclusive) must be + encoded as UTCTime. Any dates with year values before 1950 or after + 2049 must be encoded as GeneralizedTime. + + UTCTime values must be expressed in Greenwich Mean Time (Zulu) and + must include seconds (i.e., times are YYMMDDHHMMSSZ), even where the + number of seconds is zero. Midnight (GMT) must be represented as + "YYMMDD000000Z". Century information is implicit, and the century + must be determined as follows: + + Where YY is greater than or equal to 50, the year shall be + interpreted as 19YY; and + + Where YY is less than 50, the year shall be interpreted as 20YY. + + GeneralizedTime values shall be expressed in Greenwich Mean Time + (Zulu) and must include seconds (i.e., times are YYYYMMDDHHMMSSZ), + even where the number of seconds is zero. GeneralizedTime values + must not include fractional seconds. + + A signing-time attribute must have a single attribute value, even + though the syntax is defined as a SET OF AttributeValue. There must + not be zero or multiple instances of AttributeValue present. + + The SignedAttributes syntax is defined as a SET OF Attributes. The + SignedAttributes in a signerInfo must not include multiple instances + of the signing-time attribute. + + No requirement is imposed concerning the correctness of the signing + time, and acceptance of a purported signing time is a matter of a + recipient's discretion. It is expected, however, that some signers, + + + +Housley Standards Track [Page 33] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + such as time-stamp servers, will be trusted implicitly. + +11.4 Countersignature + + The countersignature attribute type specifies one or more signatures + on the contents octets of the DER encoding of the signatureValue + field of a SignerInfo value in signed-data. Thus, the + countersignature attribute type countersigns (signs in serial) + another signature. + + The countersignature attribute must be an unsigned attribute; it + cannot be a signed attribute, an authenticated attribute, or an + unauthenticated attribute. + + The following object identifier identifies the countersignature + attribute: + + id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } + + Countersignature attribute values have ASN.1 type Countersignature: + + Countersignature ::= SignerInfo + + Countersignature values have the same meaning as SignerInfo values + for ordinary signatures, except that: + + 1. The signedAttributes field must contain a message-digest + attribute if it contains any other attributes, but need not + contain a content-type attribute, as there is no content type for + countersignatures. + + 2. The input to the message-digesting process is the contents + octets of the DER encoding of the signatureValue field of the + SignerInfo value with which the attribute is associated. + + A countersignature attribute can have multiple attribute values. The + syntax is defined as a SET OF AttributeValue, and there must be one + or more instances of AttributeValue present. + + The UnsignedAttributes syntax is defined as a SET OF Attributes. The + UnsignedAttributes in a signerInfo may include multiple instances of + the countersignature attribute. + + A countersignature, since it has type SignerInfo, can itself contain + a countersignature attribute. Thus it is possible to construct + arbitrarily long series of countersignatures. + + + + +Housley Standards Track [Page 34] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +12 Supported Algorithms + + This section lists the algorithms that must be implemented. + Additional algorithms that should be implemented are also included. + +12.1 Digest Algorithms + + CMS implementations must include SHA-1. CMS implementations should + include MD5. + + Digest algorithm identifiers are located in the SignedData + digestAlgorithms field, the SignerInfo digestAlgorithm field, the + DigestedData digestAlgorithm field, and the AuthenticatedData + digestAlgorithm field. + + Digest values are located in the DigestedData digest field, and + digest values are located in the Message Digest authenticated + attribute. In addition, digest values are input to signature + algorithms. + +12.1.1 SHA-1 + + The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The + algorithm identifier for SHA-1 is: + + sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + oiw(14) secsig(3) algorithm(2) 26 } + + The AlgorithmIdentifier parameters field is optional. If present, + the parameters field must contain an ASN.1 NULL. Implementations + should accept SHA-1 AlgorithmIdentifiers with absent parameters as + well as NULL parameters. Implementations should generate SHA-1 + AlgorithmIdentifiers with NULL parameters. + +12.1.2 MD5 + + The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm + identifier for MD5 is: + + md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) + rsadsi(113549) digestAlgorithm(2) 5 } + + The AlgorithmIdentifier parameters field must be present, and the + parameters field must contain NULL. Implementations may accept the + MD5 AlgorithmIdentifiers with absent parameters as well as NULL + parameters. + + + + + +Housley Standards Track [Page 35] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +12.2 Signature Algorithms + + CMS implementations must include DSA. CMS implementations may + include RSA. + + Signature algorithm identifiers are located in the SignerInfo + signatureAlgorithm field. Also, signature algorithm identifiers are + located in the SignerInfo signatureAlgorithm field of + countersignature attributes. + + Signature values are located in the SignerInfo signature field. + Also, signature values are located in the SignerInfo signature field + of countersignature attributes. + +12.2.1 DSA + + The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is + always used with the SHA-1 message digest algorithm. The algorithm + identifier for DSA is: + + id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) x9-57 (10040) x9cm(4) 3 } + + The AlgorithmIdentifier parameters field must not be present. + +12.2.2 RSA + + The RSA signature algorithm is defined in RFC 2347 [NEWPKCS#1]. RFC + 2347 specifies the use of the RSA signature algorithm with the SHA-1 + and MD5 message digest algorithms. The algorithm identifier for RSA + is: + + rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } + +12.3 Key Management Algorithms + + CMS accommodates three general key management techniques: key + agreement, key transport, and previously distributed symmetric key- + encryption keys. + +12.3.1 Key Agreement Algorithms + + CMS implementations must include key agreement using X9.42 + Ephemeral-Static Diffie-Hellman. + + Any symmetric encryption algorithm that a CMS implementation includes + as a content-encryption algorithm must also be included as a key- + + + +Housley Standards Track [Page 36] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + encryption algorithm. CMS implementations must include key agreement + of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of + Triple-DES content-encryption keys. CMS implementations should + include key agreement of RC2 pairwise key-encryption keys and RC2 + wrapping of RC2 content-encryption keys. The key wrap algorithm for + Triple-DES and RC2 is described in section 12.3.3. + + A CMS implementation may support mixed key-encryption and content- + encryption algorithms. For example, a 128-bit RC2 content-encryption + key may be wrapped with 168-bit Triple-DES key-encryption key. + Similarly, a 40-bit RC2 content-encryption key may be wrapped with + 128-bit RC2 key-encryption key. + + For key agreement of RC2 key-encryption keys, 128 bits must be + generated as input to the key expansion process used to compute the + RC2 effective key [RC2]. + + Key agreement algorithm identifiers are located in the EnvelopedData + RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and + AuthenticatedData RecipientInfos KeyAgreeRecipientInfo + keyEncryptionAlgorithm fields. + + Key wrap algorithm identifiers are located in the KeyWrapAlgorithm + parameters within the EnvelopedData RecipientInfos + KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData + RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. + + Wrapped content-encryption keys are located in the EnvelopedData + RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys + encryptedKey field. Wrapped message-authentication keys are located + in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo + RecipientEncryptedKeys encryptedKey field. + +12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman + + Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631 + [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the + EnvelopedData RecipientInfos KeyAgreeRecipientInfo and + AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are + used as follows: + + version must be 3. + + originator must be the originatorKey alternative. The + originatorKey algorithm fields must contain the dh-public-number + object identifier with absent parameters. The originatorKey + publicKey field must contain the sender's ephemeral public key. + The dh-public-number object identifier is: + + + +Housley Standards Track [Page 37] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) ansi-x942(10046) number-type(2) 1 } + + ukm may be absent. When present, the ukm is used to ensure that a + different key-encryption key is generated when the ephemeral + private key might be used more than once. + + keyEncryptionAlgorithm must be the id-alg-ESDH algorithm + identifier. The algorithm identifier parameter field for id-alg- + ESDH is KeyWrapAlgorihtm, and this parameter must be present. The + KeyWrapAlgorithm denotes the symmetric encryption algorithm used + to encrypt the content-encryption key with the pairwise key- + encryption key generated using the Ephemeral-Static Diffie-Hellman + key agreement algorithm. Triple-DES and RC2 key wrap algorithms + are discussed in section 12.3.3. The id-alg-ESDH algorithm + identifier and parameter syntax is: + + id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) + rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } + + KeyWrapAlgorithm ::= AlgorithmIdentifier + + recipientEncryptedKeys contains an identifier and an encrypted key + for each recipient. The RecipientEncryptedKey + KeyAgreeRecipientIdentifier must contain either the + issuerAndSerialNumber identifying the recipient's certificate or + the RecipientKeyIdentifier containing the subject key identifier + from the recipient's certificate. In both cases, the recipient's + certificate contains the recipient's static public key. + RecipientEncryptedKey EncryptedKey must contain the content- + encryption key encrypted with the Ephemeral-Static Diffie-Hellman + generated pairwise key-encryption key using the algorithm + specified by the KeyWrapAlgortihm. + +12.3.2 Key Transport Algorithms + + CMS implementations should include key transport using RSA. RSA + implementations must include key transport of Triple-DES content- + encryption keys. RSA implementations should include key transport of + RC2 content-encryption keys. + + Key transport algorithm identifiers are located in the EnvelopedData + RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm and + AuthenticatedData RecipientInfos KeyTransRecipientInfo + keyEncryptionAlgorithm fields. + + Key transport encrypted content-encryption keys are located in the + EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey + + + +Housley Standards Track [Page 38] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + field. Key transport encrypted message-authentication keys are + located in the AuthenticatedData RecipientInfos KeyTransRecipientInfo + encryptedKey field. + +12.3.2.1 RSA + + The RSA key transport algorithm is the RSA encryption scheme defined + in RFC 2313 [PKCS#1], block type is 02, where the message to be + encrypted is the content-encryption key. The algorithm identifier + for RSA is: + + rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } + + The AlgorithmIdentifier parameters field must be present, and the + parameters field must contain NULL. + + When using a Triple-DES content-encryption key, adjust the parity + bits for each DES key comprising the Triple-DES key prior to RSA + encryption. + + The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to + provide confidentiality has a known vulnerability concerns. The + vulnerability is primarily relevant to usage in interactive + applications rather than to store-and-forward environments. Further + information and proposed countermeasures are discussed in the + Security Considerations section of this document. + + Note that the same encryption scheme is also defined in RFC 2437 + [NEWPKCS#1]. Within RFC 2437, this scheme is called + RSAES-PKCS1-v1_5. + +12.3.3 Symmetric Key-Encryption Key Algorithms + + CMS implementations may include symmetric key-encryption key + management. Such CMS implementations must include Triple-DES key- + encryption keys wrapping Triple-DES content-encryption keys, and such + CMS implementations should include RC2 key-encryption keys wrapping + RC2 content-encryption keys. Only 128-bit RC2 keys may be used as + key-encryption keys, and they must be used with the + RC2ParameterVersion parameter set to 58. A CMS implementation may + support mixed key-encryption and content-encryption algorithms. For + example, a 40-bit RC2 content-encryption key may be wrapped with + 168-bit Triple-DES key-encryption key or with a 128-bit RC2 key- + encryption key. + + + + + + +Housley Standards Track [Page 39] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + Key wrap algorithm identifiers are located in the EnvelopedData + RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and + AuthenticatedData RecipientInfos KEKRecipientInfo + keyEncryptionAlgorithm fields. + + Wrapped content-encryption keys are located in the EnvelopedData + RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped + message-authentication keys are located in the AuthenticatedData + RecipientInfos KEKRecipientInfo encryptedKey field. + + The output of a key agreement algorithm is a key-encryption key, and + this key-encryption key is used to encrypt the content-encryption + key. In conjunction with key agreement algorithms, CMS + implementations must include encryption of content-encryption keys + with the pairwise key-encryption key generated using a key agreement + algorithm. To support key agreement, key wrap algorithm identifiers + are located in the KeyWrapAlgorithm parameter of the EnvelopedData + RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and + AuthenticatedData RecipientInfos KeyAgreeRecipientInfo + keyEncryptionAlgorithm fields. Wrapped content-encryption keys are + located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo + RecipientEncryptedKeys encryptedKey field, wrapped message- + authentication keys are located in the AuthenticatedData + RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys + encryptedKey field. + +12.3.3.1 Triple-DES Key Wrap + + Triple-DES key encryption has the algorithm identifier: + + id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } + + The AlgorithmIdentifier parameter field must be NULL. + + The key wrap algorithm used to encrypt a Triple-DES content- + encryption key with a Triple-DES key-encryption key is specified in + section 12.6. + + Out-of-band distribution of the Triple-DES key-encryption key used to + encrypt the Triple-DES content-encryption key is beyond of the scope + of this document. + + + + + + + + + +Housley Standards Track [Page 40] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +12.3.3.2 RC2 Key Wrap + + RC2 key encryption has the algorithm identifier: + + id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } + + The AlgorithmIdentifier parameter field must be RC2wrapParameter: + + RC2wrapParameter ::= RC2ParameterVersion + + RC2ParameterVersion ::= INTEGER + + The RC2 effective-key-bits (key size) greater than 32 and less than + 256 is encoded in the RC2ParameterVersion. For the effective-key- + bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, + and 58 respectively. These values are not simply the RC2 key length. + Note that the value 160 must be encoded as two octets (00 A0), + because the one octet (A0) encoding represents a negative number. + + Only 128-bit RC2 keys may be used as key-encryption keys, and they + must be used with the RC2ParameterVersion parameter set to 58. + + The key wrap algorithm used to encrypt a RC2 content-encryption key + with a RC2 key-encryption key is specified in section 12.6. + + Out-of-band distribution of the RC2 key-encryption key used to + encrypt the RC2 content-encryption key is beyond of the scope of this + document. + +12.4 Content Encryption Algorithms + + CMS implementations must include Triple-DES in CBC mode. CMS + implementations should include RC2 in CBC mode. + + Content encryption algorithms identifiers are located in the + EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the + EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. + + Content encryption algorithms are used to encipher the content + located in the EnvelopedData EncryptedContentInfo encryptedContent + field and the EncryptedData EncryptedContentInfo encryptedContent + field. + + + + + + + + +Housley Standards Track [Page 41] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +12.4.1 Triple-DES CBC + + The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The + Triple-DES is composed from three sequential DES [DES] operations: + encrypt, decrypt, and encrypt. Three-Key Triple-DES uses a different + key for each DES operation. Two-Key Triple-DES uses one key for the + two encrypt operations and different key for the decrypt operation. + The same algorithm identifiers are used for Three-Key Triple-DES and + Two-Key Triple-DES. The algorithm identifier for Triple-DES in + Cipher Block Chaining (CBC) mode is: + + des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } + + The AlgorithmIdentifier parameters field must be present, and the + parameters field must contain a CBCParameter: + + CBCParameter ::= IV + + IV ::= OCTET STRING -- exactly 8 octets + +12.4.2 RC2 CBC + + The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm + identifier for RC2 in CBC mode is: + + rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) + rsadsi(113549) encryptionAlgorithm(3) 2 } + + The AlgorithmIdentifier parameters field must be present, and the + parameters field must contain a RC2CBCParameter: + + RC2CBCParameter ::= SEQUENCE { + rc2ParameterVersion INTEGER, + iv OCTET STRING } -- exactly 8 octets + + The RC2 effective-key-bits (key size) greater than 32 and less than + 256 is encoded in the rc2ParameterVersion. For the effective-key- + bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, + and 58 respectively. These values are not simply the RC2 key length. + Note that the value 160 must be encoded as two octets (00 A0), since + the one octet (A0) encoding represents a negative number. + +12.5 Message Authentication Code Algorithms + + CMS implementations that support authenticatedData must include HMAC + with SHA-1. + + + + +Housley Standards Track [Page 42] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + MAC algorithm identifiers are located in the AuthenticatedData + macAlgorithm field. + + MAC values are located in the AuthenticatedData mac field. + +12.5.1 HMAC with SHA-1 + + The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The + algorithm identifier for HMAC with SHA-1 is: + + hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } + + The AlgorithmIdentifier parameters field must be absent. + +12.6 Triple-DES and RC2 Key Wrap Algorithms + + CMS implementations must include encryption of a Triple-DES content- + encryption key with a Triple-DES key-encryption key using the + algorithm specified in Sections 12.6.2 and 12.6.3. CMS + implementations should include encryption of a RC2 content-encryption + key with a RC2 key-encryption key using the algorithm specified in + Sections 12.6.4 and 12.6.5. Triple-DES and RC2 content-encryption + keys are encrypted in Cipher Block Chaining (CBC) mode [MODES]. + + Key Transport algorithms allow for the content-encryption key to be + directly encrypted; however, key agreement and symmetric key- + encryption key algorithms encrypt the content-encryption key with a + second symmetric encryption algorithm. This section describes how + the Triple-DES or RC2 content-encryption key is formatted and + encrypted. + + Key agreement algorithms generate a pairwise key-encryption key, and + a key wrap algorithm is used to encrypt the content-encryption key + with the pairwise key-encryption key. Similarly, a key wrap + algorithm is used to encrypt the content-encryption key in a + previously distributed key-encryption key. + + The key-encryption key is generated by the key agreement algorithm or + distributed out of band. For key agreement of RC2 key-encryption + keys, 128 bits must be generated as input to the key expansion + process used to compute the RC2 effective key [RC2]. + + The same algorithm identifier is used for both 2-key and 3-key + Triple-DES. When the length of the content-encryption key to be + wrapped is a 2-key Triple-DES key, a third key with the same value as + the first key is created. Thus, all Triple-DES content-encryption + keys are wrapped like 3-key Triple-DES keys. + + + +Housley Standards Track [Page 43] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +12.6.1 Key Checksum + + The CMS Checksum Algorithm is used to provide a content-encryption + key integrity check value. The algorithm is: + + 1. Compute a 20 octet SHA-1 [SHA1] message digest on the + content-encryption key. + 2. Use the most significant (first) eight octets of the message + digest value as the checksum value. + +12.6.2 Triple-DES Key Wrap + + The Triple-DES key wrap algorithm encrypts a Triple-DES content- + encryption key with a Triple-DES key-encryption key. The Triple-DES + key wrap algorithm is: + + 1. Set odd parity for each of the DES key octets comprising + the content-encryption key, call the result CEK. + 2. Compute an 8 octet key checksum value on CEK as described above + in Section 12.6.1, call the result ICV. + 3. Let CEKICV = CEK || ICV. + 4. Generate 8 octets at random, call the result IV. + 5. Encrypt CEKICV in CBC mode using the key-encryption key. Use + the random value generated in the previous step as the + initialization vector (IV). Call the ciphertext TEMP1. + 6. Let TEMP2 = IV || TEMP1. + 7. Reverse the order of the octets in TEMP2. That is, the most + significant (first) octet is swapped with the least significant + (last) octet, and so on. Call the result TEMP3. + 8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use + an initialization vector (IV) of 0x4adda22c79e82105. + The ciphertext is 40 octets long. + + Note: When the same content-encryption key is wrapped in different + key-encryption keys, a fresh initialization vector (IV) must be + generated for each invocation of the key wrap algorithm. + +12.6.3 Triple-DES Key Unwrap + + The Triple-DES key unwrap algorithm decrypts a Triple-DES content- + encryption key using a Triple-DES key-encryption key. The Triple-DES + key unwrap algorithm is: + + 1. If the wrapped content-encryption key is not 40 octets, then + error. + 2. Decrypt the wrapped content-encryption key in CBC mode using + the key-encryption key. Use an initialization vector (IV) + of 0x4adda22c79e82105. Call the output TEMP3. + + + +Housley Standards Track [Page 44] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + 3. Reverse the order of the octets in TEMP3. That is, the most + significant (first) octet is swapped with the least significant + (last) octet, and so on. Call the result TEMP2. + 4. Decompose the TEMP2 into IV and TEMP1. IV is the most + significant (first) 8 octets, and TEMP1 is the least significant + (last) 32 octets. + 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use + the IV value from the previous step as the initialization vector. + Call the ciphertext CEKICV. + 6. Decompose the CEKICV into CEK and ICV. CEK is the most significant + (first) 24 octets, and ICV is the least significant (last) 8 octets. + 7. Compute an 8 octet key checksum value on CEK as described above + in Section 12.6.1. If the computed key checksum value does not + match the decrypted key checksum value, ICV, then error. + 8. Check for odd parity each of the DES key octets comprising CEK. + If parity is incorrect, then there is an error. + 9. Use CEK as the content-encryption key. + +12.6.4 RC2 Key Wrap + + The RC2 key wrap algorithm encrypts a RC2 content-encryption key with + a RC2 key-encryption key. The RC2 key wrap algorithm is: + + 1. Let the content-encryption key be called CEK, and let the length + of the content-encryption key in octets be called LENGTH. LENGTH + is a single octet. + 2. Let LCEK = LENGTH || CEK. + 3. Let LCEKPAD = LCEK || PAD. If the length of LCEK is a multiple + of 8, the PAD has a length of zero. If the length of LCEK is + not a multiple of 8, then PAD contains the fewest number of + random octets to make the length of LCEKPAD a multiple of 8. + 4. Compute an 8 octet key checksum value on LCEKPAD as described + above in Section 12.6.1, call the result ICV. + 5. Let LCEKPADICV = LCEKPAD || ICV. + 6. Generate 8 octets at random, call the result IV. + 7. Encrypt LCEKPADICV in CBC mode using the key-encryption key. + Use the random value generated in the previous step as the + initialization vector (IV). Call the ciphertext TEMP1. + 8. Let TEMP2 = IV || TEMP1. + 9. Reverse the order of the octets in TEMP2. That is, the most + significant (first) octet is swapped with the least significant + (last) octet, and so on. Call the result TEMP3. + 10. Encrypt TEMP3 in CBC mode using the key-encryption key. Use + an initialization vector (IV) of 0x4adda22c79e82105. + + Note: When the same content-encryption key is wrapped in different + key-encryption keys, a fresh initialization vector (IV) must be + generated for each invocation of the key wrap algorithm. + + + +Housley Standards Track [Page 45] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +12.6.5 RC2 Key Unwrap + + The RC2 key unwrap algorithm decrypts a RC2 content-encryption key + using a RC2 key-encryption key. The RC2 key unwrap algorithm is: + + 1. If the wrapped content-encryption key is not a multiple of 8 + octets, then error. + 2. Decrypt the wrapped content-encryption key in CBC mode using + the key-encryption key. Use an initialization vector (IV) + of 0x4adda22c79e82105. Call the output TEMP3. + 3. Reverse the order of the octets in TEMP3. That is, the most + significant (first) octet is swapped with the least significant + (last) octet, and so on. Call the result TEMP2. + 4. Decompose the TEMP2 into IV and TEMP1. IV is the most + significant (first) 8 octets, and TEMP1 is the remaining octets. + + 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use + the IV value from the previous step as the initialization vector. + Call the plaintext LCEKPADICV. + 6. Decompose the LCEKPADICV into LCEKPAD, and ICV. ICV is the + least significant (last) octet 8 octets. LCEKPAD is the + remaining octets. + 7. Compute an 8 octet key checksum value on LCEKPAD as described + above in Section 12.6.1. If the computed key checksum value + does not match the decrypted key checksum value, ICV, then error. + 8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the + most significant (first) octet. CEK is the following LENGTH + octets. PAD is the remaining octets, if any. + 9. If the length of PAD is more than 7 octets, then error. + 10. Use CEK as the content-encryption key. + + + + + + + + + + + + + + + + + + + + + +Housley Standards Track [Page 46] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +Appendix A: ASN.1 Module + +CryptographicMessageSyntax + { iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } + +DEFINITIONS IMPLICIT TAGS ::= +BEGIN + +-- EXPORTS All +-- The types and values defined in this module are exported for use in +-- the other ASN.1 modules. Other applications may use them for their +-- own purposes. + +IMPORTS + + -- Directory Information Framework (X.501) + Name + FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) + informationFramework(1) 3 } + + -- Directory Authentication Framework (X.509) + AlgorithmIdentifier, AttributeCertificate, Certificate, + CertificateList, CertificateSerialNumber + FROM AuthenticationFramework { joint-iso-itu-t ds(5) + module(1) authenticationFramework(7) 3 } ; + + +-- Cryptographic Message Syntax + +ContentInfo ::= SEQUENCE { + contentType ContentType, + content [0] EXPLICIT ANY DEFINED BY contentType } + +ContentType ::= OBJECT IDENTIFIER + +SignedData ::= SEQUENCE { + version CMSVersion, + digestAlgorithms DigestAlgorithmIdentifiers, + encapContentInfo EncapsulatedContentInfo, + certificates [0] IMPLICIT CertificateSet OPTIONAL, + crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, + signerInfos SignerInfos } + +DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier + +SignerInfos ::= SET OF SignerInfo + + + + +Housley Standards Track [Page 47] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +EncapsulatedContentInfo ::= SEQUENCE { + eContentType ContentType, + eContent [0] EXPLICIT OCTET STRING OPTIONAL } + +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 } + +SignedAttributes ::= SET SIZE (1..MAX) OF Attribute + +UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute + +Attribute ::= SEQUENCE { + attrType OBJECT IDENTIFIER, + attrValues SET OF AttributeValue } + +AttributeValue ::= ANY + +SignatureValue ::= OCTET STRING + +EnvelopedData ::= SEQUENCE { + version CMSVersion, + originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, + recipientInfos RecipientInfos, + encryptedContentInfo EncryptedContentInfo, + unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } + +OriginatorInfo ::= SEQUENCE { + certs [0] IMPLICIT CertificateSet OPTIONAL, + crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } + +RecipientInfos ::= SET OF RecipientInfo + +EncryptedContentInfo ::= SEQUENCE { + contentType ContentType, + contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, + encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } + +EncryptedContent ::= OCTET STRING + + + +Housley Standards Track [Page 48] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute + +RecipientInfo ::= CHOICE { + ktri KeyTransRecipientInfo, + kari [1] KeyAgreeRecipientInfo, + kekri [2] KEKRecipientInfo } + +EncryptedKey ::= OCTET STRING + +KeyTransRecipientInfo ::= SEQUENCE { + version CMSVersion, -- always set to 0 or 2 + rid RecipientIdentifier, + keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, + encryptedKey EncryptedKey } + +RecipientIdentifier ::= CHOICE { + issuerAndSerialNumber IssuerAndSerialNumber, + subjectKeyIdentifier [0] SubjectKeyIdentifier } + +KeyAgreeRecipientInfo ::= SEQUENCE { + version CMSVersion, -- always set to 3 + originator [0] EXPLICIT OriginatorIdentifierOrKey, + ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, + keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, + recipientEncryptedKeys RecipientEncryptedKeys } + +OriginatorIdentifierOrKey ::= CHOICE { + issuerAndSerialNumber IssuerAndSerialNumber, + subjectKeyIdentifier [0] SubjectKeyIdentifier, + originatorKey [1] OriginatorPublicKey } + +OriginatorPublicKey ::= SEQUENCE { + algorithm AlgorithmIdentifier, + publicKey BIT STRING } + +RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey + +RecipientEncryptedKey ::= SEQUENCE { + rid KeyAgreeRecipientIdentifier, + encryptedKey EncryptedKey } + +KeyAgreeRecipientIdentifier ::= CHOICE { + issuerAndSerialNumber IssuerAndSerialNumber, + rKeyId [0] IMPLICIT RecipientKeyIdentifier } + + + + + + + +Housley Standards Track [Page 49] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +RecipientKeyIdentifier ::= SEQUENCE { + subjectKeyIdentifier SubjectKeyIdentifier, + date GeneralizedTime OPTIONAL, + other OtherKeyAttribute OPTIONAL } + +SubjectKeyIdentifier ::= OCTET STRING + +KEKRecipientInfo ::= SEQUENCE { + version CMSVersion, -- always set to 4 + kekid KEKIdentifier, + keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, + encryptedKey EncryptedKey } + +KEKIdentifier ::= SEQUENCE { + keyIdentifier OCTET STRING, + date GeneralizedTime OPTIONAL, + other OtherKeyAttribute OPTIONAL } + +DigestedData ::= SEQUENCE { + version CMSVersion, + digestAlgorithm DigestAlgorithmIdentifier, + encapContentInfo EncapsulatedContentInfo, + digest Digest } + +Digest ::= OCTET STRING + +EncryptedData ::= SEQUENCE { + version CMSVersion, + encryptedContentInfo EncryptedContentInfo, + unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } + +AuthenticatedData ::= SEQUENCE { + version CMSVersion, + originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, + recipientInfos RecipientInfos, + macAlgorithm MessageAuthenticationCodeAlgorithm, + digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, + encapContentInfo EncapsulatedContentInfo, + authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, + mac MessageAuthenticationCode, + unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } + +AuthAttributes ::= SET SIZE (1..MAX) OF Attribute + +UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute + +MessageAuthenticationCode ::= OCTET STRING + + + + +Housley Standards Track [Page 50] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +DigestAlgorithmIdentifier ::= AlgorithmIdentifier + +SignatureAlgorithmIdentifier ::= AlgorithmIdentifier + +KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier + +ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier + +MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier + +CertificateRevocationLists ::= SET OF CertificateList + +CertificateChoices ::= CHOICE { + certificate Certificate, -- See X.509 + extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete + attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 + +CertificateSet ::= SET OF CertificateChoices + +IssuerAndSerialNumber ::= SEQUENCE { + issuer Name, + serialNumber CertificateSerialNumber } + +CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } + +UserKeyingMaterial ::= OCTET STRING + +OtherKeyAttribute ::= SEQUENCE { + keyAttrId OBJECT IDENTIFIER, + keyAttr ANY DEFINED BY keyAttrId OPTIONAL } + + +-- CMS Attributes + +MessageDigest ::= OCTET STRING + +SigningTime ::= Time + +Time ::= CHOICE { + utcTime UTCTime, + generalTime GeneralizedTime } + +Countersignature ::= SignerInfo + + + + + + + + +Housley Standards Track [Page 51] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +-- Algorithm Identifiers + +sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + oiw(14) secsig(3) algorithm(2) 26 } + +md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) + rsadsi(113549) digestAlgorithm(2) 5 } + +id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) x9-57 (10040) x9cm(4) 3 } + +rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } + +dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) ansi-x942(10046) number-type(2) 1 } + +id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) + rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } + +id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } + +id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } + +des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } + +rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) + rsadsi(113549) encryptionAlgorithm(3) 2 } + +hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } + + +-- Algorithm Parameters + +KeyWrapAlgorithm ::= AlgorithmIdentifier + +RC2wrapParameter ::= RC2ParameterVersion + +RC2ParameterVersion ::= INTEGER + +CBCParameter ::= IV + +IV ::= OCTET STRING -- exactly 8 octets + + + + +Housley Standards Track [Page 52] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +RC2CBCParameter ::= SEQUENCE { + rc2ParameterVersion INTEGER, + iv OCTET STRING } -- exactly 8 octets + + +-- Content Type Object Identifiers + +id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) + ct(1) 6 } + +id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } + +id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } + +id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } + +id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } + +id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } + +id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) + ct(1) 2 } + + +-- Attribute Object Identifiers + +id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } + +id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } + +id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } + +id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } + + + + + + + +Housley Standards Track [Page 53] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +-- Obsolete Extended Certificate syntax from PKCS#6 + +ExtendedCertificate ::= SEQUENCE { + extendedCertificateInfo ExtendedCertificateInfo, + signatureAlgorithm SignatureAlgorithmIdentifier, + signature Signature } + +ExtendedCertificateInfo ::= SEQUENCE { + version CMSVersion, + certificate Certificate, + attributes UnauthAttributes } + +Signature ::= BIT STRING + + +END -- of CryptographicMessageSyntax + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Housley Standards Track [Page 54] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +References + + 3DES American National Standards Institute. ANSI X9.52-1998, + Triple Data Encryption Algorithm Modes of Operation. 1998. + + DES American National Standards Institute. ANSI X3.106, + "American National Standard for Information Systems - Data + Link Encryption". 1983. + + DH-X9.42 Rescorla, E., "Diffie-Hellman Key Agreement Method", + RFC 2631, June 1999. + + DSS National Institute of Standards and Technology. + FIPS Pub 186: Digital Signature Standard. 19 May 1994. + + ESS Hoffman, P., Editor, "Enhanced Security Services for + S/MIME", RFC 2634, June 1999. + + HMAC Krawczyk, H., "HMAC: Keyed-Hashing for Message + Authentication", RFC 2104, February 1997. + + MD5 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + MODES National Institute of Standards and Technology. + FIPS Pub 81: DES Modes of Operation. 2 December 1980. + + MSG Ramsdell, B., Editor, "S/MIME Version 3 Message + Specification", RFC 2633, June 1999. + + NEWPKCS#1 Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0", + RFC 2347, October 1998. + + PROFILE Housley, R., Ford, W., Polk, W. and D. Solo, "Internet + X.509 Public Key Infrastructure: Certificate and CRL + Profile", RFC 2459, January 1999. + + PKCS#1 Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5.", + RFC 2313, March 1998. + + PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax + Standard, Version 1.5. November 1993. + + PKCS#7 Kaliski, B., "PKCS #7: Cryptographic Message Syntax, + Version 1.5.", RFC 2315, March 1998. + + PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, + Version 1.1. November 1993. + + + +Housley Standards Track [Page 55] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + RANDOM Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + RC2 Rivest, R., "A Description of the RC2 (r) Encryption + Algorithm", RFC 2268, March 1998. + + SHA1 National Institute of Standards and Technology. + FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. + + X.208-88 CCITT. Recommendation X.208: Specification of Abstract + Syntax Notation One (ASN.1). 1988. + + X.209-88 CCITT. Recommendation X.209: Specification of Basic + Encoding Rules for Abstract Syntax Notation One (ASN.1). + 1988. + + X.501-88 CCITT. Recommendation X.501: The Directory - Models. + 1988. + + X.509-88 CCITT. Recommendation X.509: The Directory - + Authentication Framework. 1988. + + X.509-97 ITU-T. Recommendation X.509: The Directory - + Authentication Framework. 1997. + +Security Considerations + + The Cryptographic Message Syntax provides a method for digitally + signing data, digesting data, encrypting data, and authenticating + data. + + Implementations must protect the signer's private key. Compromise of + the signer's private key permits masquerade. + + Implementations must protect the key management private key, the + key-encryption key, and the content-encryption key. Compromise of + the key management private key or the key-encryption key may result + in the disclosure of all messages protected with that key. + Similarly, compromise of the content-encryption key may result in + disclosure of the associated encrypted content. + + Implementations must protect the key management private key and the + message-authentication key. Compromise of the key management private + key permits masquerade of authenticated data. Similarly, compromise + of the message-authentication key may result in undetectable + modification of the authenticated content. + + + + + +Housley Standards Track [Page 56] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + Implementations must randomly generate content-encryption keys, + message-authentication keys, initialization vectors (IVs), and + padding. Also, the generation of public/private key pairs relies on + a random numbers. The use of inadequate pseudo-random number + generators (PRNGs) to generate cryptographic keys can result in + little or no security. An attacker may find it much easier to + reproduce the PRNG environment that produced the keys, searching the + resulting small set of possibilities, rather than brute force + searching the whole key space. The generation of quality random + numbers is difficult. RFC 1750 [RANDOM] offers important guidance in + this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality + PRNG technique. + + When using key agreement algorithms or previously distributed + symmetric key-encryption keys, a key-encryption key is used to + encrypt the content-encryption key. If the key-encryption and + content-encryption algorithms are different, the effective security + is determined by the weaker of the two algorithms. If, for example, + a message content is encrypted with 168-bit Triple-DES and the + Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, + then at most 40 bits of protection is provided. A trivial search to + determine the value of the 40-bit RC2 key can recover Triple-DES key, + and then the Triple-DES key can be used to decrypt the content. + Therefore, implementers must ensure that key-encryption algorithms + are as strong or stronger than content-encryption algorithms. + + Section 12.6 specifies key wrap algorithms used to encrypt a Triple- + DES [3DES] content-encryption key with a Triple-DES key-encryption + key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key- + encryption key. The key wrap algorithms make use of CBC mode + [MODES]. These key wrap algorithms have been reviewed for use with + Triple and RC2. They have not been reviewed for use with other + cryptographic modes or other encryption algorithms. Therefore, if a + CMS implementation wishes to support ciphers in addition to Triple- + DES or RC2, then additional key wrap algorithms need to be defined to + support the additional ciphers. + + Implementers should be aware that cryptographic algorithms become + weaker with time. As new cryptoanalysis techniques are developed and + computing performance improves, the work factor to break a particular + cryptographic algorithm will reduce. Therefore, cryptographic + algorithm implementations should be modular allowing new algorithms + to be readily inserted. That is, implementers should be prepared for + the set of mandatory to implement algorithms to change over time. + + The countersignature unauthenticated attribute includes a digital + signature that is computed on the content signature value, thus the + countersigning process need not know the original signed content. + + + +Housley Standards Track [Page 57] + +RFC 2630 Cryptographic Message Syntax June 1999 + + + This structure permits implementation efficiency advantages; however, + this structure may also permit the countersigning of an inappropriate + signature value. Therefore, implementations that perform + countersignatures should either verify the original signature value + prior to countersigning it (this verification requires processing of + the original content), or implementations should perform + countersigning in a context that ensures that only appropriate + signature values are countersigned. + + Users of CMS, particularly those employing CMS to support interactive + applications, should be aware that PKCS #1 Version 1.5 as specified + in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext + attacks when applied for encryption purposes. Exploitation of this + identified vulnerability, revealing the result of a particular RSA + decryption, requires access to an oracle which will respond to a + large number of ciphertexts (based on currently available results, + hundreds of thousands or more), which are constructed adaptively in + response to previously-received replies providing information on the + successes or failures of attempted decryption operations. As a + result, the attack appears significantly less feasible to perpetrate + for store-and-forward S/MIME environments than for directly + interactive protocols. Where CMS constructs are applied as an + intermediate encryption layer within an interactive request-response + communications environment, exploitation could be more feasible. + + An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 + [NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1 + Version 2.0 preserves support for the encryption padding format + defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new + alternative. To resolve the adaptive chosen ciphertext + vulnerability, the PKCS #1 Version 2.0 specifies and recommends use + of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption + is used to provide confidentiality. Designers of protocols and + systems employing CMS for interactive environments should either + consider usage of OAEP, or should ensure that information which could + reveal the success or failure of attempted PKCS #1 Version 1.5 + decryption operations is not provided. Support for OAEP will likely + be added to a future version of the CMS specification. + +Acknowledgments + + This document is the result of contributions from many professionals. + I appreciate the hard work of all members of the IETF S/MIME Working + Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve + Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, + Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, + John Pawling, Blake Ramsdell, Francois Rousseau, Jim Schaad, and Dave + Solo for their efforts and support. + + + +Housley Standards Track [Page 58] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +Author's Address + + Russell Housley + SPYRUS + 381 Elden Street + Suite 1120 + Herndon, VA 20170 + USA + + EMail: housley@spyrus.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Housley Standards Track [Page 59] + +RFC 2630 Cryptographic Message Syntax June 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Housley Standards Track [Page 60] + |