draft-ietf-smime-rfc2630bis-08.txt   rfc3369.txt 
S/MIME Working Group R. Housley Network Working Group R. Housley
Internet Draft RSA Laboratories Request for Comments: 3369 RSA Laboratories
expires in six months April 2002 Obsoletes: 2630, 3211 August 2002
Obsoletes: RFC 2630 and RFC 3211 Category: Standards Track
Cryptographic Message Syntax
<draft-ietf-smime-rfc2630bis-08.txt> Cryptographic Message Syntax (CMS)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet-Drafts are working Internet community, and requests discussion and suggestions for
documents of the Internet Engineering Task Force (IETF), its areas, improvements. Please refer to the current edition of the "Internet
and its working groups. Note that other groups may also distribute Official Protocol Standards" (STD 1) for the standardization state
working documents as Internet-Drafts. and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2002). All Rights Reserved.
http://www.ietf.org/shadow.html
Abstract Abstract
This document describes the Cryptographic Message Syntax (CMS). This This document describes the Cryptographic Message Syntax (CMS). This
syntax is used to digitally sign, digest, authenticate, or encrypt syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary message content. arbitrary message content.
Table of Contents Table of Contents
Status of this Memo ................................................ 1 1. Introduction ................................................ 3
Abstract ........................................................... 1 1.1 Changes Since RFC 2630 ...................................... 3
Table of Contents .................................................. 2 1.2 Terminology ................................................. 4
1 Introduction ................................................... 4 2. General Overview ............................................ 4
1.1 Changes Since RFC 2630 .................................... 4 3. General Syntax .............................................. 5
1.2 Terminology ............................................... 5 4. Data Content Type ........................................... 5
2 General Overview ............................................... 5 5. Signed-data Content Type .................................... 6
3 General Syntax ................................................. 6 5.1 SignedData Type ............................................. 7
4 Data Content Type .............................................. 6 5.2 EncapsulatedContentInfo Type ................................ 9
5 Signed-data Content Type ....................................... 7 5.2.1 Compatibility with PKCS #7 ................................ 9
5.1 SignedData Type ........................................... 8 5.3 SignerInfo Type ............................................. 11
5.2 EncapsulatedContentInfo Type .............................. 9 5.4 Message Digest Calculation Process .......................... 13
5.2.1 Compatibility with PKCS #7 ......................... 10 5.5 Signature Generation Process ................................ 14
5.3 SignerInfo Type ........................................... 12 5.6 Signature Verification Process .............................. 14
5.4 Message Digest Calculation Process ........................ 14 6. Enveloped-data Content Type ................................. 14
5.5 Signature Generation Process .............................. 15 6.1 EnvelopedData Type .......................................... 16
5.6 Signature Verification Process ............................ 15 6.2 RecipientInfo Type .......................................... 18
6 Enveloped-data Content Type .................................... 15 6.2.1 KeyTransRecipientInfo Type ................................ 19
6.1 EnvelopedData Type ........................................ 17 6.2.2 KeyAgreeRecipientInfo Type ................................ 20
6.2 RecipientInfo Type ........................................ 19 6.2.3 KEKRecipientInfo Type ..................................... 22
6.2.1 KeyTransRecipientInfo Type ......................... 20 6.2.4 PasswordRecipientInfo Type ................................ 23
6.2.2 KeyAgreeRecipientInfo Type ......................... 21 6.2.5 OtherRecipientInfo Type ................................... 24
6.2.3 KEKRecipientInfo Type .............................. 23 6.3 Content-encryption Process .................................. 24
6.2.4 PasswordRecipientInfo Type ......................... 24 6.4 Key-encryption Process ...................................... 25
6.2.5 OtherRecipientInfo Type ............................ 25 7. Digested-data Content Type .................................. 25
6.3 Content-encryption Process ................................ 25 8. Encrypted-data Content Type ................................. 26
6.4 Key-encryption Process .................................... 26 9. Authenticated-data Content Type ............................. 27
7 Digested-data Content Type ..................................... 26 9.1 AuthenticatedData Type ...................................... 28
8 Encrypted-data Content Type .................................... 27 9.2 MAC Generation .............................................. 29
9 Authenticated-data Content Type ................................ 28 9.3 MAC Verification ............................................ 31
9.1 AuthenticatedData Type .................................... 29 10. Useful Types ................................................ 31
9.2 MAC Generation ............................................ 30 10.1 Algorithm Identifier Types ................................. 31
9.3 MAC Verification .......................................... 31 10.1.1 DigestAlgorithmIdentifier ................................ 31
10 Useful Types ................................................... 32 10.1.2 SignatureAlgorithmIdentifier ............................. 32
10.1 Algorithm Identifier Types ............................... 32 10.1.3 KeyEncryptionAlgorithmIdentifier ......................... 32
10.1.1 DigestAlgorithmIdentifier ........................ 32 10.1.4 ContentEncryptionAlgorithmIdentifier ..................... 32
10.1.2 SignatureAlgorithmIdentifier ..................... 32 10.1.5 MessageAuthenticationCodeAlgorithm ....................... 32
10.1.3 KeyEncryptionAlgorithmIdentifier ................. 33 10.1.6 KeyDerivationAlgorithmIdentifier ......................... 33
10.1.4 ContentEncryptionAlgorithmIdentifier ............. 33 10.2 Other Useful Types ......................................... 33
10.1.5 MessageAuthenticationCodeAlgorithm ............... 33 10.2.1 CertificateRevocationLists ............................... 33
10.1.6 KeyDerivationAlgorithmIdentifier ................. 34 10.2.2 CertificateChoices ....................................... 33
10.2.3 CertificateSet ........................................... 34
10.2 Other Useful Types ....................................... 34 10.2.4 IssuerAndSerialNumber .................................... 34
10.2.1 CertificateRevocationLists ....................... 33 10.2.5 CMSVersion ............................................... 35
10.2.2 CertificateChoices ............................... 34 10.2.6 UserKeyingMaterial ....................................... 35
10.2.3 CertificateSet ................................... 35 10.2.7 OtherKeyAttribute ........................................ 35
10.2.4 IssuerAndSerialNumber ............................ 35 11. Useful Attributes ........................................... 35
10.2.5 CMSVersion ....................................... 36 11.1 Content Type ............................................... 36
10.2.6 UserKeyingMaterial ............................... 36 11.2 Message Digest ............................................. 36
10.2.7 OtherKeyAttribute ................................ 36 11.3 Signing Time ............................................... 37
11 Useful Attributes .............................................. 36 11.4 Countersignature ........................................... 39
11.1 Content Type ............................................. 36 12. ASN.1 Modules ............................................... 40
11.2 Message Digest ........................................... 37 12.1 CMS ASN.1 Module ........................................... 40
11.3 Signing Time ............................................. 38 12.2 Version 1 Attribute Certificate ASN.1 Module ............... 46
11.4 Countersignature ......................................... 39 13. References .................................................. 47
12 ASN.1 Modules .................................................. 40 14. Security Considerations ..................................... 48
12.1 CMS ASN.1 Module ......................................... 41 15. Acknowledgments ............................................. 50
12.2 Version 1 Attribute Certificate ASN.1 Module ............. 47 16. Author Address .............................................. 50
13 References ..................................................... 48 17. Full Copyright Statement .................................... 51
14 Security Considerations ........................................ 50
15 Acknowledgments ................................................ 52
16 Author Address ................................................. 52
17 Full Copyright Statement ....................................... 52
1 Introduction 1. Introduction
This document describes the Cryptographic Message Syntax (CMS). This This document describes the Cryptographic Message Syntax (CMS). This
syntax is used to digitally sign, digest, authenticate, or encrypt syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary message content. arbitrary message content.
The CMS describes an encapsulation syntax for data protection. It The CMS describes an encapsulation syntax for data protection. It
supports digital signatures and encryption. The syntax allows supports digital signatures and encryption. The syntax allows
multiple encapsulations; one encapsulation envelope can be nested multiple encapsulations; one encapsulation envelope can be nested
inside another. Likewise, one party can digitally sign some inside another. Likewise, one party can digitally sign some
previously encapsulated data. It also allows arbitrary attributes, previously encapsulated data. It also allows arbitrary attributes,
skipping to change at page 5, line 9 skipping to change at page 4, line 9
S/MIME v2 signatures [OLDMSG], which are based on PKCS#7 version 1.5, S/MIME v2 signatures [OLDMSG], which are based on PKCS#7 version 1.5,
are compatible with S/MIME v3 signatures [MSG], which are based on are compatible with S/MIME v3 signatures [MSG], which are based on
RFC 2630. However, there are some subtle compatibility issues with RFC 2630. However, there are some subtle compatibility issues with
signatures using PKCS#7 version 1.5 and the CMS. These issues are signatures using PKCS#7 version 1.5 and the CMS. These issues are
discussed in section 5.2.1. discussed in section 5.2.1.
Specific cryptographic algorithms are not discussed in this document, Specific cryptographic algorithms are not discussed in this document,
but they were discussed in RFC 2630. The discussion of specific but they were discussed in RFC 2630. The discussion of specific
cryptographic algorithms has been moved to a separate document cryptographic algorithms has been moved to a separate document
[CMSALG]. Separation of the protocol and algorithm specifications [CMSALG]. Separation of the protocol and algorithm specifications
allows the IETF to update each document independently. No mandatory allows the IETF to update each document independently. This
to implement algorithms are specified. Rather, protocols that rely specification does not require the implementation of any particular
on the CMS are expected to choose appropriate algorithms for their algorithms. Rather, protocols that rely on the CMS are expected to
environment. The algorithms may be selected from [CMSALG] or choose appropriate algorithms for their environment. The algorithms
elsewhere. may be selected from [CMSALG] or elsewhere.
1.2 Terminology 1.2 Terminology
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
described by Scott Bradner in [STDWORDS]. described in [STDWORDS].
2 General Overview 2 General Overview
The CMS is general enough to support many different content types. The CMS is general enough to support many different content types.
This document defines one protection content, ContentInfo. This document defines one protection content, ContentInfo.
ContentInfo encapsulates a single identified content type, and the ContentInfo encapsulates a single identified content type, and the
identified type may provide further encapsulation. This document identified type may provide further encapsulation. This document
defines six content types: data, signed-data, enveloped-data, defines six content types: data, signed-data, enveloped-data,
digested-data, encrypted-data, and authenticated-data. Additional digested-data, encrypted-data, and authenticated-data. Additional
content types can be defined outside this document. content types can be defined outside this document.
skipping to change at page 6, line 11 skipping to change at page 5, line 11
content that contains one or more unrecognized attributes. Signed content that contains one or more unrecognized attributes. Signed
attributes and authenticated attributes are the only data types used attributes and authenticated attributes are the only data types used
in the CMS that require DER encoding. in the CMS that require DER encoding.
3 General Syntax 3 General Syntax
The following object identifier identifies the content information The following object identifier identifies the content information
type: type:
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }
The CMS associates a content type identifier with a content. The The CMS associates a content type identifier with a content. The
syntax MUST have ASN.1 type ContentInfo: syntax MUST have ASN.1 type ContentInfo:
ContentInfo ::= SEQUENCE { ContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType } content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER ContentType ::= OBJECT IDENTIFIER
skipping to change at page 6, line 40 skipping to change at page 5, line 40
signed-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).
S/MIME uses id-data to identify MIME encoded content. The use of S/MIME uses id-data to identify MIME encoded content. The use of
this content identifier is specified in RFC 2311 for S/MIME v2 this content identifier is specified in RFC 2311 for S/MIME v2
[OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. [OLDMSG] and RFC 2633 for S/MIME v3 [MSG].
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. content type.
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
revocation lists (CRLs). revocation lists (CRLs).
skipping to change at page 8, line 13 skipping to change at page 7, line 18
information type SignerInfo, and the fourth, fifth, and sixth parts information type SignerInfo, and the fourth, fifth, and sixth parts
describe the message digest calculation, signature generation, and describe the message digest calculation, signature generation, and
signature verification processes, respectively. signature verification processes, respectively.
5.1 SignedData Type 5.1 SignedData Type
The following object identifier identifies the signed-data content The following object identifier identifies the signed-data content
type: type:
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
The signed-data content type shall have ASN.1 type SignedData: The signed-data content type shall have ASN.1 type SignedData:
SignedData ::= SEQUENCE { SignedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers, digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL, certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos } signerInfos SignerInfos }
skipping to change at page 8, line 36 skipping to change at page 7, line 41
SignerInfos ::= SET OF SignerInfo SignerInfos ::= SET OF SignerInfo
The fields of type SignedData have the following meanings: The fields of type SignedData have the following meanings:
version is the syntax version number. The appropriate value version is the syntax version number. The appropriate value
depends on certificates, eContentType, and SignerInfo. The depends on certificates, eContentType, and SignerInfo. The
version MUST be assigned as follows: version MUST be assigned as follows:
IF (certificates is present) AND IF (certificates is present) AND
(any version 2 attribute certificates are present) (any version 2 attribute certificates are present)
THEN version MUST be 4 THEN version MUST be 4
ELSE ELSE
IF ((certificates is present) AND IF ((certificates is present) AND
(any version 1 attribute certificates are present)) OR (any version 1 attribute certificates are present)) OR
(encapContentInfo eContentType is other than id-data) OR (encapContentInfo eContentType is other than id-data) OR
(any SignerInfo structures are version 3) (any SignerInfo structures are version 3)
THEN version MUST be 3 THEN version MUST be 3
ELSE version MUST be 1 ELSE version MUST be 1
digestAlgorithms is a collection of message digest algorithm digestAlgorithms is a collection of message digest algorithm
identifiers. There MAY be any number of elements in the identifiers. There MAY be any number of elements in the
collection, including zero. Each element identifies the message collection, including zero. Each element identifies the message
digest algorithm, along with any associated parameters, used by digest algorithm, along with any associated parameters, used by
one or more signer. The collection is intended to list the one or more signer. The collection is intended to list the
message digest algorithms employed by all of the signers, in any message digest algorithms employed by all of the signers, in any
order, to facilitate one-pass signature verification. order, to facilitate one-pass signature verification.
Implementations MAY fail to validate signatures that use a digest Implementations MAY fail to validate signatures that use a digest
algorithm that is not included in this set. The message digesting algorithm that is not included in this set. The message digesting
skipping to change at page 13, line 27 skipping to change at page 12, line 32
signedAttrs is a collection of attributes that are signed. The signedAttrs is a collection of attributes that are signed. The
field is optional, but it MUST be present if the content type of field is optional, but it MUST be present if the content type of
the EncapsulatedContentInfo value being signed is not id-data. the EncapsulatedContentInfo value being signed is not id-data.
SignedAttributes MUST be DER encoded, even if the rest of the SignedAttributes MUST be DER encoded, even if the rest of the
structure is BER encoded. Useful attribute types, such as signing structure is BER encoded. Useful attribute types, such as signing
time, are defined in Section 11. If the field is present, it MUST time, are defined in Section 11. If the field is present, it MUST
contain, at a minimum, the following two attributes: 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 signed. Section of the EncapsulatedContentInfo value being signed. Section
11.1 defines the content-type attribute. However, the content- 11.1 defines the content-type attribute. However, the
type attribute MUST NOT be used as part of a countersignature content-type attribute MUST NOT be used as part of a
unsigned attribute as defined in section 11.4. countersignature unsigned attribute as defined in section 11.4.
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.
signatureAlgorithm identifies the signature algorithm, and any signatureAlgorithm identifies the signature algorithm, and any
associated parameters, used by the signer to generate the digital associated parameters, used by the signer to generate the digital
signature. signature.
signature is the result of digital signature generation, using the signature is the result of digital signature generation, using the
skipping to change at page 15, line 40 skipping to change at page 14, line 47
signedAttributes, then the content message digest MUST be calculated signedAttributes, then the content message digest MUST be calculated
as described in section 5.4. For the signature to be valid, the as described in section 5.4. For the signature to be valid, the
message digest value calculated by the recipient MUST be the same as message digest value calculated by the recipient MUST be the same as
the value of the messageDigest attribute included in the the value of the messageDigest attribute included in the
signedAttributes of the SignedData signerInfo. signedAttributes of the SignedData signerInfo.
If the SignedData signerInfo includes signedAttributes, then the If the SignedData signerInfo includes signedAttributes, then the
content-type attribute value MUST match the SignedData content-type attribute value MUST match the SignedData
encapContentInfo eContentType value. encapContentInfo eContentType value.
6 Enveloped-data Content Type 6. Enveloped-data Content Type
The enveloped-data content type consists of an encrypted content of The enveloped-data content type consists of an encrypted content of
any type and encrypted content-encryption keys for one or more any type and encrypted content-encryption keys for one or more
recipients. The combination of the encrypted content and one recipients. The combination of the encrypted content and one
encrypted content-encryption key for a recipient is a "digital encrypted content-encryption key for a recipient is a "digital
envelope" for that recipient. Any type of content can be enveloped envelope" for that recipient. Any type of content can be enveloped
for an arbitrary number of recipients using any of the three key for an arbitrary number of recipients using any of the three key
management techniques for each recipient. management techniques for each recipient.
The typical application of the enveloped-data content type will The typical application of the enveloped-data content type will
skipping to change at page 17, line 16 skipping to change at page 16, line 25
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,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes 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 SIZE (1..MAX) OF RecipientInfo RecipientInfos ::= SET SIZE (1..MAX) 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
skipping to change at page 19, line 28 skipping to change at page 18, line 28
The recipientInfos field comes before the encryptedContentInfo field The recipientInfos field comes before the encryptedContentInfo field
so that an EnvelopedData value may be processed in a single pass. so that an EnvelopedData value may be processed in a single pass.
6.2 RecipientInfo Type 6.2 RecipientInfo Type
Per-recipient information is represented in the type RecipientInfo. Per-recipient information is represented in the type RecipientInfo.
RecipientInfo has a different format for each of the supported key RecipientInfo has a different format for each of the supported key
management techniques. Any of the key management techniques can be management techniques. Any of the key management techniques can be
used for each recipient of the same encrypted content. In all cases, used for each recipient of the same encrypted content. In all cases,
the content-encryption key is transferred to one or more recipient in the encrypted content-encryption key is transferred to one or more
encrypted form. recipients.
Since all implementations will not support every possible key Since all implementations will not support every possible key
management algorithm, all implementations MUST gracefully handle management algorithm, all implementations MUST gracefully handle
unimplemented algorithms when they are encountered. For example, if unimplemented algorithms when they are encountered. For example, if
a recipient receives a content-encryption key encrypted in their RSA a recipient receives a content-encryption key encrypted in their RSA
public key using RSA-OAEP and the implementation only supports RSA public key using RSA-OAEP and the implementation only supports RSA
PKCS #1 v1.5, then a graceful failure must be implemented. PKCS #1 v1.5, then a graceful failure must be implemented.
Implementations MUST support key transport, key agreement, and Implementations MUST support key transport, key agreement, and
previously distributed symmetric key-encryption keys, as represented previously distributed symmetric key-encryption keys, as represented
skipping to change at page 26, line 10 skipping to change at page 25, line 13
k k ... k k -- if lth mod k = 0 k k ... k k -- if lth mod k = 0
The padding can be removed unambiguously since all input is padded, The padding can be removed unambiguously since all input is padded,
including input values that are already a multiple of the block size, including input values that are already a multiple of the block size,
and no padding string is a suffix of another. This padding method is and no padding string is a suffix of another. This padding method is
well defined if and only if k is less than 256. well defined if and only if k is less than 256.
6.4 Key-encryption Process 6.4 Key-encryption Process
The input to the key-encryption process -- the value supplied to the The input to the key-encryption process -- the value supplied to the
recipient's key-encryption algorithm --is just the "value" of the recipient's key-encryption algorithm -- is just the "value" of the
content-encryption key. content-encryption key.
Any of the aforementioned key management techniques can be used for Any of the aforementioned key management techniques can be used for
each recipient of the same encrypted content. each recipient of the same encrypted content.
7 Digested-data Content Type 7. Digested-data Content Type
The digested-data content type consists of content of any type and a The digested-data content type consists of content of any type and a
message digest of the content. message digest of the content.
Typically, the digested-data content type is used to provide content Typically, the digested-data content type is used to provide content
integrity, and the result generally becomes an input to the integrity, and the result generally becomes an input to the
enveloped-data content type. enveloped-data content type.
The following steps construct digested-data: The following steps construct digested-data:
skipping to change at page 27, line 26 skipping to change at page 26, line 36
encapContentInfo is the content that is digested, as defined in encapContentInfo is the content that is digested, as defined in
section 5.2. section 5.2.
digest is the result of the message-digesting process. digest is the result of the message-digesting process.
The ordering of the digestAlgorithm field, the encapContentInfo The ordering of the digestAlgorithm field, the encapContentInfo
field, and the digest field makes it possible to process a field, and the digest field makes it possible to process a
DigestedData value in a single pass. DigestedData value in a single pass.
8 Encrypted-data Content Type 8. Encrypted-data Content Type
The encrypted-data content type consists of encrypted content of any The encrypted-data content type consists of encrypted content of any
type. Unlike the enveloped-data content type, the encrypted-data type. Unlike the enveloped-data content type, the encrypted-data
content type has neither recipients nor encrypted content-encryption content type has neither recipients nor encrypted content-encryption
keys. Keys MUST be managed by other means. keys. Keys MUST be managed by other means.
The typical application of the encrypted-data content type will be to The typical application of the encrypted-data content type will be to
encrypt the content of the data content type for local storage, encrypt the content of the data content type for local storage,
perhaps where the encryption key is derived from a password. perhaps where the encryption key is derived from a password.
skipping to change at page 28, line 18 skipping to change at page 27, line 25
present, then version MUST be 2. If unprotectedAttrs is absent, present, then version MUST be 2. If unprotectedAttrs is absent,
then version MUST be 0. then version MUST 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.
unprotectedAttrs 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 verify the integrity of the content. Any type of recipient to verify the integrity of the content. Any type of
content can be integrity protected for an arbitrary number of content can be integrity protected for an arbitrary number of
recipients. recipients.
The process by which authenticated-data is constructed involves the The process by which authenticated-data is constructed involves the
skipping to change at page 32, line 23 skipping to change at page 31, line 31
value calculated by the recipient MUST be the same as the value of value calculated by the recipient MUST be the same as the value of
the mac field. Similarly, for authentication to succeed when the the mac field. Similarly, for authentication to succeed when the
authAttrs field is present, the content message digest value authAttrs field is present, the content message digest value
calculated by the recipient MUST be the same as the message digest calculated by the recipient MUST be the same as the message digest
value included in the authAttrs message-digest attribute. value included in the authAttrs message-digest attribute.
If the AuthenticatedData includes authAttrs, then the content-type If the AuthenticatedData includes authAttrs, then the content-type
attribute value MUST match the AuthenticatedData encapContentInfo attribute value MUST match the AuthenticatedData encapContentInfo
eContentType value. eContentType value.
10 Useful Types 10. Useful Types
This section is divided into two parts. The first part defines This section is divided into two parts. The first part defines
algorithm identifiers, and the second part defines other useful algorithm identifiers, and the second part defines other useful
types. types.
10.1 Algorithm Identifier Types 10.1 Algorithm Identifier Types
All of the algorithm identifiers have the same type: All of the algorithm identifiers have the same type:
AlgorithmIdentifier. The definition of AlgorithmIdentifier is taken AlgorithmIdentifier. The definition of AlgorithmIdentifier is taken
from X.509 [X.509-88]. from X.509 [X.509-88].
skipping to change at page 35, line 15 skipping to change at page 34, line 28
Certificate Profile for Authorization" [ACPROFILE]. Certificate Profile for Authorization" [ACPROFILE].
The definition of Certificate is taken from X.509. The definition of Certificate is taken from X.509.
The definitions of AttributeCertificate are taken from X.509-1997 and The definitions of AttributeCertificate are taken from X.509-1997 and
X.509-2000. The definition from X.509-1997 is assigned to X.509-2000. The definition from X.509-1997 is assigned to
AttributeCertificateV1 (see section 12.2), and the definition from AttributeCertificateV1 (see section 12.2), and the definition from
X.509-2000 is assigned to AttributeCertificateV2. X.509-2000 is assigned to AttributeCertificateV2.
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
certificate Certificate, certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2 } v2AttrCert [2] IMPLICIT AttributeCertificateV2 }
10.2.3 CertificateSet 10.2.3 CertificateSet
The CertificateSet type provides a set of certificates. It is The CertificateSet type provides a set of certificates. It is
intended that the set be sufficient to contain chains from a intended that the set be sufficient to contain chains from a
recognized "root" or "top-level certification authority" to all of recognized "root" or "top-level certification authority" to all of
the sender certificates with which the set is associated. However, the sender certificates with which the set is associated. However,
there may be more certificates than necessary, or there MAY be fewer there may be more certificates than necessary, or there MAY be fewer
than necessary. than necessary.
skipping to change at page 36, line 34 skipping to change at page 36, line 5
The OtherKeyAttribute type gives a syntax for the inclusion of other The OtherKeyAttribute type gives a syntax for the inclusion of other
key attributes that permit the recipient to select the key used by key attributes that permit the recipient to select the key used by
the sender. The attribute object identifier must be registered along the sender. The attribute object identifier must be registered along
with the syntax of the attribute itself. Use of this structure with the syntax of the attribute itself. Use of this structure
should be avoided since it might impede interoperability. should be avoided since it might impede interoperability.
OtherKeyAttribute ::= SEQUENCE { OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER, keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL } keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
11 Useful Attributes 11. Useful Attributes
This section defines attributes that may be used with signed-data, This section defines attributes that may be used with signed-data,
enveloped-data, encrypted-data, or authenticated-data. The syntax of enveloped-data, encrypted-data, or authenticated-data. The syntax of
Attribute is compatible with X.501 [X.501-88] and RFC 3280 [PROFILE]. Attribute is compatible with X.501 [X.501-88] and RFC 3280 [PROFILE].
Some of the attributes defined in this section were originally Some of the attributes defined in this section were originally
defined in PKCS #9 [PKCS#9]; others were originally defined in a defined in PKCS #9 [PKCS#9]; others were originally defined in a
previous version of this specification [OLDCMS]. The attributes are previous version of this specification [OLDCMS]. The attributes are
not listed in any particular order. not listed in any particular order.
Additional attributes are defined in many places, notably the S/MIME Additional attributes are defined in many places, notably the S/MIME
skipping to change at page 40, line 34 skipping to change at page 40, line 14
A countersignature attribute can have multiple attribute values. The A countersignature attribute can have multiple attribute values. The
syntax is defined as a SET OF AttributeValue, and there MUST be one syntax is defined as a SET OF AttributeValue, and there MUST be one
or more instances of AttributeValue present. or more instances of AttributeValue present.
The UnsignedAttributes syntax is defined as a SET OF Attributes. The The UnsignedAttributes syntax is defined as a SET OF Attributes. The
UnsignedAttributes in a signerInfo may include multiple instances of UnsignedAttributes in a signerInfo may include multiple instances of
the countersignature attribute. the countersignature attribute.
A countersignature, since it has type SignerInfo, can itself contain A countersignature, since it has type SignerInfo, can itself contain
a countersignature attribute. Thus, it is possible to construct a countersignature attribute. Thus, it is possible to construct an
arbitrarily long series of countersignatures. arbitrarily long series of countersignatures.
12 ASN.1 Modules 12. ASN.1 Modules
Section 12.1 contains the ASN.1 module for the CMS, and section 12.2 Section 12.1 contains the ASN.1 module for the CMS, and section 12.2
contains the ASN.1 module for the Version 1 Attribute Certificate. contains the ASN.1 module for the Version 1 Attribute Certificate.
12.1 CMS ASN.1 Module 12.1 CMS 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-2001(14) } pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
-- The types and values defined in this module are exported for use in -- The types and values defined in this module are exported for use
-- the other ASN.1 modules. Other applications may use them for their -- in the other ASN.1 modules. Other applications may use them for
-- own purposes. -- their own purposes.
IMPORTS IMPORTS
-- Imports from RFC 3280 [PROFILE], Appendix A.1 -- Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier, Certificate, CertificateList, AlgorithmIdentifier, Certificate, CertificateList,
CertificateSerialNumber, Name CertificateSerialNumber, Name
FROM PKIX1Explicit88 { iso(1) FROM PKIX1Explicit88 { iso(1)
identified-organization(3) dod(6) internet(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0) security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) } pkix1-explicit(18) }
-- Imports from RFC <TBD> [ACPROFILE], Appendix B -- Imports from RFC 3281 [ACPROFILE], Appendix B
AttributeCertificate AttributeCertificate
FROM PKIXAttributeCertificate { iso(1) FROM PKIXAttributeCertificate { iso(1)
identified-organization(3) dod(6) internet(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0) security(5) mechanisms(5) pkix(7) mod(0)
attribute-cert(12) } attribute-cert(12) }
-- Imports from Appendix B of this document -- Imports from Appendix B of this document
AttributeCertificateV1 AttributeCertificateV1
FROM AttributeCertificateVersion1 { iso(1) member-body(2) FROM AttributeCertificateVersion1 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
skipping to change at page 48, line 5 skipping to change at page 47, line 12
security(5) mechanisms(5) pkix(7) mod(0) security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) } pkix1-explicit(18) }
-- Imports from RFC 3280 [PROFILE], Appendix A.2 -- Imports from RFC 3280 [PROFILE], Appendix A.2
GeneralNames GeneralNames
FROM PKIX1Implicit88 { iso(1) FROM PKIX1Implicit88 { iso(1)
identified-organization(3) dod(6) internet(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0) security(5) mechanisms(5) pkix(7) mod(0)
pkix1-implicit(19) } pkix1-implicit(19) }
-- Imports from RFC <TBD> [ACPROFILE], Appendix B -- Imports from RFC 3281 [ACPROFILE], Appendix B
AttCertValidityPeriod, IssuerSerial AttCertValidityPeriod, IssuerSerial
FROM PKIXAttributeCertificate { iso(1) FROM PKIXAttributeCertificate { iso(1)
identified-organization(3) dod(6) internet(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0) security(5) mechanisms(5) pkix(7) mod(0)
attribute-cert(12) } ; attribute-cert(12) } ;
-- Definition extracted from X.509-1997 [X.509-97], but -- Definition extracted from X.509-1997 [X.509-97], but
-- different type names are used to avoid collisions. -- different type names are used to avoid collisions.
AttributeCertificateV1 ::= SEQUENCE { AttributeCertificateV1 ::= SEQUENCE {
skipping to change at page 48, line 39 skipping to change at page 48, line 5
serialNumber CertificateSerialNumber, serialNumber CertificateSerialNumber,
attCertValidityPeriod AttCertValidityPeriod, attCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute, attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL, issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL } extensions Extensions OPTIONAL }
AttCertVersionV1 ::= INTEGER { v1(0) } AttCertVersionV1 ::= INTEGER { v1(0) }
END -- of AttributeCertificateVersion1 END -- of AttributeCertificateVersion1
13 References 13. References
ACPROFILE Farrell, S., and R. Housley. An Internet Attribute [ACPROFILE] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization. RFC <TBD>. <Date>. Certificate Profile for Authorization", RFC 3281, April
{draft-ietf-pkix-ac509prof-*.txt} 2002.
CMSALG Housley, R. Cryptographic Message Syntax (CMS) Algorithms. [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
RFC <TBD>. <Date>. {draft-ietf-smime-cmsalg-*.txt} Algorithms", RFC 3269, August 2002.
DSS National Institute of Standards and Technology. [DSS] National Institute of Standards and Technology. FIPS Pub
FIPS Pub 186: Digital Signature Standard. 19 May 1994. 186: Digital Signature Standard. 19 May 1994.
ESS Hoffman, P. Enhanced Security Services for S/MIME. [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC
RFC 2634. June 1999. 2634, June 1999.
MSG Ramsdell, B. S/MIME Version 3 Message Specification. [MSG] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633. June 1999. RFC 2633, June 1999.
OLDCMS Housley, R., Cryptographic Message Syntax, RFC 2630, [OLDCMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999. June 1999.
OLDMSG Dusse, S., P. Hoffman, B. Ramsdell, L. Lundblade, and [OLDMSG] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and
L. Repka. S/MIME Version 2 Message Specification. L. Repka, "S/MIME Version 2 Message Specification", RFC
RFC 2311. March 1998. 2311, March 1998.
PROFILE Housley, R., W. Polk, W. Ford, and D. Solo. Internet [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and CRL X.509 Public Key Infrastructure: Certificate and CRL
Profile. RFC 3280. April 2002. Profile", RFC 3280, April 2002.
PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax [PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax
Standard, Version 1.5. November 1993. Standard, Version 1.5. November 1993.
PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, [PKCS#7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax,
Version 1.5. RFC 2315. March 1998. Version 1.5.", RFC 2315, March 1998.
PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, [PKCS#9] RSA Laboratories. PKCS #9: Selected Attribute Types,
Version 1.1. November 1993. Version 1.1. November 1993.
PWRI Gutmann, P. Password-based Encryption for S/MIME. [PWRI] Gutmann, P., "Password-based Encryption for S/MIME", RFC
RFC 3211. December 2001. 3211, December 2001.
RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security. RFC 1750. December 1994. Recommendations for Security", RFC 1750, December 1994.
STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels. RFC2119. March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
X.208-88 CCITT. Recommendation X.208: Specification of Abstract [X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding [X.209-88] CCITT. Recommendation X.209: Specification of Basic
Rules for Abstract Syntax Notation One (ASN.1). 1988. Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988.
X.501-88 CCITT. Recommendation X.501: The Directory - Models. 1988. [X.501-88] CCITT. Recommendation X.501: The Directory - Models.
1988.
X.509-88 CCITT. Recommendation X.509: The Directory - Authentication [X.509-88] CCITT. Recommendation X.509: The Directory -
Framework. 1988. Authentication Framework. 1988.
X.509-97 ITU-T. Recommendation X.509: The Directory - Authentication [X.509-97] ITU-T. Recommendation X.509: The Directory -
Framework. 1997. Authentication Framework. 1997.
X.509-00 ITU-T. Recommendation X.509: The Directory - Authentication [X.509-00] ITU-T. Recommendation X.509: The Directory -
Framework. 2000. Authentication Framework. 2000.
14 Security Considerations 14. Security Considerations
The Cryptographic Message Syntax provides a method for digitally The Cryptographic Message Syntax provides a method for digitally
signing data, digesting data, encrypting data, and authenticating signing data, digesting data, encrypting data, and authenticating
data. data.
Implementations must protect the signer's private key. Compromise of Implementations must protect the signer's private key. Compromise of
the signer's private key permits masquerade. the signer's private key permits masquerade.
Implementations must protect the key management private key, the key- Implementations must protect the key management private key, the
encryption key, and the content-encryption key. Compromise of the key-encryption key, and the content-encryption key. Compromise of
key management private key or the key-encryption key may result in the key management private key or the key-encryption key may result
the disclosure of all contents protected with that key. Similarly, in the disclosure of all contents protected with that key.
compromise of the content-encryption key may result in disclosure of Similarly, compromise of the content-encryption key may result in
the associated encrypted content. disclosure of the associated encrypted content.
Implementations must protect the key management private key and the Implementations must protect the key management private key and the
message-authentication key. Compromise of the key management private message-authentication key. Compromise of the key management private
key permits masquerade of authenticated data. Similarly, compromise key permits masquerade of authenticated data. Similarly, compromise
of the message-authentication key may result in undetectable of the message-authentication key may result in undetectable
modification of the authenticated content. modification of the authenticated content.
The key management technique employed to distribute message- The key management technique employed to distribute message-
authentication keys must itself provide data origin authentication, authentication keys must itself provide data origin authentication,
otherwise the contents are delivered with integrity from an unknown otherwise the contents are delivered with integrity from an unknown
source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie- source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static
Hellman [DH-X9.42] provide the necessary data origin authentication. Diffie-Hellman [DH-X9.42] provide the necessary data origin
Static-Static Diffie-Hellman [DH-X9.42] does provide the necessary authentication. Static-Static Diffie-Hellman [DH-X9.42] does provide
data origin authentication when both the originator and recipient the necessary data origin authentication when both the originator and
public keys are bound to appropriate identities in X.509 recipient public keys are bound to appropriate identities in X.509
certificates. certificates.
When more than two parties share the same message-authentication key, When more than two parties share the same message-authentication key,
data origin authentication is not provided. Any party that knows the data origin authentication is not provided. Any party that knows the
message-authentication key can compute a valid MAC, therefore the message-authentication key can compute a valid MAC, therefore the
contents could originate from any one of the parties. contents could originate from any one of the parties.
Implementations must randomly generate content-encryption keys, Implementations must randomly generate content-encryption keys,
message-authentication keys, initialization vectors (IVs), and message-authentication keys, initialization vectors (IVs), and
padding. Also, the generation of public/private key pairs relies on padding. Also, the generation of public/private key pairs relies on
skipping to change at page 51, line 17 skipping to change at page 50, line 31
searching the whole key space. The generation of quality random searching the whole key space. The generation of quality random
numbers is difficult. RFC 1750 [RANDOM] offers important guidance in numbers is difficult. RFC 1750 [RANDOM] offers important guidance in
this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality
PRNG technique. PRNG technique.
When using key agreement algorithms or previously distributed When using key agreement algorithms or previously distributed
symmetric key-encryption keys, a key-encryption key is used to symmetric key-encryption keys, a key-encryption key is used to
encrypt the content-encryption key. If the key-encryption and encrypt the content-encryption key. If the key-encryption and
content-encryption algorithms are different, the effective security content-encryption algorithms are different, the effective security
is determined by the weaker of the two algorithms. If, for example, is determined by the weaker of the two algorithms. If, for example,
content is encrypted with 168-bit Triple-DES and the Triple-DES content is encrypted with Triple-DES using a 168-bit Triple-DES
content-encryption key is wrapped with a 40-bit RC2 key, then at most content-encryption key, and the content-encryption key is wrapped
40 bits of protection is provided. A trivial search to determine the with RC2 using a 40-bit RC2 key-encryption key, then at most 40 bits
value of the 40-bit RC2 key can recover Triple-DES key, and then the of protection is provided. A trivial search to determine the value
of the 40-bit RC2 key can recover the Triple-DES key, and then the
Triple-DES key can be used to decrypt the content. Therefore, Triple-DES key can be used to decrypt the content. Therefore,
implementers must ensure that key-encryption algorithms are as strong implementers must ensure that key-encryption algorithms are as strong
or stronger than content-encryption algorithms. or stronger than content-encryption algorithms.
Implementers should be aware that cryptographic algorithms become Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptoanalysis techniques are developed and weaker with time. As new cryptoanalysis techniques are developed and
computing performance improves, the work factor to break a particular computing performance improves, the work factor to break a particular
cryptographic algorithm will reduce. Therefore, cryptographic cryptographic algorithm will be reduced. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms algorithm implementations should be modular, allowing new algorithms
to be readily inserted. That is, implementers should be prepared for to be readily inserted. That is, implementors should be prepared for
the set of mandatory to implement algorithms to change over time. the set of algorithms that must be supported to change over time.
The countersignature unsigned attribute includes a digital signature The countersignature unsigned attribute includes a digital signature
that is computed on the content signature value, thus the 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 verify the original signature value countersignatures should either verify the original signature value
prior to countersigning it (this verification requires processing of prior to countersigning it (this verification 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.
15 Acknowledgments 15. Acknowledgments
This document is the result of contributions from many professionals. This document is the result of contributions from many professionals.
I appreciate the hard work of all members of the IETF S/MIME Working I appreciate the hard work of all members of the IETF S/MIME Working
Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson,
Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman,
Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt
Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau,
Jim Schaad, and Dave Solo for their efforts and support. Jim Schaad, and Dave Solo for their efforts and support.
16 Author Address 16. Authors' Address
Russell Housley Russell Housley
RSA Laboratories RSA Laboratories
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
EMail: rhousley@rsasecurity.com
rhousley@rsasecurity.com 17. Full Copyright Statement
17 Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. In addition, the included on all such copies and derivative works. However, this
ASN.1 module presented in Appendix A may be used in whole or in part document itself may not be modified in any way, such as by removing
without inclusion of the copyright notice. However, this document the copyright notice or references to the Internet Society or other
itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process shall be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This revoked by the Internet Society or its successors or assigns.
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK This document and the information contained herein is provided on an
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
OR FITNESS FOR A PARTICULAR PURPOSE. HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 66 change blocks. 
205 lines changed or deleted 192 lines changed or added

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