draft-ietf-smime-cms-09.txt   draft-ietf-smime-cms-10.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet Draft SPYRUS Internet Draft SPYRUS
expires in six months November 1998 expires in six months December 1998
Cryptographic Message Syntax Cryptographic Message Syntax
<draft-ietf-smime-cms-09.txt> <draft-ietf-smime-cms-10.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 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). 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
[RFC 2315]. Wherever possible, backward compatibility is preserved; as specified in RFC 2315 [PKCS#7]. Wherever possible, backward
however, changes were necessary to accommodate attribute certificate compatibility is preserved; however, changes were necessary to
transfer and key agreement techniques for key management. accommodate attribute certificate transfer and key agreement
techniques for key management.
This draft is being discussed on the "ietf-smime" mailing list. To 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 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 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- is a Web site for the mailing list at <http://www.imc.org/ietf-
smime/>. smime/>.
Table of Contents
Status of this Memo .................................................. 1
Abstract ............................................................. 1
Table of Contents .................................................... 2
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 Validation Process ........................ 12
6 Enveloped-data Content Type ...................................... 12
6.1 EnvelopedData Type .......................................... 13
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 ....................................... 20
8 Encrypted-data Content Type ...................................... 22
9 Authenticated-data Content Type .................................. 22
9.1 AuthenticatedData Type ...................................... 23
9.2 MAC Generation .............................................. 25
9.3 MAC Validation .............................................. 26
10 Useful Types ..................................................... 26
10.1 Algorithm Identifier Types ................................. 27
10.1.1 DigestAlgorithmIdentifier .......................... 27
10.1.2 SignatureAlgorithmIdentifier ....................... 27
10.1.3 KeyEncryptionAlgorithmIdentifier ................... 27
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 .............................. 29
10.2.5 CMSVersion ......................................... 30
10.2.6 UserKeyingMaterial ................................. 30
10.2.7 OtherKeyAttribute .................................. 30
11 Useful Attributes ................................................ 30
11.1 Content Type ............................................... 30
11.2 Message Digest ............................................. 31
11.3 Signing Time ............................................... 32
11.4 Countersignature ........................................... 33
12 Supported Algorithms ............................................. 34
12.1 Digest Algorithms .......................................... 34
12.1.1 SHA-1 .............................................. 35
12.1.2 MD5 ................................................ 35
12.2 Signature Algorithms ....................................... 35
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 ...................................... 38
12.3.3 Symmetric Key-Encryption Key Algorithms ............ 39
12.3.3.1 Triple-DES Key Wrap ...................... 39
12.3.3.2 RC2 Key Wrap ............................. 40
12.4 Content Encryption Algorithms ............................... 40
12.4.1 Triple-DES CBC ...................................... 41
12.4.2 RC2 CBC ............................................. 41
12.5 Message Authentication Code Algorithms ...................... 41
12.5.1 HMAC with SHA-1 ..................................... 42
12.6 Triple-DES and RC2 Key Wrap Algorithm ....................... 42
12.6.1 Key Checksum ........................................ 43
12.6.2 Key Wrap ............................................ 43
12.6.3 Key Unwrap .......................................... 43
Appendix A: ASN.1 Module ............................................ 44
References ........................................................... 50
Security Considerations .............................................. 51
Acknowledgments ...................................................... 53
Author Address ....................................................... 54
Full Copyright Statement ............................................. 54
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 or encrypt arbitrary messages. syntax is used to digitally sign or encrypt 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 and encryption.
The syntax allows multiple encapsulation, so one encapsulation The syntax allows multiple encapsulation, so one encapsulation
envelope can be nested inside another. Likewise, one party can envelope can be nested inside another. Likewise, one party can
digitally sign some previously encapsulated data. It also allows digitally sign some previously encapsulated data. It also allows
skipping to change at page 2, line 35 skipping to change at page 4, line 35
strings. While many systems are capable of transmitting arbitrary strings. While many systems are capable of transmitting arbitrary
octet strings reliably, it is well known that many electronic-mail octet strings reliably, it is well known that many electronic-mail
systems are not. This document does not address mechanisms for systems are not. This document does not address mechanisms for
encoding octet strings for reliable transmission in such encoding octet strings for reliable transmission in such
environments. 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 one or more content content, ContentInfo. ContentInfo encapsulates a single identified
types. This document defines six content types: data, signed-data, content type, and the identified type may provide further
enveloped-data, digested-data, encrypted-data, and authenticated- encapsulation. This document defines six content types: data,
data. Additional content types can be defined outside this document. 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 An implementation that conforms to this specification must implement
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 permit 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) encoding in a single pass since the lengths of the various
components may not be known in advance. However, signed attributes components may not be known in advance. However, signed attributes
within the signed-data content type and authenticated attributes within the signed-data content type and authenticated attributes
within the authenticated-data content type require DER encoding. within the authenticated-data content type require DER encoding.
Signed attributes and authenticated attributes must be transmitted in Signed attributes and authenticated attributes must be transmitted in
skipping to change at page 3, line 29 skipping to change at page 5, line 31
ContentType ::= OBJECT IDENTIFIER ContentType ::= OBJECT IDENTIFIER
The fields of ContentInfo have the following meanings: The fields of ContentInfo have the following meanings:
contentType indicates the type of the associated content. It is contentType indicates the type of the associated content. It is
an object identifier; it is a unique string of integers assigned an object identifier; it is a unique string of integers assigned
by an authority that defines the content type. by an authority that defines the content type.
content is the associated content. The type of content can be content is the associated content. The type of content can be
determined uniquely by contentType. Content types for signed- determined uniquely by contentType. Content types for data,
data, enveloped-data, digested-data, encrypted-data, and signed-data, enveloped-data, digested-data, encrypted-data, and
authenticated-data are defined in this document. If additional authenticated-data are defined in this document. If additional
content types are defined in other documents, the ASN.1 type content types are defined in other documents, the ASN.1 type
defined should not be a CHOICE type. defined should not be a CHOICE type.
4 Data Content Type 4 Data Content Type
The following object identifier identifies the data content type: The following object identifier identifies the data content type:
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
The data content type is intended to refer to arbitrary octet The data content type is intended to refer to arbitrary octet
strings, such as ASCII text files; the interpretation is left to the strings, such as ASCII text files; the interpretation is left to the
application. Such strings need not have any internal structure application. Such strings need not have any internal structure
(although they could have their own ASN.1 definition or other (although they could have their own ASN.1 definition or other
structure). structure).
The data content type is generally encapsulated in the signed-data, The data content type is generally encapsulated in the signed-data,
enveloped-data, digested-data, encrypted-data, or authenticated-data enveloped-data, digested-data, encrypted-data, or authenticated-data
content type. Object identifiers other than id-data may be used to content type.
identify the specific type of encapsulated content, but such usage is
outside the scope of this specification.
5 Signed-data Content Type 5 Signed-data Content Type
The signed-data content type consists of a content of any type and 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 zero or more signature values. Any number of signers in parallel can
sign any type of content. sign any type of content.
The typical application of the signed-data content type represents The typical application of the signed-data content type represents
one signer's digital signature on content of the data content type. one signer's digital signature on content of the data content type.
Another typical application disseminates certificates and certificate Another typical application disseminates certificates and certificate
skipping to change at page 7, line 17 skipping to change at page 9, line 19
eContent is the content itself, carried as an octet string. The eContent is the content itself, carried as an octet string. The
eContent need not be DER encoded. eContent need not be DER encoded.
5.3 SignerInfo Type 5.3 SignerInfo Type
Per-signer information is represented in the type SignerInfo: Per-signer information is represented in the type SignerInfo:
SignerInfo ::= SEQUENCE { SignerInfo ::= SEQUENCE {
version CMSVersion, version CMSVersion,
issuerAndSerialNumber IssuerAndSerialNumber, sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier, signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue, signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE { Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER, attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue } attrValues SET OF AttributeValue }
AttributeValue ::= ANY AttributeValue ::= ANY
SignatureValue ::= OCTET STRING SignatureValue ::= OCTET STRING
The fields of type SignerInfo have the following meanings: The fields of type SignerInfo have the following meanings:
version is the syntax version number; it shall be 1. version is the syntax version number. If the SignerIdentifier is
the CHOICE issuerAndSerialNumber, then the version shall be 1. If
the SignerIdentifier is subjectKeyIdentifier, then the version
shall be 3.
issuerAndSerialNumber specifies the signer's certificate (and sid specifies the signer's certificate (and thereby the signer's
thereby the signer's public key) by issuer distinguished name and public key). The signer's public key is needed by the recipient
issuer-specific serial number. to validate 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 digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the signer. The message digest is associated parameters, used by the signer. The message digest is
computed over the encapsulated content and signed attributes, if computed on either the content being signed or the content
present. The message digest algorithm should be among those 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. listed in the digestAlgorithms field of the associated SignerData.
The message digesting process is described in Section 5.4.
signedAttributes is a collection of attributes that are signed. signedAttributes is a collection of attributes that are signed.
The field is optional, but it must be present if the content type The field is optional, but it must be present if the content type
of the EncapsulatedContentInfo value being signed is not id-data. of the EncapsulatedContentInfo value being signed is not id-data.
Each SignedAttribute in the SET must be DER encoded. Useful Each SignedAttribute in the SET must be DER encoded. Useful
attribute types, such as signing time, are defined in Section 11. attribute types, such as signing time, are defined in Section 11.
If the field is present, it must contain, at a minimum, the If the field is present, it must contain, at a minimum, the
following two attributes: following two attributes:
A content-type attribute having as its value the content type A content-type attribute having as its value the content type
skipping to change at page 11, line 29 skipping to change at page 14, line 4
recipient information type RecipientInfo, and the third and fourth recipient information type RecipientInfo, and the third and fourth
parts describe the content-encryption and key-encryption processes. parts describe the content-encryption and key-encryption processes.
6.1 EnvelopedData Type 6.1 EnvelopedData Type
The following object identifier identifies the enveloped-data content The following object identifier identifies the enveloped-data content
type: type:
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
The enveloped-data content type shall have ASN.1 type EnvelopedData: The enveloped-data content type shall have ASN.1 type EnvelopedData:
EnvelopedData ::= SEQUENCE { EnvelopedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo, encryptedContentInfo EncryptedContentInfo,
plaintextAttrs [1] IMPLICIT PlaintextAttributes OPTIONAL } unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
OriginatorInfo ::= SEQUENCE { OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL, certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }
RecipientInfos ::= SET OF RecipientInfo RecipientInfos ::= SET OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE { EncryptedContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING EncryptedContent ::= OCTET STRING
PlaintextAttributes ::= SET SIZE (1..MAX) OF Attribute UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
The fields of type EnvelopedData have the following meanings: The fields of type EnvelopedData have the following meanings:
version is the syntax version number. If originatorInfo is version is the syntax version number. If originatorInfo is
present, then version shall be 2. If any of the RecipientInfo present, then version shall be 2. If any of the RecipientInfo
structures included have a version other than 0, then the version structures included have a version other than 0, then the version
shall be 2. If plaintextAttrs is present, then version shall be shall be 2. If unprotectedAttrs is present, then version shall be
2. If originatorInfo is absent, all of the RecipientInfo 2. If originatorInfo is absent, all of the RecipientInfo
structures are version 0, and plaintextAttrs is absent, then structures are version 0, and unprotectedAttrs is absent, then
version shall be 0. version shall be 0.
originatorInfo optionally provides information about the originatorInfo optionally provides information about the
originator. It is present only if required by the key management originator. It is present only if required by the key management
algorithm. It may contain certificates and CRLs: algorithm. It may contain certificates and CRLs:
certs is a collection of certificates. certs may contain certs is a collection of certificates. certs may contain
originator certificates associated with several different key originator certificates associated with several different key
management algorithms. certs may also contain attribute management algorithms. certs may also contain attribute
certificates associated with the originator. The certificates certificates associated with the originator. The certificates
skipping to change at page 12, line 43 skipping to change at page 15, line 19
contain information sufficient to determine whether or not the contain information sufficient to determine whether or not the
certificates in the certs field are valid, but such certificates in the certs field are valid, but such
correspondence is not necessary. There may be more CRLs than correspondence is not necessary. There may be more CRLs than
necessary, and there may also be fewer CRLs than necessary. necessary, and there may also be fewer CRLs than necessary.
recipientInfos is a collection of per-recipient information. recipientInfos is a collection of per-recipient information.
There must be at least one element in the collection. There must be at least one element in the collection.
encryptedContentInfo is the encrypted content information. encryptedContentInfo is the encrypted content information.
plaintextAttrs is a collection of attributes that are not unprotectedAttrs is a collection of attributes that are not
encrypted. The field is optional. Useful attribute types are encrypted. The field is optional. Useful attribute types are
defined in Section 11. defined in Section 11.
The fields of type EncryptedContentInfo have the following meanings: The fields of type EncryptedContentInfo have the following meanings:
contentType indicates the type of content. contentType indicates the type of content.
contentEncryptionAlgorithm identifies the content-encryption contentEncryptionAlgorithm identifies the content-encryption
algorithm, and any associated parameters, used to encrypt the algorithm, and any associated parameters, used to encrypt the
content. The content-encryption process is described in Section content. The content-encryption process is described in Section
skipping to change at page 20, line 8 skipping to change at page 22, line 31
type: type:
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
The encrypted-data content type shall have ASN.1 type EncryptedData: The encrypted-data content type shall have ASN.1 type EncryptedData:
EncryptedData ::= SEQUENCE { EncryptedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
encryptedContentInfo EncryptedContentInfo, encryptedContentInfo EncryptedContentInfo,
plaintextAttrs [1] IMPLICIT PlaintextAttributes OPTIONAL } unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
The fields of type EncryptedData have the following meanings: The fields of type EncryptedData have the following meanings:
version is the syntax version number. If plaintextAttrs is version is the syntax version number. If unprotectedAttrs is
present, then version shall be 2. If plaintextAttrs is absent, present, then version shall be 2. If unprotectedAttrs is absent,
then version shall be 0. then version shall be 0.
encryptedContentInfo is the encrypted content information, as encryptedContentInfo is the encrypted content information, as
defined in Section 6.1. defined in Section 6.1.
plaintextAttrs is a collection of attributes that are not unprotectedAttrs is a collection of attributes that are not
encrypted. The field is optional. Useful attribute types are encrypted. The field is optional. Useful attribute types are
defined in Section 11. defined in Section 11.
9 Authenticated-data Content Type 9 Authenticated-data Content Type
The authenticated-data content type consists of content of any type, The authenticated-data content type consists of content of any type,
a message authentication code (MAC), and encrypted authentication a message authentication code (MAC), and encrypted authentication
keys for one or more recipients. The combination of the MAC and one keys for one or more recipients. The combination of the MAC and one
encrypted authentication key for a recipient is necessary for that encrypted authentication key for a recipient is necessary for that
recipient to validate the integrity of the content. Any type of recipient to validate the integrity of the content. Any type of
skipping to change at page 21, line 23 skipping to change at page 23, line 46
ct(1) 2 } ct(1) 2 }
The authenticated-data content type shall have ASN.1 type The authenticated-data content type shall have ASN.1 type
AuthenticatedData: AuthenticatedData:
AuthenticatedData ::= SEQUENCE { AuthenticatedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm, macAlgorithm MessageAuthenticationCodeAlgorithm,
authAttributesInfo [1] IMPLICIT AuthAttributesInfo OPTIONAL, digestAlgorithm [1] DigestAlgorithm OPTIONAL,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
authenctiatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode, mac MessageAuthenticationCode,
unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL }
AuthAttributesInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
authenticatedAttributes AuthAttributes }
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
MessageAuthenticationCode ::= OCTET STRING MessageAuthenticationCode ::= OCTET STRING
The fields of type AuthenticatedData have the following meanings: The fields of type AuthenticatedData have the following meanings:
version is the syntax version number. It shall be 0. version is the syntax version number. It shall be 0.
skipping to change at page 22, line 9 skipping to change at page 24, line 29
recipientInfos is a collection of per-recipient information, as recipientInfos is a collection of per-recipient information, as
defined in Section 6.1. There must be at least one element in the defined in Section 6.1. There must be at least one element in the
collection. collection.
macAlgorithm is a message authentication code (MAC) algorithm macAlgorithm is a message authentication code (MAC) algorithm
identifier. It identifies the MAC algorithm, along with any identifier. It identifies the MAC algorithm, along with any
associated parameters, used by the originator. Placement of the associated parameters, used by the originator. Placement of the
macAlgorithm field facilitates one-pass processing by the macAlgorithm field facilitates one-pass processing by the
recipient. recipient.
authAttributesInfo is a message digest algorithm identifier digestAlgorithm identifies the message digest algorithm, and any
followed by a collection of authenticated attributes. The associated parameters, used to compute a message digest on the
authAttributesInfo structure is optional, but it must be present encapsulated content if authenticated attributes are present. The
if the content type of the EncapsulatedContentInfo value being message digesting process is described in Section 9.2. Placement
authenticated is not id-data. Placement of the authAttributesInfo of the digestAlgorithm field facilitates one-pass processing by
digestAlgorithm field facilitates one-pass processing by the the recipient. If the digestAlgorithm field is present, then the
recipient. Each AuthenticatedAttribute in the SET must be DER authenctiatedAttributes field must also be present.
encoded. Useful attribute types are defined in Section 11. If
the authAttributesInfo structure is present, it must contain, at a encapContentInfo is the content that is authenticated, as defined
minimum, the following two attributes: in section 5.2.
authenctiatedAttributes is a collection of authenticated
attributes. The authenctiatedAttributes structure is optional,
but it must be present if the content type of the
EncapsulatedContentInfo value being authenticated is not id-data.
If the authenctiatedAttributes 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
authenctiatedAttributes field is present, it must contain,
at a minimum, the following two attributes:
A content-type attribute having as its value the content type A content-type attribute having as its value the content type
of the EncapsulatedContentInfo value being authenticated. of the EncapsulatedContentInfo value being authenticated.
Section 11.1 defines the content-type attribute. Section 11.1 defines the content-type attribute.
A message-digest attribute, having as its value the message A message-digest attribute, having as its value the message
digest of the content. Section 11.2 defines the message-digest digest of the content. Section 11.2 defines the message-digest
attribute. attribute.
encapContentInfo is the content that is authenticated, as defined
in section 5.2.
mac is the message authentication code. mac is the message authentication code.
unauthenticatedAttributes is a collection of attributes that are unauthenticatedAttributes is a collection of attributes that are
not authenticated. The field is optional. To date, no attributes not authenticated. The field is optional. To date, no attributes
have been defined for use as unauthenticated attributes, but other have been defined for use as unauthenticated attributes, but other
useful attribute types are defined in Section 11. useful attribute types are defined in Section 11.
9.2 MAC Generation 9.2 MAC Generation
The MAC calculation process computes a message authentication code The MAC calculation process computes a message authentication code
(MAC) on either the message being authenticated or a message digest (MAC) on either the message being authenticated or a message digest
of message being authenticated together with the originator's of message being authenticated together with the originator's
authenticated attributes. authenticated attributes.
If authAttributesInfo structure is absent, the input to the MAC If authenctiatedAttributes field is absent, the input to the MAC
calculation process is the value of the encapContentInfo eContent calculation process is the value of the encapContentInfo eContent
OCTET STRING. Only the octets comprising the value of the 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 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 octets are omitted. This has the advantage that the length of the
content being authenticated need not be known in advance of the MAC content being authenticated need not be known in advance of the MAC
generation process. generation process.
If authAttributesInfo structure is present, the content-type If authenctiatedAttributes field is present, the content-type
attribute (as described in Section 11.1) and the message-digest attribute (as described in Section 11.1) and the message-digest
attribute (as described in section 11.2) must be included, and the attribute (as described in section 11.2) must be included, and the
input to the MAC calculation process is the DER encoding of input to the MAC calculation process is the DER encoding of
authAttributesInfo authenticatedAttributes. Encoding of the authenticatedAttributes. A separate encoding of the
authAttributesInfo authenticatedAttributes field uses an EXPLICIT SET authenticatedAttributes field is performed for message digest
OF tag. The DER encoding of the SET OF tag is included in the MAC 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 calculation along with the length and content octets of the
authAttributesInfo authenticatedAttributes value. authenticatedAttributes value.
The message digest calculation process computes a message digest on The message digest calculation process computes a message digest on
the content being authenticated. The initial input to the message the content being authenticated. The initial input to the message
digest calculation process is the "value" of the encapsulated content digest calculation process is the "value" of the encapsulated content
being authenticated. Specifically, the input is the encapContentInfo being authenticated. Specifically, the input is the encapContentInfo
eContent OCTET STRING to which the authentication process is applied. eContent OCTET STRING to which the authentication process is applied.
Only the octets comprising the value of the encapContentInfo eContent Only the octets comprising the value of the encapContentInfo eContent
OCTET STRING are input to the message digest algorithm, not the tag 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 or the length octets. This has the advantage that the length of the
content being authenticated need not be known in advance. Although content being authenticated need not be known in advance. Although
skipping to change at page 23, line 44 skipping to change at page 26, line 30
algorithm employed (e.g., HMAC). The object identifier, along with algorithm employed (e.g., HMAC). The object identifier, along with
any parameters, that specifies the MAC algorithm employed by the any parameters, that specifies the MAC algorithm employed by the
originator is carried in the macAlgorithm field. The MAC value originator is carried in the macAlgorithm field. The MAC value
generated by the originator is encoded as an OCTET STRING and carried generated by the originator is encoded as an OCTET STRING and carried
in the mac field. in the mac field.
9.3 MAC Validation 9.3 MAC Validation
The input to the MAC validation process includes the input data The input to the MAC validation process includes the input data
(determined based on the presence or absence of the (determined based on the presence or absence of the
authAttributesInfo structure, as defined in 9.2), and the authenticatedAttributes field, as defined in 9.2), and the
authentication key conveyed in recipientInfo. The details of the MAC authentication key conveyed in recipientInfo. The details of the MAC
validation process depend on the MAC algorithm employed. validation process depend on the MAC algorithm employed.
The recipient may not rely on any MAC values or message digest values The recipient may not rely on any MAC values or message digest values
computed by the originator. The content is authenticated as computed by the originator. The content is authenticated as
described in section 9.2. If the originator includes authenticated described in section 9.2. If the originator includes authenticated
attributes, then the content of the authAttributesInfo attributes, then the content of the authenticatedAttributes is
authenticatedAttributes is authenticated as described in section 9.2. authenticated as described in section 9.2. For authentication to
succeed, the message MAC value calculated by the recipient must be
For authentication to succeed, the message MAC value calculated by the same as the value of the mac field. Similarly, for
the recipient must be the same as the value of the mac field. authentication to succeed when the authenticatedAttributes field is
Similarly, for authentication to succeed when the authAttributesInfo present, the content message digest value calculated by the recipient
structure is present, the content message digest value calculated by must be the same as the message digest value included in the
the recipient must be the same as the message digest value included authenticatedAttributes message-digest attribute.
in the authAttributesInfo authenticatedAttributes message-digest
attribute.
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:
skipping to change at page 26, line 13 skipping to change at page 28, line 47
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, and they are profiled for use in the
Internet in RFC TBD. Internet in RFC TBD [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. The PKCS #6 extended certificate is obsolete. PKCS #6
certificates are included for backward compatibility, and their use certificates are included for backward compatibility, and their use
should be avoided. The Internet profile of X.509 certificates is should be avoided. The Internet profile of X.509 certificates is
specified in RFC TBD. specified in the "Internet X.509 Public Key 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, -- Obsolete
attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57
10.2.3 CertificateSet 10.2.3 CertificateSet
skipping to change at page 28, line 9 skipping to change at page 30, line 43
11 Useful Attributes 11 Useful Attributes
This section defines attributes that may used with signed-data or This section defines attributes that may used with signed-data or
authenticated-data. Some of the attributes defined in this section authenticated-data. Some of the attributes defined in this section
were originally defined in PKCS #9 [PKCS #9], others were not were originally defined in PKCS #9 [PKCS #9], others were not
previously defined. The attributes are not listed in any particular previously defined. The attributes are not listed in any particular
order. 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 [RFC TBD2] and the Enhanced Security Version 3 Message Specification [MSG] and the Enhanced Security
Services for S/MIME [RFC TBD3], which also include recommendations on Services for S/MIME [ESS], which also include recommendations on the
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 or
skipping to change at page 28, line 51 skipping to change at page 31, line 36
the AuthAttributes in an AuthenticatedData must not include multiple the AuthAttributes in an AuthenticatedData must not include multiple
instances of the content-type attribute. instances of the content-type attribute.
11.2 Message Digest 11.2 Message Digest
The message-digest attribute type specifies the message digest of the The message-digest attribute type specifies the message digest of the
encapContentInfo eContent OCTET STRING being signed in signed-data encapContentInfo eContent OCTET STRING being signed in signed-data
(see section 5.4) or authenticated in authenticated-data (see section (see section 5.4) or authenticated in authenticated-data (see section
9.2). For signed-data, the message digest is computed using the 9.2). For signed-data, the message digest is computed using the
signer's message digest algorithm. For authenticated-data, the signer's message digest algorithm. For authenticated-data, the
message digest is computed using the message digest algorithm message digest is computed using the originator's message digest
identified by the authAttributesInfo digestAlgorithm. algorithm.
Within signed-data, the message-digest signed attribute type is Within signed-data, the message-digest signed attribute type is
required if there are any attributes present. Within authenticated- required if there are any attributes present. Within authenticated-
data, the message-digest authenticated attribute type is required if data, the message-digest authenticated attribute type is required if
there are any attributes present. there are any attributes present.
The message-digest attribute must be a signed attribute or an The message-digest 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 or an
unauthenticated attribute. unauthenticated attribute.
The following object identifier identifies the message-digest The following object identifier identifies the message-digest
attribute: attribute:
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
Message-digest attribute values have ASN.1 type MessageDigest: Message-digest attribute values have ASN.1 type MessageDigest:
MessageDigest ::= OCTET STRING MessageDigest ::= OCTET STRING
A message-digest attribute must have a single attribute value, even A message-digest attribute must have a single attribute value, even
though the syntax is defined as a SET OF AttributeValue. There must though the syntax is defined as a SET OF AttributeValue. There must
not be zero or multiple instances of AttributeValue present. not be zero or multiple instances of AttributeValue present.
The SignedAttributes syntax is defined as a SET OF Attributes. The The SignedAttributes syntax is defined as a SET OF Attributes. The
SignedAttributes in a signerInfo must not include multiple instances SignedAttributes in a signerInfo must not include multiple instances
skipping to change at page 32, line 6 skipping to change at page 34, line 40
Additional algorithms that should be implemented are also included. Additional algorithms that should be implemented are also included.
12.1 Digest Algorithms 12.1 Digest Algorithms
CMS implementations must include SHA-1. CMS implementations should CMS implementations must include SHA-1. CMS implementations should
include MD5. include MD5.
Digest algorithm identifiers are located in the SignedData Digest algorithm identifiers are located in the SignedData
digestAlgorithms field, the SignerInfo digestAlgorithm field, the digestAlgorithms field, the SignerInfo digestAlgorithm field, the
DigestedData digestAlgorithm field, and the AuthenticatedData DigestedData digestAlgorithm field, and the AuthenticatedData
authAttributesInfo digestAlgorithm field. digestAlgorithm field.
Digest values are located in the DigestedData digest field, and Digest values are located in the DigestedData digest field, and
digest values are located in the Message Digest authenticated digest values are located in the Message Digest authenticated
attribute. In addition, digest values are input to signature attribute. In addition, digest values are input to signature
algorithms. algorithms.
12.1.1 SHA-1 12.1.1 SHA-1
The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The
algorithm identifier for SHA-1 is: algorithm identifier for SHA-1 is:
skipping to change at page 32, line 29 skipping to change at page 35, line 21
oiw(14) secsig(3) algorithm(2) 26 } oiw(14) secsig(3) algorithm(2) 26 }
The AlgorithmIdentifier parameters field is optional. If present, The AlgorithmIdentifier parameters field is optional. If present,
the parameters field must contain an ASN.1 NULL. Implementations the parameters field must contain an ASN.1 NULL. Implementations
should accept SHA-1 AlgorithmIdentifiers with absent parameters as should accept SHA-1 AlgorithmIdentifiers with absent parameters as
well as NULL parameters. Implementations should generate SHA-1 well as NULL parameters. Implementations should generate SHA-1
AlgorithmIdentifiers with NULL parameters. AlgorithmIdentifiers with NULL parameters.
12.1.2 MD5 12.1.2 MD5
The MD5 digest algorithm is defined in RFC 1321 [RFC 1321]. The The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm
algorithm identifier for MD5 is: identifier for MD5 is:
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 } rsadsi(113549) digestAlgorithm(2) 5 }
The AlgorithmIdentifier parameters field must be present, and the The AlgorithmIdentifier parameters field must be present, and the
parameters field must contain NULL. Implementations may accept the parameters field must contain NULL. Implementations may accept the
MD5 AlgorithmIdentifiers with absent parameters as well as NULL MD5 AlgorithmIdentifiers with absent parameters as well as NULL
parameters. parameters.
12.2 Signature Algorithms 12.2 Signature Algorithms
skipping to change at page 33, line 19 skipping to change at page 36, line 18
always used with the SHA-1 message digest algorithm. The algorithm always used with the SHA-1 message digest algorithm. The algorithm
identifier for DSA is: identifier for DSA is:
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 3 } us(840) x9-57 (10040) x9cm(4) 3 }
The AlgorithmIdentifier parameters field must not be present. The AlgorithmIdentifier parameters field must not be present.
12.2.2 RSA 12.2.2 RSA
The RSA signature algorithm is defined in RFC 2313 [RFC 2313]. RFC The RSA signature algorithm is defined in RFC 2313 [PKCS#1]. RFC
2313 specifies the use of the RSA signature algorithm with the MD5 2313 specifies the use of the RSA signature algorithm with the MD5
message digest algorithm. That definition is extended here to message digest algorithm. That definition is extended here to
include support for the SHA-1 message digest algorithm as well. The include support for the SHA-1 message digest algorithm as well. The
algorithm identifier for RSA is: algorithm identifier 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 }
The AlgorithmIdentifier parameters field must be present, and the The AlgorithmIdentifier parameters field must be present, and the
parameters field must contain NULL. parameters field must contain NULL.
This specification modifies RFC 2313 to include SHA-1 as an This specification modifies RFC 2313 [PKCS#1] to include SHA-1 as an
additional message digest algorithm. Section 10.1.2 of RFC 2313 is additional message digest algorithm. Section 10.1.2 of RFC 2313 is
modified to list SHA-1 in the bullet item about digestAlgorithm. The modified to list SHA-1 in the bullet item about digestAlgorithm. The
following object identifier is added to the list in section 10.1.2 of following object identifier is added to the list in section 10.1.2 of
RFC 2313: RFC 2313:
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 } oiw(14) secsig(3) algorithm(2) 26 }
12.3 Key Management Algorithms 12.3 Key Management Algorithms
skipping to change at page 34, line 9 skipping to change at page 37, line 7
CMS implementations must include key agreement using X9.42 Ephemeral- CMS implementations must include key agreement using X9.42 Ephemeral-
Static Diffie-Hellman. 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 is wrapping of RC2 content-encryption keys. The key wrap algorithm for
described in section 12.6. Triple-DES and RC2 is described in section 12.3.3.
A CMS implementation may support mixed key-encryption and content- A CMS implementation may support mixed key-encryption and content-
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
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 Key agreement algorithm identifiers are located in the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm field. RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
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 RecipientInfo
KeyAgreeRecipientInfo keyEncryptionAlgorithm field. KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
Wrapped content-encryption keys are located in the EnvelopedData Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys
encryptedKey field. 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 TBD1
[RFC TBD1]. When using Ephemeral-Static Diffie-Hellman, the [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the
EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are used as EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are used as
follows: 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)
us(840) ansi-x942(10046) number-type(2) 1 } us(840) ansi-x942(10046) number-type(2) 1 }
ukm may be absent. The ukm is used to ensure that a different ukm may be absent. When present, the ukm is used to ensure that a
key-encryption key is generated when the ephemeral private key different key-encryption key is generated when the ephemeral
might be used more than once. private key might be used more than once.
keyEncryptionAlgorithm must be the id-alg-ESDH algorithm keyEncryptionAlgorithm must be the id-alg-ESDH algorithm
identifier. The algorithm identifier parameters field must be identifier. The algorithm identifier parameter field for id-alg-
present and contain a KeyWrapAlgorithm value. 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 }
skipping to change at page 35, line 45 skipping to change at page 38, line 47
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 field. RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm field.
Key transport encrypted content-encryption keys are located in the Key transport encrypted content-encryption keys are located in the
EnvelopedData RecipientInfo KeyTransRecipientInfo EncryptedKey field. EnvelopedData RecipientInfo KeyTransRecipientInfo EncryptedKey field.
12.3.2.1 RSA 12.3.2.1 RSA
The RSA key transport algorithm is defined in RFC 2313 [RFC 2313]. The RSA key transport algorithm is defined in RFC 2313 [PKCS#1]. RFC
RFC 2313 specifies the transport of content-encryption keys, 2313 specifies the transport of content-encryption keys, including
including Triple-DES and RC2 keys. The algorithm identifier for RSA Triple-DES and RC2 keys. The algorithm identifier for RSA is:
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 }
The AlgorithmIdentifier parameters field must be present, and the The AlgorithmIdentifier parameters field must be present, and the
parameters field must contain NULL. parameters field must contain NULL.
The use of RSA encryption, as defined in RFC 2313, to provide The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to
confidentiality has a known vulnerability concerns. The vulnerability provide confidentiality has a known vulnerability concerns. The
is primarily relevant to usage in interactive applications rather vulnerability is primarily relevant to usage in interactive
than to store-and-forward environments. Further information and applications rather than to store-and-forward environments. Further
proposed countermeasures are discussed in the Security Considerations information and proposed countermeasures are discussed in the
section of this document. Security Considerations section of this document.
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. The key wrap algorithm is specified in RC2 content-encryption keys. A CMS implementation may support mixed
section 12.6. 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 field. RecipientInfo KEKRecipientInfo keyEncryptionAlgorithm field.
Wrapped content-encryption keys are located in the EnvelopedData Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfo KEKRecipientInfo encryptedKey field. RecipientInfo KEKRecipientInfo encryptedKey field.
In conjunction with key agreement algorithms, CMS implementations The output of a key agreement algorithm is a key-encryption key, and
must include encryption of content-encryption keys with the pairwise this key-encryption key is used to encrypt the content-encryption
key-encryption key generated using a key agreement algorithm. To key. In conjunction with key agreement algorithms, CMS
support key agreement, key wrap algorithm identifiers are located in implementations must include encryption of content-encryption keys
the KeyWrapAlgorithm parameter of the EnvelopedData RecipientInfo with the pairwise key-encryption key generated using a key agreement
KeyAgreeRecipientInfo keyEncryptionAlgorithm field, and wrapped algorithm. To support key agreement, key wrap algorithm identifiers
content-encryption keys are located in the EnvelopedData are located in the KeyWrapAlgorithm parameter of the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm field, and
wrapped content-encryption keys are located in the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys
encryptedKey field. 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-3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 3 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 3 }
The AlgorithmIdentifier parameter field must be NULL. 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 Out-of-band distribution of the Triple-DES key-encryption key used to
encrypt the Triple-DES content-encryption key is out of the scope of encrypt the Triple-DES content-encryption key is beyond of the scope
this document. of this document.
12.3.3.2 RC2 Key Wrap 12.3.3.2 RC2 Key Wrap
RC2 key encryption has the algorithm identifier: RC2 key encryption has the algorithm identifier:
id-alg-RC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-RC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 4 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 4 }
The AlgorithmIdentifier parameter field must be RC2wrapParameter: The AlgorithmIdentifier parameter field must be RC2wrapParameter:
skipping to change at page 37, line 25 skipping to change at page 40, line 33
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.
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 Out-of-band distribution of the RC2 key-encryption key used to
encrypt the RC2 content-encryption key is out 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
implementations should include RC2 in CBC mode. implementations should include RC2 in CBC mode.
Content encryption algorithms identifiers are located in the Content encryption algorithms identifiers are located in the
EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field
and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm
field. field.
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 [3DES]. The algorithm The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The
identifier for Triple-DES is: algorithm identifier for Triple-DES 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 contain The AlgorithmIdentifier parameters field must be present, and the
a CBCParameter: parameters field must contain a CBCParameter:
CBCParameter ::= IV CBCParameter ::= IV
IV ::= OCTET STRING -- exactly 8 octets IV ::= OCTET STRING -- exactly 8 octets
12.4.2 RC2 CBC 12.4.2 RC2 CBC
The RC2 algorithm is described in RFC 2268 [RFC 2268]. The algorithm The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm
identifier for RC2 in CBC mode is: identifier for RC2 in CBC mode is:
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 } rsadsi(113549) encryptionAlgorithm(3) 2 }
The AlgorithmIdentifier parameters field must be present and contain The AlgorithmIdentifier parameters field must be present, and the
a RC2CBCParameter: parameters field must contain a RC2CBCParameter:
RC2CBCParameter ::= SEQUENCE { RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER, rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets iv OCTET STRING } -- exactly 8 octets
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), since Note that the value 160 must be encoded as two octets (00 A0), since
the one octet (A0) encoding represents a negative number. the one octet (A0) encoding represents a negative number.
12.5 Message Authentication Code Algorithms 12.5 Message Authentication Code Algorithms
CMS implementations that support authenticatedData must include HMAC CMS implementations that support authenticatedData must include HMAC
with SHA-1. with SHA-1.
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 MAC values are located in the AuthenticatedData mac field.
values are also located in the mac-value authenticated attribute.
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 [RFC 2104]. The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The
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 CMS Key Wrap Algorithm 12.6 Triple-DES and RC2 Key Wrap Algorithm
CMS implementations must implement the key wrap algorithm specified CMS implementations must include encryption of a Triple-DES content-
in this section. encryption key with a Triple-DES key-encryption key using the
algorithm specified in this section. CMS implementations should
include encryption of a RC2 content-encryption key with a RC2 key-
encryption key. 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 Key Transport algorithms allow for the content-encryption key to be
directly encrypted; however, key agreement and symmetric key- directly encrypted; however, key agreement and symmetric key-
encryption key algorithms encrypt the content-encryption key with a encryption key algorithms encrypt the content-encryption key with a
second symmetric encryption algorithm. This section describes how second symmetric encryption algorithm. This section describes how
the content-encryption key is formatted and encrypted. the Triple-DES or RC2 content-encryption key is formatted and
encrypted.
Key agreement algorithms generate a pairwise key-encryption key, and Key agreement algorithms generate a pairwise key-encryption key, and
this key wrap algorithm is used to encrypt the content-encryption key a key wrap algorithm is used to encrypt the content-encryption key
with the pairwise key-encryption key. Similarly, this key wrap with the pairwise key-encryption key. Similarly, a key wrap
algorithm is used to encrypt the content-encryption key in a algorithm is used to encrypt the content-encryption key in a
previously distributed key-encryption key. previously distributed key-encryption key.
The key-encryption key is generated by the key agreement algorithm or The key-encryption key is generated by the key agreement algorithm or
distributed out of band. For key agreement of RC2 key-encryption distributed out of band. For key agreement of RC2 key-encryption
keys, 128 bits must be generated as input to the key expansion keys, 128 bits must be generated as input to the key expansion
process used to compute the RC2 effective key [RFC 2268]. process used to compute the RC2 effective key [RC2].
The block size of the key-encryption algorithm must be implicitly The block size of the key-encryption algorithm must be implicitly
determined from the KeyEncryptionAlgorithmIdentifier field. determined from the KeyEncryptionAlgorithmIdentifier field; however,
Likewise, the size of the content-encryption key must be implicitly both Triple-DES and RC2 have a block size of eight octets.
determined from the ContentEncryptionAlgorithmIdentifier field.
Since the same algorithm identifier is used for both 2-key and 3-key The same algorithm identifier is used for both 2-key and 3-key
Triple-DES, three keys are always wrapped for Triple-DES. Thus, Triple-DES. When the length of the wrapped content-encryption key is
2-key Triple-DES provides three keys where the first and third keys 16 octets, 2-key Triple-DES is used for the content-encryption
are the same. algorithm. Similarly, when the length of the wrapped content-
encryption key is 24 octets, 3-key Triple-DES is used for the
content-encryption algorithm.
12.6.1 Key Checksum 12.6.1 Key Checksum
The Fletcher checksum [SUM] algorithm is used to provide an integrity The CMS Checksum Algorithm is used to provide an content-encryption
check value. The algorithm is: key integrity check value. The algorithm is:
1. Initialize two 16 bit integers, sum1 and sum2, to zero. 1. Compute a 20 octet SHA-1 [SHA1] message digest on the
2. Loop through the octets of the content-encryption key, most content-encryption key.
significant (first) octet to least significant (last) octet. 2. Use the most significant (first) eight octets of the message
2a. Create a 16 bit integer, called temp, by concatenating digest value as the checksum value.
eight zero bits and the key octet.
2b. sum1 = sum1 + temp.
2c. sum2 = sum2 + sum1.
3. Use sum2 as the checksum value.
12.6.2 Key Wrap 12.6.2 Key Wrap
1. Modify the content-encryption key to meet any restrictions on the key. 1. Modify the content-encryption key to meet any restrictions on the key.
For example, adjust the parity bits for each DES key comprising a For example, adjust the parity bits for each DES key comprising a
Triple-DES key. Triple-DES key.
2. Compute a 16-bit key checksum value on the content-encryption key as 2. Compute a 8 octet key checksum value on the content-encryption key as
described above. described Section 12.6.1 above.
3. Generate a 32-bit random salt value. 3. Generate a 4 octet random salt value.
4. Concatenate the salt, content-encryption key, and key checksum value. 4. Concatenate the salt, content-encryption key, and key checksum value.
5. Randomly generate the number of pad octets necessary to make the result 5. Pad the result, using the technique specified in Section 6.3, so
a multiple of block size of the key-encryption algorithm (the Triple-DES that the padded result is a multiple of eight octets (the Triple-DES
block size is 8 bytes), then append them to the result. and RC2 block size). Append the pad to the result.
6. Encrypt the result with the key-encryption algorithm key. Use an IV 6. Encrypt in CBC mode the padded result using the key-encryption key.
with each octet equal to 'A5' hexadecimal. Use an IV with each octet equal to 'A5' hexadecimal.
Some key-encryption algorithm identifiers include an IV as part of
the parameters. The IV must still be the constant above.
12.6.3 Key Unwrap 12.6.3 Key Unwrap
The key unwrap algorithm is: The key unwrap algorithm is:
1. Decrypt the ciphertext using the key-encryption key. Use an IV 1. Decrypt in CBC mode the ciphertext using the key-encryption key. Use
with each octet equal to 'A5' hexadecimal. an IV with each octet equal to 'A5' hexadecimal.
2. Decompose the result into the content-encryption key and key checksum 2. Decompose the result into the content-encryption key and key checksum
values. The salt and pad values are discarded. values. The salt and pad values are discarded.
3. Compute a 16-bit key checksum value on the content-encryption key 3. Compute a 8 octet key checksum value on the content-encryption key
as described above. as described in Section 12.6.1 above.
4. If computed key checksum value does not match the decrypted key 4. If the computed key checksum value does not match the decrypted key
checksum value, then there is an error. checksum value, then there is an error.
5. If there are restrictions on keys, then check if the 5. If there are restrictions on keys, then check if the content-
content-encryption key meets these restrictions. For example, encryption key meets these restrictions. For example, check for odd
check for odd parity of each octet in each DES key that makes up parity of each octet in each DES key that makes up a Triple-DES key.
a Triple-DES key. If any restriction is incorrect, then there is If any restriction is incorrect, then there is an error.
an error.
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 ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at page 42, line 10 skipping to change at page 45, line 10
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo SignerInfos ::= SET OF SignerInfo
EncapsulatedContentInfo ::= SEQUENCE { EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL } eContent [0] EXPLICIT OCTET STRING OPTIONAL }
SignerInfo ::= SEQUENCE { SignerInfo ::= SEQUENCE {
version CMSVersion, version CMSVersion,
issuerAndSerialNumber IssuerAndSerialNumber, sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier, signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue, signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE { Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER, attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue } attrValues SET OF AttributeValue }
AttributeValue ::= ANY AttributeValue ::= ANY
SignatureValue ::= OCTET STRING SignatureValue ::= OCTET STRING
EnvelopedData ::= SEQUENCE { EnvelopedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo, encryptedContentInfo EncryptedContentInfo,
plaintextAttrs [1] IMPLICIT PlaintextAttributes OPTIONAL } unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
OriginatorInfo ::= SEQUENCE { OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL, certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }
RecipientInfos ::= SET OF RecipientInfo RecipientInfos ::= SET OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE { EncryptedContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING EncryptedContent ::= OCTET STRING
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
PlaintextAttributes ::= SET SIZE (1..MAX) OF Attribute
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo } kekri [2] KEKRecipientInfo }
EncryptedKey ::= OCTET STRING EncryptedKey ::= OCTET STRING
KeyTransRecipientInfo ::= SEQUENCE { KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2 version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier, rid RecipientIdentifier,
skipping to change at page 44, line 34 skipping to change at page 47, line 39
EncryptedData ::= SEQUENCE { EncryptedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
encryptedContentInfo EncryptedContentInfo } encryptedContentInfo EncryptedContentInfo }
AuthenticatedData ::= SEQUENCE { AuthenticatedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm, macAlgorithm MessageAuthenticationCodeAlgorithm,
authAttributesInfo [1] IMPLICIT AuthAttributesInfo OPTIONAL, digestAlgorithm [1] DigestAlgorithm OPTIONAL,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
authenctiatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode, mac MessageAuthenticationCode,
unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL }
AuthAttributesInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
authenticatedAttributes AuthAttributes }
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
MessageAuthenticationCode ::= OCTET STRING MessageAuthenticationCode ::= OCTET STRING
DigestAlgorithmIdentifier ::= AlgorithmIdentifier DigestAlgorithmIdentifier ::= AlgorithmIdentifier
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
CertificateRevocationLists ::= SET OF CertificateList CertificateRevocationLists ::= SET OF CertificateList
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509 certificate Certificate, -- See X.509
skipping to change at page 47, line 15 skipping to change at page 50, line 15
version CMSVersion, version CMSVersion,
certificate Certificate, certificate Certificate,
attributes UnauthAttributes } attributes UnauthAttributes }
Signature ::= BIT STRING Signature ::= BIT STRING
END -- of CryptographicMessageSyntax END -- of CryptographicMessageSyntax
References References
3DES Tuchman, W. "Hellman Presents No Shortcut Solutions To DES". 3DES American National Standards Institute. ANSI X9.52-1998,
IEEE Spectrum, v. 16, n. 7, pp40-41. July 1979. 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.
(currently draft-ietf-smime-x942-*.txt)
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.
PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax ESS Hoffman, P. Enhanced Security Services for S/MIME.
Standard, Version 1.5. November 1993. (currently draft-ietf-smime-ess-*.txt)
PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types,
Version 1.1. November 1993.
RFC 1321 Rivest, R. The MD5 Message-Digest Algorithm. April 1992.
RFC 1750 Eastlake, D.; S. Crocker; J. Schiller. Randomness
Recommendations for Security. December 1994.
RFC 2104 Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication.
February 1997. February 1997.
RFC 2268 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. MD5 Rivest, R. The MD5 Message-Digest Algorithm. April 1992.
March 1998.
RFC 2313 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. MODES National Institute of Standards and Technology.
March 1998. FIPS Pub 81: DES Modes of Operation. 2 December 1980.
RFC 2315 Kaliski, B. PKCS #7: Cryptographic Message Syntax, MSG Ramsdell, B. S/MIME Version 3 Message Specification.
Version 1.5. March 1998. (currently draft-ietf-smime-msg-*.txt)
RFC 2437 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. NEWPKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0.
October 1998. October 1998.
RFC TBD Housley, R., W. Ford, W. Polk, D. Solo. Internet PROFILE Housley, R., W. Ford, W. Polk, D. Solo. Internet
X.509 Public Key Infrastructure: Certificate and CRL X.509 Public Key Infrastructure: Certificate and CRL
Profile. (currently draft-ietf-pkix-ipki-part1-*.txt) Profile. (currently draft-ietf-pkix-ipki-part1-*.txt)
PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5.
March 1998.
RFC TBD1 Rescorla, E. Ephemeral-Static Diffie-Hellman Key PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax
Agreement Method. (currently draft-ietf-smime-x942-*.txt) Standard, Version 1.5. November 1993.
RFC TBD2 Ramsdell, B. S/MIME Version 3 Message Specification. PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax,
(currently draft-ietf-smime-msg-*.txt) Version 1.5. March 1998.
RFC TBD3 Hoffman, P. Enhanced Security Services for S/MIME. PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types,
(currently draft-ietf-smime-ess-*.txt) Version 1.1. November 1993.
RANDOM Eastlake, D.; S. Crocker; J. Schiller. Randomness
Recommendations for Security. December 1994.
RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm.
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.
SUM Fletcher, J. "An Arithmetic Checksum for Serial
Transmissions", IEEE Transactions on Communication,
Vol. COM-30, No. 1, pp. 247-252, January 1982.
X.208 CCITT. Recommendation X.208: Specification of Abstract X.208 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 CCITT. Recommendation X.209: Specification of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1). 1988. Rules for Abstract Syntax Notation One (ASN.1). 1988.
X.501 CCITT. Recommendation X.501: The Directory - Models. 1988. X.501 CCITT. Recommendation X.501: The Directory - Models. 1988.
X.509 CCITT. Recommendation X.509: The Directory - Authentication X.509 CCITT. Recommendation X.509: The Directory - Authentication
Framework. 1988. Framework. 1988.
skipping to change at page 49, line 18 skipping to change at page 52, line 20
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), salt
values, and padding. Also, the generation of public/private key values, and padding. Also, the generation of public/private key
pairs relies on a random numbers. The use of inadequate pseudo- pairs relies on a random numbers. The use of inadequate pseudo-
random number generators (PRNGs) to generate cryptographic keys can random number generators (PRNGs) to generate cryptographic keys can
result in little or no security. An attacker may find it much easier result in little or no security. An attacker may find it much easier
to reproduce the PRNG environment that produced the keys, searching to reproduce the PRNG environment that produced the keys, searching
the resulting small set of possibilities, rather than brute force the 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 offers important guidance in this numbers is difficult. RFC 1750 [RANDOM] offers important guidance in
area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality
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,
a message content is encrypted with 168-bit Triple-DES and the 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, 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 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, 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 message and then the Triple-DES key can be used to decrypt the content.
content. Therefore, implementers must ensure that key-encryption Therefore, implementers must ensure that key-encryption algorithms
algorithms are as strong or stronger than content-encryption are as strong or stronger than content-encryption algorithms.
algorithms.
Section 12.6 specifies a key wrap algorithm used to encrypt a Triple-
DES [3DES] or RC2 [RC2] content-encryption key with a Triple-DES or
RC2 key-encryption key using CBC mode [MODES]. This key wrap
algorithm has been reviewed for use with Triple-DES in CBC mode and
RC2 in CBC mode; it has not been reviewed for use with other
algorithms or other modes. Analysis has discovered concerns with
using this key wrap algorithm with stream ciphers or block ciphers in
OFB mode [MODES]. Therefore, if a CMS implementation wises to
support ciphers in addition to Triple-DES in CBC mode or RC2 in CBC
mode, then additional key wrap algorithms may need to be defined to
support the additional ciphers.
The countersignature unauthenticated attribute includes a digital The countersignature unauthenticated attribute includes a digital
signature that is computed on the content signature value, thus the signature that is computed on the content signature value, thus the
countersigning process need not know the original signed content. countersigning process need not know the original signed content.
This structure permits implementation efficiency advantages; however, This structure permits implementation efficiency advantages; however,
this structure may also permit the countersigning of an inappropriate this structure may also permit the countersigning of an inappropriate
signature value. Therefore, implementations that perform signature value. Therefore, implementations that perform
countersignatures should either validate the original signature value countersignatures should either validate the original signature value
prior to countersigning it (this validation requires processing of prior to countersigning it (this validation requires processing of
the original content), or implementations should perform the original content), or implementations should perform
countersigning in a context that ensures that only appropriate countersigning in a context that ensures that only appropriate
signature values are countersigned. signature values are countersigned.
Users of CMS, particularly those employing CMS to support interactive Users of CMS, particularly those employing CMS to support interactive
applications, should be aware that PKCS #1 Version 1.5 [RFC 2313] is applications, should be aware that PKCS #1 Version 1.5 as specified
vulnerable to adaptive chosen ciphertext attacks when applied for in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext
encryption purposes. Exploitation of this identified vulnerability, attacks when applied for encryption purposes. Exploitation of this
revealing the result of a particular RSA decryption, requires access identified vulnerability, revealing the result of a particular RSA
to an oracle which will respond to a large number of ciphertexts decryption, requires access to an oracle which will respond to a
(based on currently available results, hundreds of thousands or large number of ciphertexts (based on currently available results,
more), which are constructed adaptively in response to previously- hundreds of thousands or more), which are constructed adaptively in
received replies providing information on the successes or failures response to previously-received replies providing information on the
of attempted decryption operations. As a result, the attack appears successes or failures of attempted decryption operations. As a
significantly less feasible to perpetrate for store-and-forward result, the attack appears significantly less feasible to perpetrate
S/MIME environments than for directly interactive protocols. Where for store-and-forward S/MIME environments than for directly
CMS constructs are applied as an intermediate encryption layer within interactive protocols. Where CMS constructs are applied as an
an interactive request-response communications environment, intermediate encryption layer within an interactive request-response
exploitation could be more feasible. communications environment, exploitation could be more feasible.
An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0
[RFC 2437]. This new document will supersede RFC 2313. PKCS#1 [NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1
Version 2.0 preserves support for the encryption padding format Version 2.0 preserves support for the encryption padding format
defined in PKCS#1 Version 1.5 [RFC 2313], and it also defines a new defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new
alternative. To resolve the adaptive chosen ciphertext alternative. To resolve the adaptive chosen ciphertext
vulnerability, the PKCS #1 Version 2.0 specifies and recommends use vulnerability, the PKCS #1 Version 2.0 specifies and recommends use
of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption
is used to provide confidentiality. Designers of protocols and is used to provide confidentiality. Designers of protocols and
systems employing CMS for interactive environments should either systems employing CMS for interactive environments should either
consider usage of OAEP, or should ensure that information which could consider usage of OAEP, or should ensure that information which could
reveal the success or failure of attempted PKCS #1 Version 1.5 reveal the success or failure of attempted PKCS #1 Version 1.5
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.
skipping to change at line 2366 skipping to change at page 54, line 15
Author Address Author 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 housley@spyrus.com
Full Copyright Statement
Copyright (C) The Internet Society (date). 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. In addition, the
ASN.1 module presented in Appendix A may be used in whole or in part
without inclusion of the copyright notice. 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 shall 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.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/