draft-ietf-smime-cms-12.txt   rfc2630.txt 
S/MIME Working Group R. Housley Network Working Group R. Housley
Internet Draft SPYRUS Request for Comments: 2630 SPYRUS
expires in six months March 1999 Category: Standards Track June 1999
Cryptographic Message Syntax Cryptographic Message Syntax
<draft-ietf-smime-cms-12.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet-Drafts are working Internet community, and requests discussion and suggestions for
documents of the Internet Engineering Task Force (IETF), its areas, improvements. Please refer to the current edition of the "Internet
and its working groups. Note that other groups may also distribute Official Protocol Standards" (STD 1) for the standardization state
working documents as Internet-Drafts. and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the Copyright (C) The Internet Society (1999). All Rights Reserved.
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
This document describes the Cryptographic Message Syntax. This This document describes the Cryptographic Message Syntax. This
syntax is used to digitally sign, digest, authenticate, or encrypt syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages. arbitrary messages.
The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 The Cryptographic Message Syntax is derived from PKCS #7 version 1.5
as specified in RFC 2315 [PKCS#7]. Wherever possible, backward as specified in RFC 2315 [PKCS#7]. Wherever possible, backward
compatibility is preserved; however, changes were necessary to compatibility is preserved; however, changes were necessary to
accommodate attribute certificate transfer and key agreement accommodate attribute certificate transfer and key agreement
techniques for key management. techniques for key management.
This draft is being discussed on the "ietf-smime" mailing list. To
join the list, send a message to <ietf-smime-request@imc.org> with
the single word "subscribe" in the body of the message. Also, there
is a Web site for the mailing list at <http://www.imc.org/ietf-
smime/>.
Table of Contents Table of Contents
Status of this Memo .................................................. 1 1 Introduction ................................................. 4
Abstract ............................................................. 1 2 General Overview ............................................. 4
Table of Contents .................................................... 2 3 General Syntax ............................................... 5
1 Introduction ..................................................... 4 4 Data Content Type ............................................ 5
2 General Overview ................................................. 4 5 Signed-data Content Type ..................................... 6
3 General Syntax ................................................... 5 5.1 SignedData Type ......................................... 7
4 Data Content Type ................................................ 5 5.2 EncapsulatedContentInfo Type ............................ 8
5 Signed-data Content Type ......................................... 6 5.3 SignerInfo Type ......................................... 9
5.1 SignedData Type ............................................. 7 5.4 Message Digest Calculation Process ...................... 11
5.2 EncapsulatedContentInfo Type ................................ 8 5.5 Message Signature Generation Process .................... 12
5.3 SignerInfo Type ............................................. 9 5.6 Message Signature Verification Process .................. 12
5.4 Message Digest Calculation Process .......................... 11 6 Enveloped-data Content Type .................................. 12
5.5 Message Signature Generation Process ........................ 12 6.1 EnvelopedData Type ...................................... 14
5.6 Message Signature Verification Process ...................... 12 6.2 RecipientInfo Type ...................................... 15
6 Enveloped-data Content Type ...................................... 12 6.2.1 KeyTransRecipientInfo Type ....................... 16
6.1 EnvelopedData Type .......................................... 14 6.2.2 KeyAgreeRecipientInfo Type ....................... 17
6.2 RecipientInfo Type .......................................... 15 6.2.3 KEKRecipientInfo Type ............................ 19
6.2.1 KeyTransRecipientInfo Type ........................... 16 6.3 Content-encryption Process .............................. 20
6.2.2 KeyAgreeRecipientInfo Type ........................... 17 6.4 Key-encryption Process .................................. 20
6.2.3 KEKRecipientInfo Type ................................ 19 7 Digested-data Content Type ................................... 21
6.3 Content-encryption Process .................................. 20 8 Encrypted-data Content Type .................................. 22
6.4 Key-encryption Process ...................................... 20 9 Authenticated-data Content Type .............................. 23
7 Digested-data Content Type ....................................... 21 9.1 AuthenticatedData Type .................................. 23
8 Encrypted-data Content Type ...................................... 22 9.2 MAC Generation .......................................... 25
9 Authenticated-data Content Type .................................. 23 9.3 MAC Verification ........................................ 26
9.1 AuthenticatedData Type ...................................... 23 10 Useful Types ................................................. 27
9.2 MAC Generation .............................................. 25 10.1 Algorithm Identifier Types ............................. 27
9.3 MAC Verification ............................................ 26 10.1.1 DigestAlgorithmIdentifier ...................... 27
10 Useful Types ..................................................... 27 10.1.2 SignatureAlgorithmIdentifier ................... 27
10.1 Algorithm Identifier Types ................................. 27 10.1.3 KeyEncryptionAlgorithmIdentifier ............... 28
10.1.1 DigestAlgorithmIdentifier .......................... 27 10.1.4 ContentEncryptionAlgorithmIdentifier ........... 28
10.1.2 SignatureAlgorithmIdentifier ....................... 27 10.1.5 MessageAuthenticationCodeAlgorithm ............. 28
10.1.3 KeyEncryptionAlgorithmIdentifier ................... 27 10.2 Other Useful Types ..................................... 28
10.1.4 ContentEncryptionAlgorithmIdentifier ............... 28 10.2.1 CertificateRevocationLists ..................... 28
10.1.5 MessageAuthenticationCodeAlgorithm ................. 28 10.2.2 CertificateChoices ............................. 29
10.2 Other Useful Types ......................................... 28 10.2.3 CertificateSet ................................. 29
10.2.1 CertificateRevocationLists ......................... 28 10.2.4 IssuerAndSerialNumber .......................... 30
10.2.2 CertificateChoices ................................. 29 10.2.5 CMSVersion ..................................... 30
10.2.3 CertificateSet ..................................... 29 10.2.6 UserKeyingMaterial ............................. 30
10.2.4 IssuerAndSerialNumber .............................. 29 10.2.7 OtherKeyAttribute .............................. 30
10.2.5 CMSVersion ......................................... 30
10.2.6 UserKeyingMaterial ................................. 30
10.2.7 OtherKeyAttribute .................................. 30
11 Useful Attributes ................................................ 30 11 Useful Attributes ............................................ 31
11.1 Content Type ............................................... 31 11.1 Content Type ........................................... 31
11.2 Message Digest ............................................. 31 11.2 Message Digest ......................................... 32
11.3 Signing Time ............................................... 32 11.3 Signing Time ........................................... 32
11.4 Countersignature ........................................... 33 11.4 Countersignature ....................................... 34
12 Supported Algorithms ............................................. 34 12 Supported Algorithms ......................................... 35
12.1 Digest Algorithms .......................................... 34 12.1 Digest Algorithms ...................................... 35
12.1.1 SHA-1 .............................................. 35 12.1.1 SHA-1 .......................................... 35
12.1.2 MD5 ................................................ 35 12.1.2 MD5 ............................................ 35
12.2 Signature Algorithms ....................................... 35 12.2 Signature Algorithms ................................... 36
12.2.1 DSA ................................................ 36 12.2.1 DSA ............................................ 36
12.2.2 RSA ................................................ 36 12.2.2 RSA ............................................ 36
12.3 Key Management Algorithms .................................. 36 12.3 Key Management Algorithms .............................. 36
12.3.1 Key Agreement Algorithms ........................... 36 12.3.1 Key Agreement Algorithms ....................... 36
12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman .... 37 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman. 37
12.3.2 Key Transport Algorithms ........................... 38 12.3.2 Key Transport Algorithms ....................... 38
12.3.2.1 RSA ...................................... 38 12.3.2.1 RSA .................................. 39
12.3.3 Symmetric Key-Encryption Key Algorithms ............ 39 12.3.3 Symmetric Key-Encryption Key Algorithms ........ 39
12.3.3.1 Triple-DES Key Wrap ...................... 40 12.3.3.1 Triple-DES Key Wrap .................. 40
12.3.3.2 RC2 Key Wrap ............................. 40 12.3.3.2 RC2 Key Wrap ......................... 41
12.4 Content Encryption Algorithms ............................... 41 12.4 Content Encryption Algorithms ........................... 41
12.4.1 Triple-DES CBC ...................................... 41 12.4.1 Triple-DES CBC .................................. 42
12.4.2 RC2 CBC ............................................. 41 12.4.2 RC2 CBC ......................................... 42
12.5 Message Authentication Code Algorithms ...................... 42 12.5 Message Authentication Code Algorithms .................. 42
12.5.1 HMAC with SHA-1 ..................................... 42 12.5.1 HMAC with SHA-1 ................................. 43
12.6 Triple-DES and RC2 Key Wrap Algorithms ...................... 42 12.6 Triple-DES and RC2 Key Wrap Algorithms .................. 43
12.6.1 Key Checksum ........................................ 43 12.6.1 Key Checksum .................................... 44
12.6.2 Triple-DES Key Wrap ................................. 43 12.6.2 Triple-DES Key Wrap ............................. 44
12.6.3 Triple-DES Key Unwrap ............................... 44 12.6.3 Triple-DES Key Unwrap ........................... 44
12.6.4 RC2 Key Wrap ........................................ 44 12.6.4 RC2 Key Wrap .................................... 45
12.6.5 RC2 Key Unwrap ...................................... 45 12.6.5 RC2 Key Unwrap .................................. 46
Appendix A: ASN.1 Module ............................................ 46 Appendix A: ASN.1 Module ........................................ 47
References ........................................................... 54 References ....................................................... 55
Security Considerations .............................................. 55 Security Considerations .......................................... 56
Acknowledgments ...................................................... 57 Acknowledgments .................................................. 58
Author Address ....................................................... 58 Author's Address ................................................. 59
Full Copyright Statement ............................................. 58 Full Copyright Statement ......................................... 60
1 Introduction 1 Introduction
This document describes the Cryptographic Message Syntax. This This document describes the Cryptographic Message Syntax. This
syntax is used to digitally sign, digest, authenticate, or encrypt syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages. arbitrary messages.
The Cryptographic Message Syntax describes an encapsulation syntax The Cryptographic Message Syntax describes an encapsulation syntax
for data protection. It supports digital signatures and encryption. for data protection. It supports digital signatures, message
The syntax allows multiple encapsulation, so one encapsulation authentication codes, and encryption. The syntax allows multiple
envelope can be nested inside another. Likewise, one party can encapsulation, so one encapsulation envelope can be nested inside
digitally sign some previously encapsulated data. It also allows another. Likewise, one party can digitally sign some previously
arbitrary attributes, such as signing time, to be signed along with encapsulated data. It also allows arbitrary attributes, such as
the message content, and provides for other attributes such as signing time, to be signed along with the message content, and
countersignatures to be associated with a signature. provides for other attributes such as countersignatures to be
associated with a signature.
The Cryptographic Message Syntax can support a variety of The Cryptographic Message Syntax can support a variety of
architectures for certificate-based key management, such as the one architectures for certificate-based key management, such as the one
defined by the PKIX working group. defined by the PKIX working group.
The Cryptographic Message Syntax values are generated using ASN.1, The Cryptographic Message Syntax values are generated using ASN.1
using BER-encoding. Values are typically represented as octet [X.208-88], using BER-encoding [X.209-88]. Values are typically
strings. While many systems are capable of transmitting arbitrary represented as octet strings. While many systems are capable of
octet strings reliably, it is well known that many electronic-mail transmitting arbitrary octet strings reliably, it is well known that
systems are not. This document does not address mechanisms for many electronic-mail systems are not. This document does not address
encoding octet strings for reliable transmission in such mechanisms for encoding octet strings for reliable transmission in
environments. such environments.
2 General Overview 2 General Overview
The Cryptographic Message Syntax (CMS) is general enough to support The Cryptographic Message Syntax (CMS) is general enough to support
many different content types. This document defines one protection many different content types. This document defines one protection
content, ContentInfo. ContentInfo encapsulates a single identified content, ContentInfo. ContentInfo encapsulates a single identified
content type, and the identified type may provide further content type, and the identified type may provide further
encapsulation. This document defines six content types: data, encapsulation. This document defines six content types: data,
signed-data, enveloped-data, digested-data, encrypted-data, and signed-data, enveloped-data, digested-data, encrypted-data, and
authenticated-data. Additional content types can be defined outside authenticated-data. Additional content types can be defined outside
skipping to change at page 5, line 5 skipping to change at page 5, line 6
the protection content, ContentInfo, and must implement the data, the protection content, ContentInfo, and must implement the data,
signed-data, and enveloped-data content types. The other content signed-data, and enveloped-data content types. The other content
types may be implemented if desired. types may be implemented if desired.
As a general design philosophy, each content type permits single pass As a general design philosophy, each content type permits single pass
processing using indefinite-length Basic Encoding Rules (BER) processing using indefinite-length Basic Encoding Rules (BER)
encoding. Single-pass operation is especially helpful if content is encoding. Single-pass operation is especially helpful if content is
large, stored on tapes, or is "piped" from another process. Single- large, stored on tapes, or is "piped" from another process. Single-
pass operation has one significant drawback: it is difficult to pass operation has one significant drawback: it is difficult to
perform encode operations using the Distinguished Encoding Rules perform encode operations using the Distinguished Encoding Rules
(DER) encoding in a single pass since the lengths of the various (DER) [X.509-88] encoding in a single pass since the lengths of the
components may not be known in advance. However, signed attributes various components may not be known in advance. However, signed
within the signed-data content type and authenticated attributes attributes within the signed-data content type and authenticated
within the authenticated-data content type require DER encoding. attributes within the authenticated-data content type require DER
Signed attributes and authenticated attributes must be transmitted in encoding. Signed attributes and authenticated attributes must be
DER form to ensure that recipients can verify a content that contains transmitted in DER form to ensure that recipients can verify a
one or more unrecognized attributes. Signed attributes and content that contains one or more unrecognized attributes. Signed
authenticated attributes are the only CMS data types that require DER attributes and authenticated attributes are the only CMS data types
encoding. that require DER encoding.
3 General Syntax 3 General Syntax
The Cryptographic Message Syntax (CMS) associates a content type The Cryptographic Message Syntax (CMS) associates a content type
identifier with a content. The syntax shall have ASN.1 type identifier with a content. The syntax shall have ASN.1 type
ContentInfo: ContentInfo:
ContentInfo ::= SEQUENCE { ContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType } content [0] EXPLICIT ANY DEFINED BY contentType }
skipping to change at page 20, line 47 skipping to change at page 20, line 47
k k ... k k -- if lth mod k = 0 k k ... k k -- if lth mod k = 0
The padding can be removed unambiguously since all input is padded, The padding can be removed unambiguously since all input is padded,
including input values that are already a multiple of the block size, 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 and no padding string is a suffix of another. This padding method is
well defined if and only if k is less than 256. well defined if and only if k is less than 256.
6.4 Key-encryption Process 6.4 Key-encryption Process
The input to the key-encryption process -- the value supplied to the The input to the key-encryption process -- the value supplied to the
recipient's key-encryption algorithm --is just the "value" of the recipient's key-encryption algorithm -- is just the "value" of the
content-encryption key. content-encryption key.
Any of the three key management techniques can be used for each Any of the three key management techniques can be used for each
recipient of the same encrypted content. recipient of the same encrypted content.
7 Digested-data Content Type 7 Digested-data Content Type
The digested-data content type consists of content of any type and a The digested-data content type consists of content of any type and a
message digest of the content. message digest of the content.
skipping to change at page 27, line 19 skipping to change at page 27, line 20
10 Useful Types 10 Useful Types
This section is divided into two parts. The first part defines This section is divided into two parts. The first part defines
algorithm identifiers, and the second part defines other useful algorithm identifiers, and the second part defines other useful
types. types.
10.1 Algorithm Identifier Types 10.1 Algorithm Identifier Types
All of the algorithm identifiers have the same type: All of the algorithm identifiers have the same type:
AlgorithmIdentifier. The definition of AlgorithmIdentifier is AlgorithmIdentifier. The definition of AlgorithmIdentifier is
imported from X.509. imported from X.509 [X.509-88].
There are many alternatives for each type of algorithm listed. For There are many alternatives for each type of algorithm listed. For
each of these five types, Section 12 lists the algorithms that must each of these five types, Section 12 lists the algorithms that must
be included in a CMS implementation. be included in a CMS implementation.
10.1.1 DigestAlgorithmIdentifier 10.1.1 DigestAlgorithmIdentifier
The DigestAlgorithmIdentifier type identifies a message-digest The DigestAlgorithmIdentifier type identifies a message-digest
algorithm. Examples include SHA-1, MD2, and MD5. 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 algorithm maps an octet string (the message) to another octet string
skipping to change at page 29, line 7 skipping to change at page 29, line 12
revocation lists (CRLs). It is intended that the set contain revocation lists (CRLs). It is intended that the set contain
information sufficient to determine whether the certificates and information sufficient to determine whether the certificates and
attribute certificates with which the set is associated are revoked attribute certificates with which the set is associated are revoked
or not. However, there may be more CRLs than necessary or there may or not. However, there may be more CRLs than necessary or there may
be fewer CRLs than necessary. be fewer CRLs than necessary.
The CertificateList may contain a CRL, an Authority Revocation List The CertificateList may contain a CRL, an Authority Revocation List
(ARL), a Delta Revocation List, or an Attribute Certificate (ARL), a Delta Revocation List, or an Attribute Certificate
Revocation List. All of these lists share a common syntax. Revocation List. All of these lists share a common syntax.
CRLs are specified in X.509, and they are profiled for use in the CRLs are specified in X.509 [X.509-97], and they are profiled for use
Internet in RFC 2459 [PROFILE]. in the Internet in RFC 2459 [PROFILE].
The definition of CertificateList is imported from X.509. The definition of CertificateList is imported from X.509.
CertificateRevocationLists ::= SET OF CertificateList CertificateRevocationLists ::= SET OF CertificateList
10.2.2 CertificateChoices 10.2.2 CertificateChoices
The CertificateChoices type gives either a PKCS #6 extended The CertificateChoices type gives either a PKCS #6 extended
certificate [PKCS#6], an X.509 certificate, or an X.509 attribute certificate [PKCS#6], an X.509 certificate, or an X.509 attribute
certificate. The PKCS #6 extended certificate is obsolete. PKCS #6 certificate [X.509-97]. The PKCS #6 extended certificate is
certificates are included for backward compatibility, and their use obsolete. PKCS #6 certificates are included for backward
should be avoided. The Internet profile of X.509 certificates is compatibility, and their use should be avoided. The Internet profile
specified in the "Internet X.509 Public Key Infrastructure: of X.509 certificates is specified in the "Internet X.509 Public Key
Certificate and CRL Profile" [PROFILE]. Infrastructure: Certificate and CRL Profile" [PROFILE].
The definitions of Certificate and AttributeCertificate are imported The definitions of Certificate and AttributeCertificate are imported
from X.509. from X.509.
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509 certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete extendedCertificate [0] IMPLICIT ExtendedCertificate,
attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 -- Obsolete
attrCert [1] IMPLICIT AttributeCertificate }
-- See X.509 and X9.57
10.2.3 CertificateSet 10.2.3 CertificateSet
The CertificateSet type provides a set of certificates. It is The CertificateSet type provides a set of certificates. It is
intended that the set be sufficient to contain chains from a intended that the set be sufficient to contain chains from a
recognized "root" or "top-level certification authority" to all of recognized "root" or "top-level certification authority" to all of
the sender certificates with which the set is associated. However, the sender certificates with which the set is associated. However,
there may be more certificates than necessary, or there may be fewer there may be more certificates than necessary, or there may be fewer
than necessary. than necessary.
skipping to change at page 30, line 6 skipping to change at page 30, line 13
subjects and issuers of certificates within a chain. subjects and issuers of certificates within a chain.
CertificateSet ::= SET OF CertificateChoices CertificateSet ::= SET OF CertificateChoices
10.2.4 IssuerAndSerialNumber 10.2.4 IssuerAndSerialNumber
The IssuerAndSerialNumber type identifies a certificate, and thereby The IssuerAndSerialNumber type identifies a certificate, and thereby
an entity and a public key, by the distinguished name of the an entity and a public key, by the distinguished name of the
certificate issuer and an issuer-specific certificate serial number. certificate issuer and an issuer-specific certificate serial number.
The definition of Name is imported from X.501, and the definition of The definition of Name is imported from X.501 [X.501-88], and the
CertificateSerialNumber is imported from X.509. definition of CertificateSerialNumber is imported from X.509
[X.509-97].
IssuerAndSerialNumber ::= SEQUENCE { IssuerAndSerialNumber ::= SEQUENCE {
issuer Name, issuer Name,
serialNumber CertificateSerialNumber } serialNumber CertificateSerialNumber }
CertificateSerialNumber ::= INTEGER CertificateSerialNumber ::= INTEGER
10.2.5 CMSVersion 10.2.5 CMSVersion
The Version type gives a syntax version number, for compatibility The Version type gives a syntax version number, for compatibility
skipping to change at page 30, line 46 skipping to change at page 31, line 7
the sender. The attribute object identifier must be registered along the sender. The attribute object identifier must be registered along
with the syntax of the attribute itself. Use of this structure with the syntax of the attribute itself. Use of this structure
should be avoided since it may impede interoperability. should be avoided since it may impede interoperability.
OtherKeyAttribute ::= SEQUENCE { OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER, keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL } keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
11 Useful Attributes 11 Useful Attributes
This section defines attributes that may used with signed-data, This section defines attributes that may be used with signed-data,
enveloped-data, encrypted-data, or authenticated-data. Some of the enveloped-data, encrypted-data, or authenticated-data. The syntax of
attributes defined in this section were originally defined in PKCS #9 Attribute is compatible with X.501 [X.501-88] and RFC 2459 [PROFILE].
[PKCS#9], others were not previously defined. The attributes are not Some of the attributes defined in this section were originally
listed in any particular order. 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 Additional attributes are defined in many places, notably the S/MIME
Version 3 Message Specification [MSG] and the Enhanced Security Version 3 Message Specification [MSG] and the Enhanced Security
Services for S/MIME [ESS], which also include recommendations on the Services for S/MIME [ESS], which also include recommendations on the
placement of these attributes. placement of these attributes.
11.1 Content Type 11.1 Content Type
The content-type attribute type specifies the content type of the The content-type attribute type specifies the content type of the
ContentInfo value being signed in signed-data. The content-type ContentInfo value being signed in signed-data. The content-type
attribute type is required if there are any authenticated attributes attribute type is required if there are any authenticated attributes
present. present.
The content-type attribute must be a signed attribute or an The content-type attribute must be a signed attribute or an
authenticated attribute; it cannot be an unsigned attribute or authenticated attribute; it cannot be an unsigned attribute, an
unauthenticated attribute. unauthenticated attribute, or an unprotectedAttribute.
The following object identifier identifies the content-type The following object identifier identifies the content-type
attribute: attribute:
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
Content-type attribute values have ASN.1 type ContentType: Content-type attribute values have ASN.1 type ContentType:
ContentType ::= OBJECT IDENTIFIER ContentType ::= OBJECT IDENTIFIER
skipping to change at page 33, line 6 skipping to change at page 33, line 20
Signing-time attribute values have ASN.1 type SigningTime: Signing-time attribute values have ASN.1 type SigningTime:
SigningTime ::= Time SigningTime ::= Time
Time ::= CHOICE { Time ::= CHOICE {
utcTime UTCTime, utcTime UTCTime,
generalizedTime GeneralizedTime } generalizedTime GeneralizedTime }
Note: The definition of Time matches the one specified in the 1997 Note: The definition of Time matches the one specified in the 1997
version of X.509. version of X.509 [X.509-97].
Dates between 1 January 1950 and 31 December 2049 (inclusive) must be Dates between 1 January 1950 and 31 December 2049 (inclusive) must be
encoded as UTCTime. Any dates with year values before 1950 or after encoded as UTCTime. Any dates with year values before 1950 or after
2049 must be encoded as GeneralizedTime. 2049 must be encoded as GeneralizedTime.
UTCTime values must be expressed in Greenwich Mean Time (Zulu) and UTCTime values must be expressed in Greenwich Mean Time (Zulu) and
must include seconds (i.e., times are YYMMDDHHMMSSZ), even where the must include seconds (i.e., times are YYMMDDHHMMSSZ), even where the
number of seconds is zero. Midnight (GMT) must be represented as number of seconds is zero. Midnight (GMT) must be represented as
"YYMMDD000000Z". Century information is implicit, and the century "YYMMDD000000Z". Century information is implicit, and the century
must be determined as follows: must be determined as follows:
skipping to change at page 36, line 34 skipping to change at page 36, line 48
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
12.3 Key Management Algorithms 12.3 Key Management Algorithms
CMS accommodates three general key management techniques: key CMS accommodates three general key management techniques: key
agreement, key transport, and previously distributed symmetric key- agreement, key transport, and previously distributed symmetric key-
encryption keys. encryption keys.
12.3.1 Key Agreement Algorithms 12.3.1 Key Agreement Algorithms
CMS implementations must include key agreement using X9.42 Ephemeral- CMS implementations must include key agreement using X9.42
Static Diffie-Hellman. Ephemeral-Static Diffie-Hellman.
Any symmetric encryption algorithm that a CMS implementation includes Any symmetric encryption algorithm that a CMS implementation includes
as a content-encryption algorithm must also be included as a key- as a content-encryption algorithm must also be included as a key-
encryption algorithm. CMS implementations must include key agreement encryption algorithm. CMS implementations must include key agreement
of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of
Triple-DES content-encryption keys. CMS implementations should Triple-DES content-encryption keys. CMS implementations should
include key agreement of RC2 pairwise key-encryption keys and RC2 include key agreement of RC2 pairwise key-encryption keys and RC2
wrapping of RC2 content-encryption keys. The key wrap algorithm for wrapping of RC2 content-encryption keys. The key wrap algorithm for
Triple-DES and RC2 is described in section 12.3.3. Triple-DES and RC2 is described in section 12.3.3.
skipping to change at page 37, line 8 skipping to change at page 37, line 22
encryption algorithms. For example, a 128-bit RC2 content-encryption encryption algorithms. For example, a 128-bit RC2 content-encryption
key may be wrapped with 168-bit Triple-DES key-encryption key. key may be wrapped with 168-bit Triple-DES key-encryption key.
Similarly, a 40-bit RC2 content-encryption key may be wrapped with Similarly, a 40-bit RC2 content-encryption key may be wrapped with
128-bit RC2 key-encryption key. 128-bit RC2 key-encryption key.
For key agreement of RC2 key-encryption keys, 128 bits must be For key agreement of RC2 key-encryption keys, 128 bits must be
generated as input to the key expansion process used to compute the generated as input to the key expansion process used to compute the
RC2 effective key [RC2]. RC2 effective key [RC2].
Key agreement algorithm identifiers are located in the EnvelopedData Key agreement algorithm identifiers are located in the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm and RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfo KeyAgreeRecipientInfo AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
keyEncryptionAlgorithm fields. keyEncryptionAlgorithm fields.
Key wrap algorithm identifiers are located in the KeyWrapAlgorithm Key wrap algorithm identifiers are located in the KeyWrapAlgorithm
parameters within the EnvelopedData RecipientInfo parameters within the EnvelopedData RecipientInfos
KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData
RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
Wrapped content-encryption keys are located in the EnvelopedData Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
encryptedKey and AuthenticatedData RecipientInfo encryptedKey field. Wrapped message-authentication keys are located
KeyAgreeRecipientInfo recipientEncryptedKeys encryptedKey fields. in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
RecipientEncryptedKeys encryptedKey field.
12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman
Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631
[DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the
EnvelopedData RecipientInfo KeyAgreeRecipientInfo and EnvelopedData RecipientInfos KeyAgreeRecipientInfo and
AuthenticatedData RecipientInfo KeyAgreeRecipientInfo fields are used AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are
as follows: used as follows:
version must be 3. version must be 3.
originator must be the originatorKey alternative. The originator must be the originatorKey alternative. The
originatorKey algorithm fields must contain the dh-public-number originatorKey algorithm fields must contain the dh-public-number
object identifier with absent parameters. The originatorKey object identifier with absent parameters. The originatorKey
publicKey field must contain the sender's ephemeral public key. publicKey field must contain the sender's ephemeral public key.
The dh-public-number object identifier is: The dh-public-number object identifier is:
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
skipping to change at page 38, line 7 skipping to change at page 38, line 22
keyEncryptionAlgorithm must be the id-alg-ESDH algorithm keyEncryptionAlgorithm must be the id-alg-ESDH algorithm
identifier. The algorithm identifier parameter field for id-alg- identifier. The algorithm identifier parameter field for id-alg-
ESDH is KeyWrapAlgorihtm, and this parameter must be present. The ESDH is KeyWrapAlgorihtm, and this parameter must be present. The
KeyWrapAlgorithm denotes the symmetric encryption algorithm used KeyWrapAlgorithm denotes the symmetric encryption algorithm used
to encrypt the content-encryption key with the pairwise key- to encrypt the content-encryption key with the pairwise key-
encryption key generated using the Ephemeral-Static Diffie-Hellman encryption key generated using the Ephemeral-Static Diffie-Hellman
key agreement algorithm. Triple-DES and RC2 key wrap algorithms key agreement algorithm. Triple-DES and RC2 key wrap algorithms
are discussed in section 12.3.3. The id-alg-ESDH algorithm are discussed in section 12.3.3. The id-alg-ESDH algorithm
identifier and parameter syntax is: identifier and parameter syntax is:
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
KeyWrapAlgorithm ::= AlgorithmIdentifier KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier must contain either the KeyAgreeRecipientIdentifier must contain either the
issuerAndSerialNumber identifying the recipient's certificate or issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static public key. certificate contains the recipient's static public key.
RecipientEncryptedKey EncryptedKey must contain the content- RecipientEncryptedKey EncryptedKey must contain the content-
encryption key encrypted with the Ephemeral-Static Diffie-Hellman encryption key encrypted with the Ephemeral-Static Diffie-Hellman
skipping to change at page 38, line 32 skipping to change at page 38, line 47
specified by the KeyWrapAlgortihm. specified by the KeyWrapAlgortihm.
12.3.2 Key Transport Algorithms 12.3.2 Key Transport Algorithms
CMS implementations should include key transport using RSA. RSA CMS implementations should include key transport using RSA. RSA
implementations must include key transport of Triple-DES content- implementations must include key transport of Triple-DES content-
encryption keys. RSA implementations should include key transport of encryption keys. RSA implementations should include key transport of
RC2 content-encryption keys. RC2 content-encryption keys.
Key transport algorithm identifiers are located in the EnvelopedData Key transport algorithm identifiers are located in the EnvelopedData
RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm and RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfo KeyTransRecipientInfo AuthenticatedData RecipientInfos KeyTransRecipientInfo
keyEncryptionAlgorithm fields. keyEncryptionAlgorithm fields.
Key transport encrypted content-encryption keys are located in the Key transport encrypted content-encryption keys are located in the
EnvelopedData RecipientInfo KeyTransRecipientInfo EncryptedKey and EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey
AuthenticatedData RecipientInfo KeyTransRecipientInfo EncryptedKey field. Key transport encrypted message-authentication keys are
fields. located in the AuthenticatedData RecipientInfos KeyTransRecipientInfo
encryptedKey field.
12.3.2.1 RSA 12.3.2.1 RSA
The RSA key transport algorithm is the RSA encryption scheme defined 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 in RFC 2313 [PKCS#1], block type is 02, where the message to be
encrypted is the content-encryption key. The algorithm identifier encrypted is the content-encryption key. The algorithm identifier
for RSA is: for RSA is:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
skipping to change at page 39, line 18 skipping to change at page 39, line 33
encryption. encryption.
The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to
provide confidentiality has a known vulnerability concerns. The provide confidentiality has a known vulnerability concerns. The
vulnerability is primarily relevant to usage in interactive vulnerability is primarily relevant to usage in interactive
applications rather than to store-and-forward environments. Further applications rather than to store-and-forward environments. Further
information and proposed countermeasures are discussed in the information and proposed countermeasures are discussed in the
Security Considerations section of this document. Security Considerations section of this document.
Note that the same encryption scheme is also defined in RFC 2437 Note that the same encryption scheme is also defined in RFC 2437
[NEWPKCS#1]. Within RFC 2437, this scheme is called RSAES- [NEWPKCS#1]. Within RFC 2437, this scheme is called
PKCS1-v1_5. RSAES-PKCS1-v1_5.
12.3.3 Symmetric Key-Encryption Key Algorithms 12.3.3 Symmetric Key-Encryption Key Algorithms
CMS implementations may include symmetric key-encryption key CMS implementations may include symmetric key-encryption key
management. Such CMS implementations must include Triple-DES key- management. Such CMS implementations must include Triple-DES key-
encryption keys wrapping Triple-DES content-encryption keys, and such encryption keys wrapping Triple-DES content-encryption keys, and such
CMS implementations should include RC2 key-encryption keys wrapping CMS implementations should include RC2 key-encryption keys wrapping
RC2 content-encryption keys. A CMS implementation may support mixed RC2 content-encryption keys. Only 128-bit RC2 keys may be used as
key-encryption and content-encryption algorithms. For example, a key-encryption keys, and they must be used with the
40-bit RC2 content-encryption key may be wrapped with 168-bit Triple- RC2ParameterVersion parameter set to 58. A CMS implementation may
DES key-encryption key or with a 128-bit RC2 key-encryption key. 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.
Key wrap algorithm identifiers are located in the EnvelopedData Key wrap algorithm identifiers are located in the EnvelopedData
RecipientInfo KEKRecipientInfo keyEncryptionAlgorithm and RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfo KEKRecipientInfo AuthenticatedData RecipientInfos KEKRecipientInfo
keyEncryptionAlgorithm fields. keyEncryptionAlgorithm fields.
Wrapped content-encryption keys are located in the EnvelopedData Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfo KEKRecipientInfo encryptedKey and AuthenticatedData RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped
RecipientInfo KEKRecipientInfo encryptedKey fields. 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 The output of a key agreement algorithm is a key-encryption key, and
this key-encryption key is used to encrypt the content-encryption this key-encryption key is used to encrypt the content-encryption
key. In conjunction with key agreement algorithms, CMS key. In conjunction with key agreement algorithms, CMS
implementations must include encryption of content-encryption keys implementations must include encryption of content-encryption keys
with the pairwise key-encryption key generated using a key agreement with the pairwise key-encryption key generated using a key agreement
algorithm. To support key agreement, key wrap algorithm identifiers algorithm. To support key agreement, key wrap algorithm identifiers
are located in the KeyWrapAlgorithm parameter of the EnvelopedData are located in the KeyWrapAlgorithm parameter of the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm and RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfo KeyAgreeRecipientInfo AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
keyEncryptionAlgorithm fields, and wrapped content-encryption keys keyEncryptionAlgorithm fields. Wrapped content-encryption keys are
are located in the EnvelopedData RecipientInfo KeyAgreeRecipientInfo located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo
recipientEncryptedKeys encryptedKey and AuthenticatedData RecipientEncryptedKeys encryptedKey field, wrapped message-
RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys authentication keys are located in the AuthenticatedData
encryptedKey fields. RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
encryptedKey field.
12.3.3.1 Triple-DES Key Wrap 12.3.3.1 Triple-DES Key Wrap
Triple-DES key encryption has the algorithm identifier: Triple-DES key encryption has the algorithm identifier:
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
The AlgorithmIdentifier parameter field must be NULL. The AlgorithmIdentifier parameter field must be NULL.
skipping to change at page 40, line 45 skipping to change at page 41, line 25
RC2ParameterVersion ::= INTEGER RC2ParameterVersion ::= INTEGER
The RC2 effective-key-bits (key size) greater than 32 and less than The RC2 effective-key-bits (key size) greater than 32 and less than
256 is encoded in the RC2ParameterVersion. For the effective-key- 256 is encoded in the RC2ParameterVersion. For the effective-key-
bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
and 58 respectively. These values are not simply the RC2 key length. 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), Note that the value 160 must be encoded as two octets (00 A0),
because the one octet (A0) encoding represents a negative number. 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 The key wrap algorithm used to encrypt a RC2 content-encryption key
with a RC2 key-encryption key is specified in section 12.6. with a RC2 key-encryption key is specified in section 12.6.
Out-of-band distribution of the RC2 key-encryption key used to 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 encrypt the RC2 content-encryption key is beyond of the scope of this
document. document.
12.4 Content Encryption Algorithms 12.4 Content Encryption Algorithms
CMS implementations must include Triple-DES in CBC mode. CMS CMS implementations must include Triple-DES in CBC mode. CMS
skipping to change at page 41, line 22 skipping to change at page 42, line 8
EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields.
Content encryption algorithms are used to encipher the content Content encryption algorithms are used to encipher the content
located in the EnvelopedData EncryptedContentInfo encryptedContent located in the EnvelopedData EncryptedContentInfo encryptedContent
field and the EncryptedData EncryptedContentInfo encryptedContent field and the EncryptedData EncryptedContentInfo encryptedContent
field. field.
12.4.1 Triple-DES CBC 12.4.1 Triple-DES CBC
The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The
algorithm identifier for Triple-DES is: 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) des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
The AlgorithmIdentifier parameters field must be present, and the The AlgorithmIdentifier parameters field must be present, and the
parameters field must contain a CBCParameter: parameters field must contain a CBCParameter:
CBCParameter ::= IV CBCParameter ::= IV
IV ::= OCTET STRING -- exactly 8 octets IV ::= OCTET STRING -- exactly 8 octets
skipping to change at page 42, line 23 skipping to change at page 43, line 15
MAC algorithm identifiers are located in the AuthenticatedData MAC algorithm identifiers are located in the AuthenticatedData
macAlgorithm field. macAlgorithm field.
MAC values are located in the AuthenticatedData mac field. MAC values are located in the AuthenticatedData mac field.
12.5.1 HMAC with SHA-1 12.5.1 HMAC with SHA-1
The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The
algorithm identifier for HMAC with SHA-1 is: algorithm identifier for HMAC with SHA-1 is:
HMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
The AlgorithmIdentifier parameters field must be absent. The AlgorithmIdentifier parameters field must be absent.
12.6 Triple-DES and RC2 Key Wrap Algorithms 12.6 Triple-DES and RC2 Key Wrap Algorithms
CMS implementations must include encryption of a Triple-DES content- CMS implementations must include encryption of a Triple-DES content-
encryption key with a Triple-DES key-encryption key using the encryption key with a Triple-DES key-encryption key using the
algorithm specified in Sections 12.6.2 and 12.6.3. CMS algorithm specified in Sections 12.6.2 and 12.6.3. CMS
implementations should include encryption of a RC2 content-encryption implementations should include encryption of a RC2 content-encryption
skipping to change at page 46, line 7 skipping to change at page 47, line 7
above in Section 12.6.1. If the computed key checksum value above in Section 12.6.1. If the computed key checksum value
does not match the decrypted key checksum value, ICV, then error. does not match the decrypted key checksum value, ICV, then error.
8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the 8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the
most significant (first) octet. CEK is the following LENGTH most significant (first) octet. CEK is the following LENGTH
octets. PAD is the remaining octets, if any. octets. PAD is the remaining octets, if any.
9. If the length of PAD is more than 7 octets, then error. 9. If the length of PAD is more than 7 octets, then error.
10. Use CEK as the content-encryption key. 10. Use CEK as the content-encryption key.
Appendix A: ASN.1 Module Appendix A: ASN.1 Module
CryptographicMessageSyntax CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 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) DEFINITIONS IMPLICIT TAGS ::=
AlgorithmIdentifier, AttributeCertificate, Certificate, BEGIN
CertificateList, CertificateSerialNumber
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 } ;
-- Cryptographic Message Syntax -- 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.
ContentInfo ::= SEQUENCE { IMPORTS
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER -- Directory Information Framework (X.501)
Name
FROM InformationFramework { joint-iso-itu-t ds(5) modules(1)
informationFramework(1) 3 }
SignedData ::= SEQUENCE { -- Directory Authentication Framework (X.509)
version CMSVersion, AlgorithmIdentifier, AttributeCertificate, Certificate,
digestAlgorithms DigestAlgorithmIdentifiers, CertificateList, CertificateSerialNumber
encapContentInfo EncapsulatedContentInfo, FROM AuthenticationFramework { joint-iso-itu-t ds(5)
certificates [0] IMPLICIT CertificateSet OPTIONAL, module(1) authenticationFramework(7) 3 } ;
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier -- Cryptographic Message Syntax
SignerInfos ::= SET OF SignerInfo ContentInfo ::= SEQUENCE {
EncapsulatedContentInfo ::= SEQUENCE { contentType ContentType,
eContentType ContentType, content [0] EXPLICIT ANY DEFINED BY contentType }
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
SignerInfo ::= SEQUENCE { ContentType ::= OBJECT IDENTIFIER
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerIdentifier ::= CHOICE { SignedData ::= SEQUENCE {
issuerAndSerialNumber IssuerAndSerialNumber, version CMSVersion,
subjectKeyIdentifier [0] SubjectKeyIdentifier } digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute SignerInfos ::= SET OF SignerInfo
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
Attribute ::= SEQUENCE { SignerInfo ::= SEQUENCE {
attrType OBJECT IDENTIFIER, version CMSVersion,
attrValues SET OF AttributeValue } sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
AttributeValue ::= ANY SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignatureValue ::= OCTET STRING SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
EnvelopedData ::= SEQUENCE { UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
OriginatorInfo ::= SEQUENCE { Attribute ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL, attrType OBJECT IDENTIFIER,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } attrValues SET OF AttributeValue }
RecipientInfos ::= SET OF RecipientInfo AttributeValue ::= ANY
EncryptedContentInfo ::= SEQUENCE { SignatureValue ::= OCTET STRING
contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING EnvelopedData ::= SEQUENCE {
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
RecipientInfo ::= CHOICE { OriginatorInfo ::= SEQUENCE {
ktri KeyTransRecipientInfo, certs [0] IMPLICIT CertificateSet OPTIONAL,
kari [1] KeyAgreeRecipientInfo, crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }
kekri [2] KEKRecipientInfo }
EncryptedKey ::= OCTET STRING RecipientInfos ::= SET OF RecipientInfo
KeyTransRecipientInfo ::= SEQUENCE { EncryptedContentInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2 contentType ContentType,
rid RecipientIdentifier, contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE { EncryptedContent ::= OCTET STRING
issuerAndSerialNumber IssuerAndSerialNumber, UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
subjectKeyIdentifier [0] SubjectKeyIdentifier }
KeyAgreeRecipientInfo ::= SEQUENCE { RecipientInfo ::= CHOICE {
version CMSVersion, -- always set to 3 ktri KeyTransRecipientInfo,
originator [0] EXPLICIT OriginatorIdentifierOrKey, kari [1] KeyAgreeRecipientInfo,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, kekri [2] KEKRecipientInfo }
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys }
OriginatorIdentifierOrKey ::= CHOICE { EncryptedKey ::= OCTET STRING
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
OriginatorPublicKey ::= SEQUENCE { KeyTransRecipientInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier, version CMSVersion, -- always set to 0 or 2
publicKey BIT STRING } rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
RecipientEncryptedKey ::= SEQUENCE { KeyAgreeRecipientInfo ::= SEQUENCE {
rid KeyAgreeRecipientIdentifier, version CMSVersion, -- always set to 3
encryptedKey EncryptedKey } originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys }
KeyAgreeRecipientIdentifier ::= CHOICE { OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
rKeyId [0] IMPLICIT RecipientKeyIdentifier } subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
RecipientKeyIdentifier ::= SEQUENCE { OriginatorPublicKey ::= SEQUENCE {
subjectKeyIdentifier SubjectKeyIdentifier, algorithm AlgorithmIdentifier,
date GeneralizedTime OPTIONAL, publicKey BIT STRING }
other OtherKeyAttribute OPTIONAL }
SubjectKeyIdentifier ::= OCTET STRING RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
KEKRecipientInfo ::= SEQUENCE { RecipientEncryptedKey ::= SEQUENCE {
version CMSVersion, -- always set to 4 rid KeyAgreeRecipientIdentifier,
kekid KEKIdentifier, encryptedKey EncryptedKey }
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KEKIdentifier ::= SEQUENCE { KeyAgreeRecipientIdentifier ::= CHOICE {
keyIdentifier OCTET STRING, issuerAndSerialNumber IssuerAndSerialNumber,
date GeneralizedTime OPTIONAL, rKeyId [0] IMPLICIT RecipientKeyIdentifier }
other OtherKeyAttribute OPTIONAL }
DigestedData ::= SEQUENCE { RecipientKeyIdentifier ::= SEQUENCE {
version CMSVersion, subjectKeyIdentifier SubjectKeyIdentifier,
digestAlgorithm DigestAlgorithmIdentifier, date GeneralizedTime OPTIONAL,
encapContentInfo EncapsulatedContentInfo, other OtherKeyAttribute OPTIONAL }
digest Digest }
Digest ::= OCTET STRING SubjectKeyIdentifier ::= OCTET STRING
EncryptedData ::= SEQUENCE { KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, version CMSVersion, -- always set to 4
encryptedContentInfo EncryptedContentInfo } kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
AuthenticatedData ::= SEQUENCE { KEKIdentifier ::= SEQUENCE {
version CMSVersion, keyIdentifier OCTET STRING,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, date GeneralizedTime OPTIONAL,
recipientInfos RecipientInfos, other OtherKeyAttribute OPTIONAL }
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 DigestedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithm DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo,
digest Digest }
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute Digest ::= OCTET STRING
MessageAuthenticationCode ::= OCTET STRING EncryptedData ::= SEQUENCE {
version CMSVersion,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
DigestAlgorithmIdentifier ::= AlgorithmIdentifier AuthenticatedData ::= SEQUENCE {
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 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 }
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier MessageAuthenticationCode ::= OCTET STRING
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
CertificateRevocationLists ::= SET OF CertificateList SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
CertificateChoices ::= CHOICE { KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57
CertificateSet ::= SET OF CertificateChoices ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
IssuerAndSerialNumber ::= SEQUENCE { MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
issuer Name,
serialNumber CertificateSerialNumber }
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } CertificateRevocationLists ::= SET OF CertificateList
UserKeyingMaterial ::= OCTET STRING CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57
UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial CertificateSet ::= SET OF CertificateChoices
OtherKeyAttribute ::= SEQUENCE { IssuerAndSerialNumber ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER, issuer Name,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL } serialNumber CertificateSerialNumber }
-- CMS Attributes CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) }
MessageDigest ::= OCTET STRING UserKeyingMaterial ::= OCTET STRING
SigningTime ::= Time OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
Time ::= CHOICE { -- CMS Attributes
utcTime UTCTime,
generalTime GeneralizedTime }
Countersignature ::= SignerInfo MessageDigest ::= OCTET STRING
-- Algorithm Identifiers
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) SigningTime ::= Time
oiw(14) secsig(3) algorithm(2) 26 }
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) Time ::= CHOICE {
rsadsi(113549) digestAlgorithm(2) 5 } utcTime UTCTime,
generalTime GeneralizedTime }
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) Countersignature ::= SignerInfo
us(840) x9-57 (10040) x9cm(4) 3 } -- Algorithm Identifiers
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } oiw(14) secsig(3) algorithm(2) 26 }
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
oiw(14) secsig(3) algorithm(2) 26 } rsadsi(113549) digestAlgorithm(2) 5 }
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 } us(840) x9-57 (10040) x9cm(4) 3 }
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } us(840) ansi-x942(10046) number-type(2) 1 }
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
rsadsi(113549) encryptionAlgorithm(3) 2 } us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
HMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } rsadsi(113549) encryptionAlgorithm(3) 2 }
-- Algorithm Parameters hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
KeyWrapAlgorithm ::= AlgorithmIdentifier -- Algorithm Parameters
RC2wrapParameter ::= RC2ParameterVersion KeyWrapAlgorithm ::= AlgorithmIdentifier
RC2ParameterVersion ::= INTEGER
CBCParameter ::= IV RC2wrapParameter ::= RC2ParameterVersion
IV ::= OCTET STRING -- exactly 8 octets RC2ParameterVersion ::= INTEGER
RC2CBCParameter ::= SEQUENCE { CBCParameter ::= IV
rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets
-- Content Type Object Identifiers IV ::= OCTET STRING -- exactly 8 octets
RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) -- Content Type Object Identifiers
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 6 }
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
ct(1) 2 }
-- Attribute Object Identifiers id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
ct(1) 2 }
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) -- Attribute Object Identifiers
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
-- Obsolete Extended Certificate syntax from PKCS#6 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
ExtendedCertificateOrCertificate ::= CHOICE { id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
certificate Certificate, us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }
extendedCertificate [0] IMPLICIT ExtendedCertificate }
ExtendedCertificate ::= SEQUENCE { -- Obsolete Extended Certificate syntax from PKCS#6
extendedCertificateInfo ExtendedCertificateInfo,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature }
ExtendedCertificateInfo ::= SEQUENCE { ExtendedCertificate ::= SEQUENCE {
version CMSVersion, extendedCertificateInfo ExtendedCertificateInfo,
certificate Certificate, signatureAlgorithm SignatureAlgorithmIdentifier,
attributes UnauthAttributes } signature Signature }
Signature ::= BIT STRING ExtendedCertificateInfo ::= SEQUENCE {
version CMSVersion,
certificate Certificate,
attributes UnauthAttributes }
END -- of CryptographicMessageSyntax Signature ::= BIT STRING
END -- of CryptographicMessageSyntax
References References
3DES American National Standards Institute. ANSI X9.52-1998, 3DES American National Standards Institute. ANSI X9.52-1998,
Triple Data Encryption Algorithm Modes of Operation. 1998. Triple Data Encryption Algorithm Modes of Operation. 1998.
DES American National Standards Institute. ANSI X3.106, DES American National Standards Institute. ANSI X3.106,
"American National Standard for Information Systems - Data "American National Standard for Information Systems - Data
Link Encryption". 1983. Link Encryption". 1983.
DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. DH-X9.42 Rescorla, E., "Diffie-Hellman Key Agreement Method",
(currently draft-ietf-smime-x942-*.txt) RFC 2631, June 1999.
DSS National Institute of Standards and Technology. DSS National Institute of Standards and Technology.
FIPS Pub 186: Digital Signature Standard. 19 May 1994. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
ESS Hoffman, P. Enhanced Security Services for S/MIME. ESS Hoffman, P., Editor, "Enhanced Security Services for
(currently draft-ietf-smime-ess-*.txt) S/MIME", RFC 2634, June 1999.
HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. HMAC Krawczyk, H., "HMAC: Keyed-Hashing for Message
RFC 2104. February 1997. Authentication", RFC 2104, February 1997.
MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321. MD5 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
MODES National Institute of Standards and Technology. MODES National Institute of Standards and Technology.
FIPS Pub 81: DES Modes of Operation. 2 December 1980. FIPS Pub 81: DES Modes of Operation. 2 December 1980.
MSG Ramsdell, B. S/MIME Version 3 Message Specification. MSG Ramsdell, B., Editor, "S/MIME Version 3 Message
(currently draft-ietf-smime-msg-*.txt) Specification", RFC 2633, June 1999.
NEWPKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. NEWPKCS#1 Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0",
RFC 2347. October 1998. RFC 2347, October 1998.
PROFILE Housley, R., W. Ford, W. Polk, D. Solo. Internet PROFILE Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and CRL X.509 Public Key Infrastructure: Certificate and CRL
Profile. RFC 2459. January 1999. Profile", RFC 2459, January 1999.
PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. PKCS#1 Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5.",
RFC 2313. March 1998. RFC 2313, March 1998.
PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax
Standard, Version 1.5. November 1993. Standard, Version 1.5. November 1993.
PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, PKCS#7 Kaliski, B., "PKCS #7: Cryptographic Message Syntax,
Version 1.5. RFC 2315. March 1998. Version 1.5.", RFC 2315, March 1998.
PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types,
Version 1.1. November 1993. Version 1.1. November 1993.
RANDOM Eastlake, D.; S. Crocker; J. Schiller. Randomness RANDOM Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security. RFC 1750. December 1994. Recommendations for Security", RFC 1750, December 1994.
RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. RC2 Rivest, R., "A Description of the RC2 (r) Encryption
RFC 2268. March 1998. Algorithm", RFC 2268, March 1998.
SHA1 National Institute of Standards and Technology. SHA1 National Institute of Standards and Technology.
FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995.
X.208 CCITT. Recommendation X.208: Specification of Abstract X.208-88 CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
X.209 CCITT. Recommendation X.209: Specification of Basic Encoding X.209-88 CCITT. Recommendation X.209: Specification of Basic
Rules for Abstract Syntax Notation One (ASN.1). 1988. Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988.
X.501 CCITT. Recommendation X.501: The Directory - Models. 1988. X.501-88 CCITT. Recommendation X.501: The Directory - Models.
1988.
X.509 CCITT. Recommendation X.509: The Directory - Authentication X.509-88 CCITT. Recommendation X.509: The Directory -
Framework. 1988. Authentication Framework. 1988.
X.509-97 ITU-T. Recommendation X.509: The Directory -
Authentication Framework. 1997.
Security Considerations Security Considerations
The Cryptographic Message Syntax provides a method for digitally The Cryptographic Message Syntax provides a method for digitally
signing data, digesting data, encrypting data, and authenticating signing data, digesting data, encrypting data, and authenticating
data. data.
Implementations must protect the signer's private key. Compromise of Implementations must protect the signer's private key. Compromise of
the signer's private key permits masquerade. the signer's private key permits masquerade.
Implementations must protect the key management private key, the key- Implementations must protect the key management private key, the
encryption key, and the content-encryption key. Compromise of the key-encryption key, and the content-encryption key. Compromise of
key management private key or the key-encryption key may result in the key management private key or the key-encryption key may result
the disclosure of all messages protected with that key. Similarly, in the disclosure of all messages protected with that key.
compromise of the content-encryption key may result in disclosure of Similarly, compromise of the content-encryption key may result in
the associated encrypted content. disclosure of the associated encrypted content.
Implementations must protect the key management private key and the Implementations must protect the key management private key and the
message-authentication key. Compromise of the key management private message-authentication key. Compromise of the key management private
key permits masquerade of authenticated data. Similarly, compromise key permits masquerade of authenticated data. Similarly, compromise
of the message-authentication key may result in undetectable of the message-authentication key may result in undetectable
modification of the authenticated content. modification of the authenticated content.
Implementations must randomly generate content-encryption keys, Implementations must randomly generate content-encryption keys,
message-authentication keys, initialization vectors (IVs), salt message-authentication keys, initialization vectors (IVs), and
values, and padding. Also, the generation of public/private key padding. Also, the generation of public/private key pairs relies on
pairs relies on a random numbers. The use of inadequate pseudo- a random numbers. The use of inadequate pseudo-random number
random number generators (PRNGs) to generate cryptographic keys can generators (PRNGs) to generate cryptographic keys can result in
result in little or no security. An attacker may find it much easier little or no security. An attacker may find it much easier to
to reproduce the PRNG environment that produced the keys, searching reproduce the PRNG environment that produced the keys, searching the
the resulting small set of possibilities, rather than brute force resulting small set of possibilities, rather than brute force
searching the whole key space. The generation of quality random searching the whole key space. The generation of quality random
numbers is difficult. RFC 1750 [RANDOM] offers important guidance in numbers is difficult. RFC 1750 [RANDOM] offers important guidance in
this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality
PRNG technique. PRNG technique.
When using key agreement algorithms or previously distributed When using key agreement algorithms or previously distributed
symmetric key-encryption keys, a key-encryption key is used to symmetric key-encryption keys, a key-encryption key is used to
encrypt the content-encryption key. If the key-encryption and encrypt the content-encryption key. If the key-encryption and
content-encryption algorithms are different, the effective security content-encryption algorithms are different, the effective security
is determined by the weaker of the two algorithms. If, for example, is determined by the weaker of the two algorithms. If, for example,
skipping to change at page 57, line 44 skipping to change at page 58, line 51
decryption operations is not provided. Support for OAEP will likely decryption operations is not provided. Support for OAEP will likely
be added to a future version of the CMS specification. be added to a future version of the CMS specification.
Acknowledgments Acknowledgments
This document is the result of contributions from many professionals. This document is the result of contributions from many professionals.
I appreciate the hard work of all members of the IETF S/MIME Working 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 Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve
Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson,
Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn,
John Pawling, Blake Ramsdell, Jim Schaad, and Dave Solo for their John Pawling, Blake Ramsdell, Francois Rousseau, Jim Schaad, and Dave
efforts and support. Solo for their efforts and support.
Author Address Author's Address
Russell Housley Russell Housley
SPYRUS SPYRUS
381 Elden Street 381 Elden Street
Suite 1120 Suite 1120
Herndon, VA 20170 Herndon, VA 20170
USA USA
housley@spyrus.com EMail: housley@spyrus.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. In addition, the included on all such copies and derivative works. However, this
ASN.1 module presented in Appendix A may be used in whole or in part document itself may not be modified in any way, such as by removing
without inclusion of the copyright notice. However, this document the copyright notice or references to the Internet Society or other
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 Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process shall be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This revoked by the Internet Society or its successors or assigns.
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK This document and the information contained herein is provided on an
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
OR FITNESS FOR A PARTICULAR PURPOSE. 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.
 End of changes. 160 change blocks. 
484 lines changed or deleted 482 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/