draft-ietf-smime-rfc2630bis-02.txt   draft-ietf-smime-rfc2630bis-03.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 August 2001 expires in six months August 2001
Cryptographic Message Syntax Cryptographic Message Syntax
<draft-ietf-smime-rfc2630bis-02.txt> <draft-ietf-smime-rfc2630bis-03.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
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
This document describes the Cryptographic Message Syntax (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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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.2.1 Compatibility with PKCS #7 ......................... 10
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 ......................... 18 6.2.1 KeyTransRecipientInfo Type ......................... 18
6.2.2 KeyAgreeRecipientInfo Type ......................... 19 6.2.2 KeyAgreeRecipientInfo Type ......................... 19
6.2.3 KEKRecipientInfo Type .............................. 21 6.2.3 KEKRecipientInfo Type .............................. 21
skipping to change at page 6, line 19 skipping to change at page 6, line 19
various components may not be known in advance. However, signed various components may not be known in advance. However, signed
attributes within the signed-data content type and authenticated attributes within the signed-data content type and authenticated
attributes within the authenticated-data content type need to be attributes within the authenticated-data content type need to be
transmitted in DER form to ensure that recipients can verify a transmitted in DER form to ensure that recipients can verify a
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
type:
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
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
The fields of ContentInfo have the following meanings: The fields of ContentInfo have the following meanings:
skipping to change at page 10, line 32 skipping to change at page 10, line 39
within EncapsulatedContentInfo is absent, then the signatureValue is within EncapsulatedContentInfo is absent, then the signatureValue is
calculated and the eContentType is assigned as though the eContent calculated and the eContentType is assigned as though the eContent
value was present. value was present.
In the degenerate case where there are no signers, the In the degenerate case where there are no signers, the
EncapsulatedContentInfo value being "signed" is irrelevant. In this EncapsulatedContentInfo value being "signed" is irrelevant. In this
case, the content type within the EncapsulatedContentInfo value being case, the content type within the EncapsulatedContentInfo value being
"signed" MUST be id-data (as defined in section 4), and the content "signed" MUST be id-data (as defined in section 4), and the content
field of the EncapsulatedContentInfo value MUST be omitted. field of the EncapsulatedContentInfo value MUST be omitted.
5.2.1 [*** NEW ***] Compatibility with PKCS #7
This section contains a word of warning to implementers that wish to
support both the CMS and PKCS #7 [PKCS#7]. Both the CMS and PKCS #7
identify the type of the encapsulated content with an object
identifier, but the ASN.1 type of the content itself was variable in
PKCS #7. The definition for eContent, in PKCS #7 this was:
content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
In the CMS, the definition for eContent is:
eContent [0] EXPLICIT OCTET STRING OPTIONAL
The newer definition is much easier to use in most applications, and
it is compatible with both S/MIME v2 and S/MIME v3. However, there
are some deployed applications that use the older PKCS #7 definition.
For example, Microsoft AuthentiCode does not sign an OCTET STRING.
To achive backward compatibility with PKCS #7, CMS implementations
MAY examine the value of the eContentType, and then adjust the
expected encoding of eContent based on the object identifier value.
For example, to support Microsoft AuthentiCode, the following
information might be included:
eContentType Object Identifier = { 1 3 6 1 4 1 311 2 1 4 }
eContent Type = SpcIndirectDataContext -- Microsoft code signing
5.3 SignerInfo Type 5.3 SignerInfo Type
Per-signer information is represented in the type SignerInfo: Per-signer information is represented in the type SignerInfo:
SignerInfo ::= SEQUENCE { SignerInfo ::= SEQUENCE {
version CMSVersion, version CMSVersion,
sid SignerIdentifier, sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier, signatureAlgorithm SignatureAlgorithmIdentifier,
skipping to change at page 13, line 14 skipping to change at page 13, line 49
whether the signedAttrs field is present. When the field is absent, whether the signedAttrs field is present. When the field is absent,
the result is just the message digest of the content as described the result is just the message digest of the content as described
above. When the field is present, however, the result is the message above. When the field is present, however, the result is the message
digest of the complete DER encoding of the SignedAttrs value digest of the complete DER encoding of the SignedAttrs value
contained in the signedAttrs field. Since the SignedAttrs value, contained in the signedAttrs field. Since the SignedAttrs value,
when present, must contain the content-type and the message-digest when present, must contain the content-type and the message-digest
attributes, those values are indirectly included in the result. The attributes, those values are indirectly included in the result. The
content-type attribute MUST NOT be included in a countersignature content-type attribute MUST NOT be included in a countersignature
unsigned attribute as defined in section 11.4. A separate encoding unsigned attribute as defined in section 11.4. A separate encoding
of the signedAttrs field is performed for message digest calculation. of the signedAttrs field is performed for message digest calculation.
The IMPLICIT [0] tag in the signedAttributes is not used for the DER The IMPLICIT [0] tag in the signedAttrs is not used for the DER
encoding, rather an EXPLICIT SET OF tag is used. That is, the DER encoding, rather an EXPLICIT SET OF tag is used. That is, the DER
encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0] encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0]
tag, MUST be included in the message digest calculation along with tag, MUST be included in the message digest calculation along with
the length and content octets of the SignedAttributes value. the length and content octets of the SignedAttributes value.
When the signedAttrs field is absent, only the octets comprising the When the signedAttrs field is absent, only the octets comprising the
value of the signedData encapContentInfo eContent OCTET STRING (e.g., value of the signedData encapContentInfo eContent OCTET STRING (e.g.,
the contents of a file) are input to the message digest calculation. the contents of a file) are input to the message digest calculation.
This has the advantage that the length of the content being signed This has the advantage that the length of the content being signed
need not be known in advance of the signature generation process. need not be known in advance of the signature generation process.
skipping to change at page 27, line 50 skipping to change at page 28, line 40
[*** NEW ***] version is the syntax version number. The version [*** NEW ***] version is the syntax version number. The version
MUST be assigned as follows: MUST be assigned as follows:
IF ((originatorInfo is present) AND IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present)) (any version 2 attribute certificates are present))
THEN version is 1 THEN version is 1
ELSE version is 0 ELSE version is 0
originatorInfo optionally provides information about the originatorInfo optionally provides information about the
originator. It is present only if required by the key originator. It is present only if required by the key management
management algorithm. It MAY contain certificates, attribute algorithm. It MAY contain certificates, attribute certificates,
certificates, and CRLs, as defined in Section 6.1. and CRLs, as defined in Section 6.1.
recipientInfos is a collection of per-recipient information, as recipientInfos is a collection of per-recipient information, as
defined in Section 6.1. There MUST be at least one element in defined in Section 6.1. There MUST be at least one element in the
the collection. collection.
macAlgorithm is a message authentication code (MAC) algorithm macAlgorithm is a message authentication code (MAC) algorithm
identifier. It identifies the MAC algorithm, along with any identifier. It identifies the MAC algorithm, along with any
associated parameters, used by the originator. Placement of associated parameters, used by the originator. Placement of the
the macAlgorithm field facilitates one-pass processing by the macAlgorithm field facilitates one-pass processing by the
recipient. recipient.
digestAlgorithm identifies the message digest algorithm, and digestAlgorithm identifies the message digest algorithm, and any
any associated parameters, used to compute a message digest on associated parameters, used to compute a message digest on the
the encapsulated content if authenticated attributes are encapsulated content if authenticated attributes are present. The
present. The message digesting process is described in Section message digesting process is described in Section 9.2. Placement
9.2. Placement of the digestAlgorithm field facilitates one- of the digestAlgorithm field facilitates one-pass processing by
pass processing by the recipient. If the digestAlgorithm field the recipient. If the digestAlgorithm field is present, then the
is present, then the authAttrs field MUST also be present. authAttrs field MUST also be present.
encapContentInfo is the content that is authenticated, as encapContentInfo is the content that is authenticated, as defined
defined in section 5.2. in section 5.2.
authAttrs is a collection of authenticated attributes. The authAttrs is a collection of authenticated attributes. The
authAttrs structure is optional, but it MUST be present if the authAttrs structure is optional, but it MUST be present if the
content type of the EncapsulatedContentInfo value being content type of the EncapsulatedContentInfo value being
authenticated is not id-data. If the authAttrs field is authenticated is not id-data. If the authAttrs field is present,
present, then the digestAlgorithm field MUST also be present. then the digestAlgorithm field MUST also be present. Each
Each attribute in the SET MUST be DER encoded. Useful attribute in the SET MUST be DER encoded. Useful attribute types
attribute types are defined in Section 11. If the authAttrs are defined in Section 11. If the authAttrs field is present, it
field is present, it MUST contain, at a minimum, the following MUST contain, at a minimum, the following two attributes:
two attributes:
A content-type attribute having as its value the content type A content-type attribute having as its value the content type
of the EncapsulatedContentInfo value being authenticated. of the EncapsulatedContentInfo value being authenticated.
Section 11.1 defines the content-type attribute. Section 11.1 defines the content-type attribute.
A message-digest attribute, having as its value the message A message-digest attribute, having as its value the message
digest of the content. Section 11.2 defines the message-digest digest of the content. Section 11.2 defines the message-digest
attribute. attribute.
mac is the message authentication code. mac is the message authentication code.
skipping to change at page 31, line 28 skipping to change at page 32, line 15
10.1.3 KeyEncryptionAlgorithmIdentifier 10.1.3 KeyEncryptionAlgorithmIdentifier
The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption
algorithm used to encrypt a content-encryption key. The encryption algorithm used to encrypt a content-encryption key. The encryption
operation maps an octet string (the key) to another octet string (the operation maps an octet string (the key) to another octet string (the
encrypted key) under control of a key-encryption key. The decryption encrypted key) under control of a key-encryption key. The decryption
operation is the inverse of the encryption operation. Context operation is the inverse of the encryption operation. Context
determines which operation is intended. determines which operation is intended.
The details of encryption and decryption depend on the key management The details of encryption and decryption depend on the key management
algorithm used. Key transport, key agreement, and previously algorithm used. Key transport, key agreement, previously distributed
distributed symmetric key-encrypting keys are supported. symmetric key-encrypting keys, and symmetric key-encrypting keys
derived from passwords are supported.
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
10.1.4 ContentEncryptionAlgorithmIdentifier 10.1.4 ContentEncryptionAlgorithmIdentifier
The ContentEncryptionAlgorithmIdentifier type identifies a content- The ContentEncryptionAlgorithmIdentifier type identifies a content-
encryption algorithm. Examples include Triple-DES and RC2. A encryption algorithm. Examples include Triple-DES and RC2. A
content-encryption algorithm supports encryption and decryption content-encryption algorithm supports encryption and decryption
operations. The encryption operation maps an octet string (the operations. The encryption operation maps an octet string (the
message) to another octet string (the ciphertext) under control of a message) to another octet string (the ciphertext) under control of a
skipping to change at page 32, line 15 skipping to change at page 33, line 4
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
10.1.6 [*** NEW ***] KeyDerivationAlgorithmIdentifier 10.1.6 [*** NEW ***] KeyDerivationAlgorithmIdentifier
The KeyDerivationAlgorithmIdentifier type is specified in RFC <TBD> The KeyDerivationAlgorithmIdentifier type is specified in RFC <TBD>
[PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated [PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated
here for completeness. here for completeness.
Key derivation algorithms convert a password or shared secret value Key derivation algorithms convert a password or shared secret value
into a key-encryption key. into a key-encryption key.
KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier
KeyDerivationAlgorithmIdentifier ::= 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
attribute certificates with which the set is associated are revoked. attribute certificates with which the set is associated are revoked.
However, there may be more CRLs than necessary or there MAY be fewer However, there may be more CRLs than necessary or there MAY be fewer
CRLs than necessary. CRLs than necessary.
The CertificateList may contain a CRL, an Authority Revocation List The CertificateList may contain a CRL, an Authority Revocation List
(ARL), a Delta CRL, or an Attribute Certificate Revocation List. All (ARL), a Delta CRL, or an Attribute Certificate Revocation List. All
of these lists share a common syntax. of these lists share a common syntax.
CRLs are specified in X.509 [X.509-97], and they are profiled for use CRLs are specified in X.509 [X.509-97], and they are profiled for use
in the Internet in RFC 2459 [PROFILE]. in the Internet in RFC <TBD> [PROFILE].
The definition of CertificateList is imported from X.509. The definition of CertificateList is imported from X.509.
CertificateRevocationLists ::= SET OF CertificateList CertificateRevocationLists ::= SET OF CertificateList
10.2.2 CertificateChoices 10.2.2 CertificateChoices
[*** NEW ***] The CertificateChoices type gives either a PKCS #6 [*** NEW ***] The CertificateChoices type gives either a PKCS #6
extended certificate [PKCS#6], an X.509 certificate, a version 1 extended certificate [PKCS#6], an X.509 certificate, a version 1
X.509 attribute certificate (ACv1) [X.509-97], or a version 2 X.509 X.509 attribute certificate (ACv1) [X.509-97], or a version 2 X.509
skipping to change at page 34, line 38 skipping to change at page 35, line 31
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 2459 [PROFILE]. Attribute is compatible with X.501 [X.501-88] and RFC <TBD>
Some of the attributes defined in this section were originally [PROFILE]. Some of the attributes defined in this section were
defined in PKCS #9 [PKCS#9]; others were originally defined in a originally defined in PKCS #9 [PKCS#9]; others were originally
previous version of this specification [OLDCMS]. The attributes are defined in a previous version of this specification [OLDCMS]. The
not listed in any particular order. attributes are not listed in any particular order.
Additional attributes are defined in many places, notably the S/MIME Additional attributes are defined in many places, notably the S/MIME
Version 3 Message Specification [MSG] and the Enhanced Security Version 3 Message Specification [MSG] and the Enhanced Security
Services for S/MIME [ESS], which also include recommendations on the Services for S/MIME [ESS], which also include recommendations on the
placement of these attributes. placement of these attributes.
11.1 Content Type 11.1 Content Type
[*** NEW ***] The content-type attribute type specifies the content [*** NEW ***] The content-type attribute type specifies the content
type of the ContentInfo within signed-data or authenticated-data. type of the ContentInfo within signed-data or authenticated-data.
skipping to change at page 39, line 29 skipping to change at page 40, line 29
-- own purposes. -- own purposes.
IMPORTS IMPORTS
-- Directory Information Framework (X.501) -- Directory Information Framework (X.501)
Name Name
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, Certificate, CertificateList,
CertificateList, CertificateSerialNumber 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>) -- Attribute Certificate Definitions (X.509-2000)
PasswordRecipientInfo AttributeCertificate
FROM PasswordRecipientInfo { iso(1) member-body(2) FROM AttributeCertificateDefinitions { joint-iso-itu-t
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) ds(5) module(1) attributeCertificateDefinitions(32) 4 }
smime(16) modules(0) pwri(12) }
-- [*** NEW ***] -- [*** 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(15) } ;
-- 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,
skipping to change at page 41, line 41 skipping to change at page 42, line 41
-- RecipientInfo ::= CHOICE { -- RecipientInfo ::= CHOICE {
-- ktri KeyTransRecipientInfo, -- ktri KeyTransRecipientInfo,
-- kari [1] KeyAgreeRecipientInfo, -- kari [1] KeyAgreeRecipientInfo,
-- kekri [2] KEKRecipientInfo } -- kekri [2] KEKRecipientInfo }
-- [*** NEW ***] -- [*** NEW ***]
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo, kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo, pwri [3] PasswordRecipientInfo,
ori [4] OtherRecipientInfo } 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 43, line 5 skipping to change at page 44, line 5
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 ***] -- [*** NEW ***]
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0
keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
-- [*** NEW ***]
OtherRecipientInfo ::= SEQUENCE { OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER, oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType } 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 }
skipping to change at page 44, line 14 skipping to change at page 45, line 22
DigestAlgorithmIdentifier ::= AlgorithmIdentifier DigestAlgorithmIdentifier ::= AlgorithmIdentifier
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
-- [*** NEW ***]
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
CertificateRevocationLists ::= SET OF CertificateList CertificateRevocationLists ::= SET OF CertificateList
-- [*** OLD ***] -- [*** OLD ***]
-- CertificateChoices ::= CHOICE { -- CertificateChoices ::= CHOICE {
-- certificate Certificate, -- See X.509 -- certificate Certificate, -- See X.509
-- extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete -- extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
-- attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 -- attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57
-- [*** NEW ***] -- [*** NEW ***]
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
skipping to change at page 46, line 11 skipping to change at page 48, line 11
Signature ::= BIT STRING Signature ::= BIT STRING
END -- of CryptographicMessageSyntax END -- of CryptographicMessageSyntax
Appendix B: Version 1 Attribute Certificate ASN.1 Module Appendix B: Version 1 Attribute Certificate ASN.1 Module
[*** NEW ***] [*** NEW ***]
AttributeCertificateVersion1 AttributeCertificateVersion1
{ 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) v1AttrCert(1) } pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
-- Only one type is defined, and it is exported. -- Only one type is defined, and it is exported.
IMPORTS IMPORTS
-- Directory Authentication Framework (X.509-1997) -- Directory Authentication Framework (X.509-1997)
skipping to change at page 47, line 50 skipping to change at page 49, line 50
RFC 2633. June 1999. RFC 2633. June 1999.
NEWPKCS#1 Kaliski, B., and J. Staddon. PKCS #1: RSA Encryption, NEWPKCS#1 Kaliski, B., and J. Staddon. PKCS #1: RSA Encryption,
Version 2.0. RFC 2437. October 1998. Version 2.0. RFC 2437. October 1998.
OLDCMS Housley, R., "Cryptographic Message Syntax", RFC 2630, OLDCMS Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999. June 1999.
PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet
X.509 Public Key Infrastructure: Certificate and CRL X.509 Public Key Infrastructure: Certificate and CRL
Profile. RFC 2459. January 1999. Profile. RFC <TBD>. <Date>.
[draft-ietf-pkix-new-part1-*.txt]
PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5.
RFC 2313. March 1998. RFC 2313. March 1998.
PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax
Standard, Version 1.5. November 1993. Standard, Version 1.5. November 1993.
PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax,
Version 1.5. RFC 2315. March 1998. Version 1.5. RFC 2315. March 1998.
PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types,
Version 1.1. November 1993. Version 1.1. November 1993.
skipping to change at page 50, line 19 skipping to change at page 52, line 19
encrypt the content-encryption key. If the key-encryption and encrypt the content-encryption key. If the key-encryption and
content-encryption algorithms are different, the effective security content-encryption algorithms are different, the effective security
is determined by the weaker of the two algorithms. If, for example, is determined by the weaker of the two algorithms. If, for example,
a message content is encrypted with 168-bit Triple-DES and the a message content is encrypted with 168-bit Triple-DES and the
Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, Triple-DES content-encryption key is wrapped with a 40-bit RC2 key,
then at most 40 bits of protection is provided. A trivial search to then at most 40 bits of protection is provided. A trivial search to
determine the value of the 40-bit RC2 key can recover Triple-DES key, determine the value of the 40-bit RC2 key can recover Triple-DES key,
and then the Triple-DES key can be used to decrypt the content. and then the Triple-DES key can be used to decrypt the content.
Therefore, implementers must ensure that key-encryption algorithms Therefore, implementers must ensure that key-encryption algorithms
are as strong or stronger than content-encryption algorithms. are as strong or stronger than content-encryption algorithms.
Section 12.6 specifies key wrap algorithms used to encrypt a Triple-
DES [3DES] content-encryption key with a Triple-DES key-encryption
key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key-
encryption key. The key wrap algorithms make use of CBC mode
[MODES]. These key wrap algorithms have been reviewed for use with
Triple and RC2. They have not been reviewed for use with other
cryptographic modes or other encryption algorithms. Therefore, if an
implementation of the CMS wishes to support ciphers in addition to
Triple-DES or RC2, then additional key wrap algorithms need to be
defined to support the additional ciphers.
Implementers should be aware that cryptographic algorithms become 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 reduce. 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, implementers should be prepared for
the set of mandatory to implement algorithms to change over time. the set of mandatory to implement algorithms to change over time.
The countersignature unsigned attribute includes a digital signature The countersignature unsigned attribute includes a digital signature
 End of changes. 

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