draft-ietf-smime-rfc2630bis-00.txt   draft-ietf-smime-rfc2630bis-01.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet Draft RSA Laboratories Internet Draft RSA Laboratories
expires in six months April 2001 expires in six months June 2001
Cryptographic Message Syntax Cryptographic Message Syntax
<draft-ietf-smime-rfc2630bis-00.txt> <draft-ietf-smime-rfc2630bis-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. 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
skipping to change at page 2, line 8 skipping to change at page 2, line 8
discussion of specific cryptographic algorithms has been moved to a discussion of specific cryptographic algorithms has been moved to a
separate document. Separation of the protocol and algorithm separate document. Separation of the protocol and algorithm
specifications allows the IETF to select different mandatory to specifications allows the IETF to select different mandatory to
implement algorithms in the future without reissuing this protocol implement algorithms in the future without reissuing this protocol
document. However, implementations of the CMS MUST support the document. However, implementations of the CMS MUST support the
mandatory to implement algorithms specified in [CMSALG], or its mandatory to implement algorithms specified in [CMSALG], or its
successor. successor.
Look for [*** NEW ***]. This string is used to identify text that is Look for [*** NEW ***]. This string is used to identify text that is
significantly different than RFC 2630. Editorial changes were made significantly different than RFC 2630. Editorial changes were made
that are not flagged with this string. that are not flagged with this string. Also, the final page of this
document contains a change history.
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 Table of Contents
Status of this Memo .................................................. 1 Status of this Memo ................................................ 1
Abstract ............................................................. 1 Abstract ........................................................... 1
Table of Contents .................................................... 3 Table of Contents .................................................. 3
1 Introduction ..................................................... 5 1 Introduction ................................................... 5
2 General Overview ................................................. 5 2 General Overview ............................................... 5
3 General Syntax ................................................... 6 3 General Syntax ................................................. 6
4 Data Content Type ................................................ 6 4 Data Content Type .............................................. 6
5 Signed-data Content Type ......................................... 7 5 Signed-data Content Type ....................................... 7
5.1 SignedData Type ............................................. 8 5.1 SignedData Type ........................................... 8
5.2 EncapsulatedContentInfo Type ................................ 9 5.2 EncapsulatedContentInfo Type .............................. 9
5.3 SignerInfo Type ............................................. 10 5.3 SignerInfo Type ........................................... 10
5.4 Message Digest Calculation Process .......................... 12 5.4 Message Digest Calculation Process ........................ 12
5.5 Message Signature Generation Process ........................ 13 5.5 Message Signature Generation Process ...................... 13
5.6 Message Signature Verification Process ...................... 13 5.6 Message Signature Verification Process .................... 13
6 Enveloped-data Content Type ...................................... 14 6 Enveloped-data Content Type .................................... 14
6.1 EnvelopedData Type .......................................... 15 6.1 EnvelopedData Type ........................................ 15
6.2 RecipientInfo Type .......................................... 17 6.2 RecipientInfo Type ........................................ 17
6.2.1 KeyTransRecipientInfo Type ........................... 17 6.2.1 KeyTransRecipientInfo Type ......................... 18
6.2.2 KeyAgreeRecipientInfo Type ........................... 18 6.2.2 KeyAgreeRecipientInfo Type ......................... 19
6.2.3 KEKRecipientInfo Type ................................ 20 6.2.3 KEKRecipientInfo Type .............................. 21
6.3 Content-encryption Process .................................. 21 6.2.4 PasswordRecipientInfo Type ......................... 22
6.4 Key-encryption Process ...................................... 22 6.2.5 OtherRecipientInfo Type ............................ 22
7 Digested-data Content Type ....................................... 22 6.3 Content-encryption Process ................................ 23
8 Encrypted-data Content Type ...................................... 24 6.4 Key-encryption Process .................................... 23
9 Authenticated-data Content Type .................................. 24 7 Digested-data Content Type ..................................... 24
9.1 AuthenticatedData Type ...................................... 25 8 Encrypted-data Content Type .................................... 25
9.2 MAC Generation .............................................. 27 9 Authenticated-data Content Type ................................ 26
9.3 MAC Verification ............................................ 28 9.1 AuthenticatedData Type .................................... 26
10 Useful Types ..................................................... 28 9.2 MAC Generation ............................................ 28
10.1 Algorithm Identifier Types ................................. 28 9.3 MAC Verification .......................................... 29
10.1.1 DigestAlgorithmIdentifier .......................... 29 10 Useful Types ................................................... 30
10.1.2 SignatureAlgorithmIdentifier ....................... 29 10.1 Algorithm Identifier Types ............................... 30
10.1.3 KeyEncryptionAlgorithmIdentifier ................... 29 10.1.1 DigestAlgorithmIdentifier ........................ 30
10.1.4 ContentEncryptionAlgorithmIdentifier ............... 29 10.1.2 SignatureAlgorithmIdentifier ..................... 30
10.1.5 MessageAuthenticationCodeAlgorithm ................. 30 10.1.3 KeyEncryptionAlgorithmIdentifier ................. 30
10.2 Other Useful Types ......................................... 30 10.1.4 ContentEncryptionAlgorithmIdentifier ............. 31
10.2.1 CertificateRevocationLists ......................... 30 10.1.5 MessageAuthenticationCodeAlgorithm ............... 31
10.2.2 CertificateChoices ................................. 30 10.1.6 KeyDerivationAlgorithmIdentifier ................. 31
10.2.3 CertificateSet ..................................... 31 10.2 Other Useful Types ....................................... 31
10.2.4 IssuerAndSerialNumber .............................. 31 10.2.1 CertificateRevocationLists ....................... 31
10.2.5 CMSVersion ......................................... 32 10.2.2 CertificateChoices ............................... 32
10.2.6 UserKeyingMaterial ................................. 32 10.2.3 CertificateSet ................................... 32
10.2.7 OtherKeyAttribute .................................. 32 10.2.4 IssuerAndSerialNumber ............................ 33
11 Useful Attributes ................................................ 32 10.2.5 CMSVersion ....................................... 33
11.1 Content Type ............................................... 33 10.2.6 UserKeyingMaterial ............................... 33
11.2 Message Digest ............................................. 33 10.2.7 OtherKeyAttribute ................................ 34
11.3 Signing Time ............................................... 34 11 Useful Attributes .............................................. 34
11.4 Countersignature ........................................... 35 11.1 Content Type ............................................. 34
Appendix A: CMS ASN.1 Module ........................................ 37 11.2 Message Digest ........................................... 35
Appendix B: Version 1 Attribute Certificate ASN.1 Module 43 11.3 Signing Time ............................................. 36
References ........................................................... 44 11.4 Countersignature ......................................... 37
Security Considerations .............................................. 46 Appendix A: CMS ASN.1 Module ...................................... 39
Acknowledgments ...................................................... 48 Appendix B: Version 1 Attribute Certificate ASN.1 Module .......... 46
Author Address ....................................................... 49 References ......................................................... 47
Full Copyright Statement ............................................. 49 Security Considerations ............................................ 49
Acknowledgments .................................................... 51
Author Address ..................................................... 52
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 messages. arbitrary messages.
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
skipping to change at page 14, line 26 skipping to change at page 14, line 26
represent one or more recipients' digital envelopes on content of the represent one or more recipients' digital envelopes on content of the
data or signed-data content types. data or signed-data content types.
Enveloped-data is constructed by the following steps: Enveloped-data is constructed by the following steps:
1. A content-encryption key for a particular content-encryption 1. A content-encryption key for a particular content-encryption
algorithm is generated at random. algorithm is generated at random.
2. The content-encryption key is encrypted for each recipient. 2. The content-encryption key is encrypted for each recipient.
The details of this encryption depend on the key management The details of this encryption depend on the key management
algorithm used, but three general techniques are supported: algorithm used, but four general techniques are supported:
key transport: the content-encryption key is encrypted in the key transport: the content-encryption key is encrypted in the
recipient's public key; recipient's public key;
key agreement: the recipient's public key and the sender's key agreement: the recipient's public key and the sender's
private key are used to generate a pairwise symmetric key, then private key are used to generate a pairwise symmetric key, then
the content-encryption key is encrypted in the pairwise the content-encryption key is encrypted in the pairwise
symmetric key; and symmetric key;
symmetric key-encryption keys: the content-encryption key is symmetric key-encryption keys: the content-encryption key is
encrypted in a previously distributed symmetric key-encryption encrypted in a previously distributed symmetric key-encryption
key. key; and
passwords: the content-encryption key is encrypted in a key-
encryption key that is derived from a password or other shared
secret value.
3. For each recipient, the encrypted content-encryption key and 3. For each recipient, the encrypted content-encryption key and
other recipient-specific information are collected into a other recipient-specific information are collected into a
RecipientInfo value, defined in Section 6.2. RecipientInfo value, defined in Section 6.2.
4. The content is encrypted with the content-encryption key. 4. The content is encrypted with the content-encryption key.
Content encryption may require that the content be padded to a Content encryption may require that the content be padded to a
multiple of some block size; see Section 6.3. multiple of some block size; see Section 6.3.
5. The RecipientInfo values for all the recipients are collected 5. The RecipientInfo values for all the recipients are collected
skipping to change at page 17, line 14 skipping to change at page 17, line 18
encryptedContent is the result of encrypting the content. The encryptedContent is the result of encrypting the content. The
field is optional, and if the field is not present, its intended field is optional, and if the field is not present, its intended
value MUST be supplied by other means. value MUST be supplied by other means.
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. [*** NEW ***] Per-recipient information is represented in the type
RecipientInfo has a different format for the three supported key RecipientInfo. RecipientInfo has a different format for each of the
management techniques: key transport, key agreement, and previously supported key management techniques. Any of the key management
distributed symmetric key-encryption keys. Any of the three key techniques can be used for each recipient of the same encrypted
management techniques can be used for each recipient of the same content. In all cases, the content-encryption key is transferred to
encrypted content. In all cases, the content-encryption key is one or more recipient in encrypted form.
transferred to one or more recipient in encrypted form.
[*** NEW ***] All implementations MUST support the mandatory to [*** NEW ***] All implementations MUST support the mandatory to
implement key management algorithms are specified in [CMSALG], or its implement key management algorithms are specified in [CMSALG], or its
successor. Use of a companion document enables the IETF to change successor. Use of a companion document enables the IETF to change
the mandatory to implement algorithms without updating this protocol the mandatory to implement algorithms without updating this protocol
specification. Since the companion algorithm specification will specification. Since the companion algorithm specification will
undoubtedly change and implementation updates will certainly take undoubtedly change and implementation updates will certainly take
time, all implementations MUST gracefully handle unimplemented time, all implementations MUST gracefully handle unimplemented
algorithms when they are encountered. algorithms when they are encountered.
[*** NEW ***] Implementations MUST support all three key management [*** NEW ***] Implementations MUST support key transport, key
techniques represented by ktri, kari, and kekri. Since each agreement, and previously distributed symmetric key-encryption keys,
recipient can employ a different key management technique and future as represented by ktri, kari, and kekri, respectively.
specifications could define additional key management techniques, all Implementations MAY support the password-based key management as
implementations MUST gracefully handle unimplemented (and as yet represented by pwri. Implementations MAY support any other key
unspecified) additions to the RecipientInfo CHOICE. Such additions management technique as represented by ori. Since each recipient can
will have their own tag, permitting unimplemented RecipientInfo employ a different key management technique and future specifications
CHOICE alternatives to be ignored while correctly processing the could define additional key management techniques, all
others. implementations MUST gracefully handle unimplemented alternatives
within the RecipientInfo CHOICE, and all implementations MUST
gracefully handle unimplemented or unknown ori alternatives.
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo } kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo }
EncryptedKey ::= OCTET STRING EncryptedKey ::= OCTET STRING
6.2.1 KeyTransRecipientInfo Type 6.2.1 KeyTransRecipientInfo Type
Per-recipient information using key transport is represented in the Per-recipient information using key transport is represented in the
type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo
transfers the content-encryption key to one recipient. transfers the content-encryption key to one recipient.
KeyTransRecipientInfo ::= SEQUENCE { KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2 version CMSVersion, -- always set to 0 or 2
skipping to change at page 22, line 5 skipping to change at page 22, line 9
keyIdentifier identifies the key-encryption key that was keyIdentifier identifies the key-encryption key that was
previously distributed to the sender and one or more recipients. previously distributed to the sender and one or more recipients.
date is optional. When present, the date specifies a single key- date is optional. When present, the date specifies a single key-
encryption key from a set that was previously distributed. encryption key from a set that was previously distributed.
other is optional. When present, this field contains additional other is optional. When present, this field contains additional
information used by the recipient to determine the key-encryption information used by the recipient to determine the key-encryption
key used by the sender. key used by the sender.
6.2.4 [*** NEW ***] PasswordRecipientInfo Type
Recipient information using a password or shared secret value is
represented in the type PasswordRecipientInfo. Each instance of
PasswordRecipientInfo will transfer the content-encryption key to one
or more recipients who posses the password or shared secret value.
The PasswordRecipientInfo Type is specified in RFC <TBD> [PWRI]. The
PasswordRecipientInfo structure is repeated here for completeness.
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
The fields of type PasswordRecipientInfo have the following meanings:
version is the syntax version number. It MUST always be 0.
keyDerivationAlgorithm identifies the key-derivation algorithm,
and any associated parameters, used to derive the key-encryption
key from the password or shared secret value. If this field is
absent, the key-encryption key is supplied from an external
source, for example a hardware crypto token such as a smart card.
keyEncryptionAlgorithm identifies the encryption algorithm, and
any associated parameters, used to encrypt the content-encryption
key with the key-encryption key.
encryptedKey is the result of encrypting the content-encryption
key with the key-encryption key.
6.2.5 [*** NEW ***] OtherRecipientInfo Type
Recipient information for key additional key management techniques
are represented in the type OtherRecipientInfo. The
OtherRecipientInfo type allows key management techniques beyond key
transport, key agreement, previously distributed symmetric key-
encryption keys, and password-based key management to be specified in
future documents. An object identifier MUST uniquely identify such
key management techniques.
OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType }
The fields of type OtherRecipientInfo have the following meanings:
oriType identifies the key management technique.
oriValue contains the protocol data elements needed by a recipient
using the identified key management technique.
6.3 Content-encryption Process 6.3 Content-encryption Process
The content-encryption key for the desired content-encryption The content-encryption key for the desired content-encryption
algorithm is randomly generated. The data to be protected is padded algorithm is randomly generated. The data to be protected is padded
as described below, then the padded data is encrypted using the as described below, then the padded data is encrypted using the
content-encryption key. The encryption operation maps an arbitrary content-encryption key. The encryption operation maps an arbitrary
string of octets (the data) to another string of octets (the string of octets (the data) to another string of octets (the
ciphertext) under control of a content-encryption key. The encrypted ciphertext) under control of a content-encryption key. The encrypted
data is included in the envelopedData encryptedContentInfo data is included in the envelopedData encryptedContentInfo
encryptedContent OCTET STRING. encryptedContent OCTET STRING.
skipping to change at page 30, line 28 skipping to change at page 31, line 34
10.1.5 MessageAuthenticationCodeAlgorithm 10.1.5 MessageAuthenticationCodeAlgorithm
The MessageAuthenticationCodeAlgorithm type identifies a message The MessageAuthenticationCodeAlgorithm type identifies a message
authentication code (MAC) algorithm. Examples include DES-MAC and authentication code (MAC) algorithm. Examples include DES-MAC and
HMAC. A MAC algorithm supports generation and verification HMAC. A MAC algorithm supports generation and verification
operations. The MAC generation and verification operations use the operations. The MAC generation and verification operations use the
same symmetric key. Context determines which operation is intended. same symmetric key. Context determines which operation is intended.
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
10.1.6 [*** NEW ***] KeyDerivationAlgorithmIdentifier
The KeyDerivationAlgorithmIdentifier type is specified in RFC <TBD>
[PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated
here for completeness.
Key derivation algorithms convert a password or shared secret value
into a key-encryption key.
KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier
10.2 Other Useful Types 10.2 Other Useful Types
This section defines types that are used other places in the This section defines types that are used other places in the
document. The types are not listed in any particular order. document. The types are not listed in any particular order.
10.2.1 CertificateRevocationLists 10.2.1 CertificateRevocationLists
The CertificateRevocationLists type gives a set of certificate The CertificateRevocationLists type gives a set of certificate
revocation lists (CRLs). It is intended that the set contain revocation lists (CRLs). It is intended that the set contain
information sufficient to determine whether the certificates and information sufficient to determine whether the certificates and
skipping to change at page 37, line 35 skipping to change at page 39, line 35
FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) FROM InformationFramework { joint-iso-itu-t ds(5) modules(1)
informationFramework(1) 3 } informationFramework(1) 3 }
-- Directory Authentication Framework (X.509-2000) -- Directory Authentication Framework (X.509-2000)
AlgorithmIdentifier, AttributeCertificate, Certificate, AlgorithmIdentifier, AttributeCertificate, Certificate,
CertificateList, CertificateSerialNumber CertificateList, CertificateSerialNumber
FROM AuthenticationFramework { joint-iso-itu-t ds(5) FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 4 } module(1) authenticationFramework(7) 4 }
-- [*** NEW ***] -- [*** NEW ***]
-- Password-based Encryption for S/MIME (RFC <TBD>)
PasswordRecipientInfo
FROM PasswordRecipientInfo { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) pwri(12) }
-- [*** NEW ***]
-- Indirectly from Directory Authentication Framework (X.509-1997) -- Indirectly from Directory Authentication Framework (X.509-1997)
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)
modules(0) v1AttrCert(1) } ; modules(0) v1AttrCert(1) } ;
-- Cryptographic Message Syntax -- Cryptographic Message Syntax
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
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 }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
skipping to change at page 39, line 19 skipping to change at page 41, line 26
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 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
-- [*** OLD ***]
-- RecipientInfo ::= CHOICE {
-- ktri KeyTransRecipientInfo,
-- kari [1] KeyAgreeRecipientInfo,
-- kekri [2] KEKRecipientInfo }
-- [*** NEW ***]
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo } kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo }
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,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE { RecipientIdentifier ::= CHOICE {
skipping to change at page 40, line 32 skipping to change at page 42, line 48
version CMSVersion, -- always set to 4 version CMSVersion, -- always set to 4
kekid KEKIdentifier, kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
KEKIdentifier ::= SEQUENCE { KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING, keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL, date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL } other OtherKeyAttribute OPTIONAL }
-- [*** NEW ***]
OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType }
DigestedData ::= SEQUENCE { DigestedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
digest Digest } digest Digest }
Digest ::= OCTET STRING Digest ::= OCTET STRING
EncryptedData ::= SEQUENCE { EncryptedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
skipping to change at page 45, line 16 skipping to change at page 48, line 16
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.
RFC <TBD>. <DATE>. [draft-ietf-smime-password-*.txt]
RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness
Recommendations for Security. RFC 1750. December 1994. Recommendations for Security. RFC 1750. December 1994.
RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm.
RFC 2268. March 1998. RFC 2268. March 1998.
SHA1 National Institute of Standards and Technology. SHA1 National Institute of Standards and Technology.
FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995.
STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate
skipping to change at line 2213 skipping to change at page 53, line 4
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. This
document and the information contained herein is provided on an "AS document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE. OR FITNESS FOR A PARTICULAR PURPOSE.
Change History
<< This section to be deleted before RFC >>
This section lists major changes since the previous revision.
Changes from -00 to -01:
1. Section 6.2. Revised RecipientInfo structure. Changed MUST implement.
Included Password-based key management and { OID, ANY } alternative for
future key management technique specifications.
2. Section 6.2.4. New discussion of PasswordRecipientInfo.
3. Section 6.2.5. New discussion of OtherRecipientInfo.
4. Section 10.1.6. New discussion of KeyDerivationAlgorithmIdentifier.
5. ASN.1 Module. Updated RecipientInfo. IMPORTed PasswordRecipientInfo.
Added OtherRecipientInfo.
 End of changes. 

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