draft-ietf-smime-cms-07.txt   draft-ietf-smime-cms-08.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet Draft SPYRUS Internet Draft SPYRUS
expires in six months October 1998 expires in six months November 1998
Cryptographic Message Syntax Cryptographic Message Syntax
<draft-ietf-smime-cms-07.txt> <draft-ietf-smime-cms-08.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 5 skipping to change at page 2, line 5
[RFC 2315]. Wherever possible, backward compatibility is preserved; [RFC 2315]. Wherever possible, backward compatibility is preserved;
however, changes were necessary to accommodate attribute certificate however, changes were necessary to accommodate attribute certificate
transfer and key agreement techniques for key management. transfer and key agreement techniques for key management.
This draft is being discussed on the "ietf-smime" mailing list. To This draft is being discussed on the "ietf-smime" mailing list. To
join the list, send a message to <ietf-smime-request@imc.org> with join the list, send a message to <ietf-smime-request@imc.org> with
the single word "subscribe" in the body of the message. Also, there the single word "subscribe" in the body of the message. Also, there
is a Web site for the mailing list at <http://www.imc.org/ietf- is a Web site for the mailing list at <http://www.imc.org/ietf-
smime/>. smime/>.
Acknowledgments
This document is the result of contributions from many professionals.
I appreciate the hard work of all members of the IETF S/MIME Working
Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve
Dusse, Paul Hoffman, Scott Hollenbeck, Burt Kaliski, John Pawling,
Blake Ramsdell, Jim Schaad, and Dave Solo for their efforts and
support.
1 Introduction 1 Introduction
This document describes the Cryptographic Message Syntax. This This document describes the Cryptographic Message Syntax. This
syntax is used to digitally sign or encrypt arbitrary messages. syntax is used to digitally sign or encrypt arbitrary messages.
The Cryptographic Message Syntax describes an encapsulation syntax The Cryptographic Message Syntax describes an encapsulation syntax
for data protection. It supports digital signatures and encryption. for data protection. It supports digital signatures and encryption.
The syntax allows multiple encapsulation, so one encapsulation The syntax allows multiple encapsulation, so one encapsulation
envelope can be nested inside another. Likewise, one party can envelope can be nested inside another. Likewise, one party can
digitally sign some previously encapsulated data. It also allows digitally sign some previously encapsulated data. It also allows
skipping to change at page 2, line 44 skipping to change at page 2, line 35
strings. While many systems are capable of transmitting arbitrary strings. While many systems are capable of transmitting arbitrary
octet strings reliably, it is well known that many electronic-mail octet strings reliably, it is well known that many electronic-mail
systems are not. This document does not address mechanisms for systems are not. This document does not address mechanisms for
encoding octet strings for reliable transmission in such encoding octet strings for reliable transmission in such
environments. environments.
2 General Overview 2 General Overview
The Cryptographic Message Syntax (CMS) is general enough to support The Cryptographic Message Syntax (CMS) is general enough to support
many different content types. This document defines one protection many different content types. This document defines one protection
content, ContentInfo. ContentInfo encapsulates one or more content, ContentInfo. ContentInfo encapsulates one or more content
protection content type. This document defines six content types: types. This document defines six content types: data, signed-data,
data, signed-data, enveloped-data, digested-data, encrypted-data, and enveloped-data, digested-data, encrypted-data, and authenticated-
authenticated-data. Additional content types can be defined outside data. Additional content types can be defined outside this document.
this document.
An implementation that conforms to this specification must implement An implementation that conforms to this specification must implement
the protection content type and the data, signed-data, and the protection content, ContentInfo, and must implement the data,
enveloped-data signed-data, and enveloped-data content types. The other content
content types. The other content types may be implemented if types may be implemented if desired.
desired.
As a general design philosophy, content types permit single pass As a general design philosophy, each content type permit single pass
processing using indefinite-length Basic Encoding Rules (BER) processing using indefinite-length Basic Encoding Rules (BER)
encoding. Single-pass operation is especially helpful if content is encoding. Single-pass operation is especially helpful if content is
large, stored on tapes, or is "piped" from another process. Single- large, stored on tapes, or is "piped" from another process. Single-
pass operation has one significant drawback: it is difficult to pass operation has one significant drawback: it is difficult to
perform encode operations using the Distinguished Encoding Rules perform encode operations using the Distinguished Encoding Rules
(DER) encoding in a single pass since the lengths of the various (DER) encoding in a single pass since the lengths of the various
components may not be known in advance. However, signed attributes components may not be known in advance. However, signed attributes
within the signed-data content type and authenticated attributes within the signed-data content type and authenticated attributes
within the authenticated-data content type require DER encoding. within the authenticated-data content type require DER encoding.
Signed attributes and authenticated attributes must be transmitted in Signed attributes and authenticated attributes must be transmitted in
DER form to ensure that recipients can validate a content that DER form to ensure that recipients can validate a content that
contains an unrecognized attribute. contains an unrecognized attribute.
3 General Syntax 3 General Syntax
The Cryptographic Message Syntax (CMS) associates a protection The Cryptographic Message Syntax (CMS) associates a content type
content type with a protection content. The syntax shall have ASN.1 identifier with a content. The syntax shall have ASN.1 type
type ContentInfo: ContentInfo:
ContentInfo ::= SEQUENCE { ContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType } content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER ContentType ::= OBJECT IDENTIFIER
The fields of ContentInfo have the following meanings: The fields of ContentInfo have the following meanings:
contentType indicates the type of protection content. It is an contentType indicates the type of the associated content. It is
object identifier; it is a unique string of integers assigned by an object identifier; it is a unique string of integers assigned
an authority that defines the content type. by an authority that defines the content type.
content is the protection content. The type of protection content content is the associated content. The type of content can be
can be determined uniquely by contentType. Protection content determined uniquely by contentType. Content types for signed-
types for signed-data, enveloped-data, digested-data, encrypted- data, enveloped-data, digested-data, encrypted-data, and
data, and authenticated-data are defined in this document. If authenticated-data are defined in this document. If additional
additional protection content types are defined in other content types are defined in other documents, the ASN.1 type
documents, the ASN.1 type defined along with the object identifier defined should not be a CHOICE type.
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
skipping to change at page 5, line 4 skipping to change at page 4, line 39
2. For each signer, the message digest is digitally signed using 2. For each signer, the message digest is digitally signed using
the signer's private key. the signer's private key.
3. For each signer, the signature value and other signer-specific 3. For each signer, the signature value and other signer-specific
information are collected into a SignerInfo value, as defined in information are collected into a SignerInfo value, as defined in
Section 5.3. Certificates and CRLs for each signer, and those not Section 5.3. Certificates and CRLs for each signer, and those not
corresponding to any signer, are collected in this step. corresponding to any signer, are collected in this step.
4. The message digest algorithms for all the signers and the 4. The message digest algorithms for all the signers and the
SignerInfo values for all the signers are collected together with SignerInfo values for all the signers are collected together with
the the content into a SignedData value, as defined in Section 5.1.
content into a SignedData value, as defined in Section 5.1.
A recipient independently computes the message digest. This message A recipient independently computes the message digest. This message
digest and the signer's public key are used to validate the signature digest and the signer's public key are used to validate the signature
value. The signer's public key is referenced by an issuer value. The signer's public key is referenced by an issuer
distinguished name and an issuer-specific serial number that uniquely distinguished name and an issuer-specific serial number that uniquely
identify the certificate containing the public key. The signer's identify the certificate containing the public key. The signer's
certificate may be included in the SignedData certificates field. certificate may be included in the SignedData certificates field.
This section is divided into six parts. The first part describes the This section is divided into six parts. The first part describes the
top-level type SignedData, the second part describes top-level type SignedData, the second part describes
skipping to change at page 6, line 27 skipping to change at page 6, line 12
certificates is a collection of certificates. It is intended that certificates is a collection of certificates. It is intended that
the set of certificates be sufficient to contain chains from a the set of certificates 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 signers in the signerInfos field. There may be more the signers in the signerInfos field. There may be more
certificates than necessary, and there may be certificates certificates than necessary, and there may be certificates
sufficient to contain chains from two or more independent top- sufficient to contain chains from two or more independent top-
level certification authorities. There may also be fewer level certification authorities. There may also be fewer
certificates than necessary, if it is expected that recipients certificates than necessary, if it is expected that recipients
have an alternate means of obtaining necessary certificates (e.g., have an alternate means of obtaining necessary certificates (e.g.,
from a previous set of certificates). If no attribute from a previous set of certificates). As discussed above, if
certificates are present in the collection, then the value of attribute certificates are present, then the value of version
version shall be 1; however, if attribute certificates are shall be 3.
present, then the value of version shall be 3.
crls is a collection of certificate revocation lists (CRLs). It crls is a collection of certificate revocation lists (CRLs). It
is intended that the set contain information sufficient to is intended that the set contain information sufficient to
determine whether or not the certificates in the certificates determine whether or not the certificates in the certificates
field are valid, but such correspondence is not necessary. There field are valid, but such correspondence is not necessary. There
may be more CRLs than necessary, and there may also be fewer CRLs may be more CRLs than necessary, and there may also be fewer CRLs
than necessary. than necessary.
signerInfos is a collection of per-signer information. There may signerInfos is a collection of per-signer information. There may
be any number of elements in the collection, including zero. The be any number of elements in the collection, including zero. The
skipping to change at page 7, line 4 skipping to change at page 6, line 37
The optional omission of the eContent within the The optional omission of the eContent within the
EncapsulatedContentInfo field makes it possible to construct EncapsulatedContentInfo field makes it possible to construct
"external signatures." In the case of external signatures, the "external signatures." In the case of external signatures, the
content being signed is absent from the EncapsulatedContentInfo value content being signed is absent from the EncapsulatedContentInfo value
included in the signed-data content type. If the eContent value included in the signed-data content type. If the eContent value
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 EncapsulatedContentInfo value being "signed" is irrelevant. In this
value being "signed" is irrelevant. In this case, the content type case, the content type within the EncapsulatedContentInfo value being
within the EncapsulatedContentInfo value being "signed" should be "signed" should be id-data (as defined in section 4), and the content
id-data (as defined in section 4), and the content field of the field of the EncapsulatedContentInfo value should be omitted.
EncapsulatedContentInfo value should be omitted.
5.2 EncapsulatedContentInfo Type 5.2 EncapsulatedContentInfo Type
The content is represented in the type EncapsulatedContentInfo: The content is represented in the type EncapsulatedContentInfo:
EncapsulatedContentInfo ::= SEQUENCE { EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL } eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER ContentType ::= OBJECT IDENTIFIER
skipping to change at page 8, line 31 skipping to change at page 8, line 15
signedAttributes is a collection of attributes that are signed. signedAttributes is a collection of attributes that are signed.
The field is optional, but it must be present if the content type The field is optional, but it must be present if the content type
of the EncapsulatedContentInfo value being signed is not id-data. of the EncapsulatedContentInfo value being signed is not id-data.
Each SignedAttribute in the SET must be DER encoded. Useful Each SignedAttribute in the SET must be DER encoded. Useful
attribute types, such as signing time, are defined in Section 11. attribute types, such as signing time, are defined in Section 11.
If the field is present, it must contain, at a minimum, the If the field is present, it must contain, at a minimum, the
following two attributes: following two attributes:
A content-type attribute having as its value the content type A content-type attribute having as its value the content type
of the EncapsulatedContentInfo value being signed. Section of the EncapsulatedContentInfo value being signed. Section
11.1 defines the content-type attribute. 11.1 defines the content-type attribute. The content-type is
not required when used as part of a 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 9, line 29 skipping to change at page 9, line 15
or the length octets. or the length octets.
The result of the message digest calculation process depends on The result of the message digest calculation process depends on
whether the signedAttributes field is present. When the field is whether the signedAttributes field is present. When the field is
absent, the result is just the message digest of the content as absent, the result is just the message digest of the content as
described above. When the field is present, however, the result is described above. When the field is present, however, the result is
the message digest of the complete DER encoding of the the message digest of the complete DER encoding of the
SignedAttributes value contained in the signedAttributes field. SignedAttributes value contained in the signedAttributes field.
Since the SignedAttributes value, when present, must contain the Since the SignedAttributes value, when present, must contain the
content type and the content message digest attributes, those values content type and the content message digest attributes, those values
are indirectly included in the result. A separate encoding of the are indirectly included in the result. The content type attribute is
not required when used as part of a countersignature unsigned
attribute as defined in section 11.4. A separate encoding of the
signedAttributes field is performed for message digest calculation. signedAttributes field is performed for message digest calculation.
The IMPLICIT [0] tag in the signedAttributes field is not used for The IMPLICIT [0] tag in the signedAttributes field 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 SET OF tag, rather than of the IMPLICIT [0] the DER encoding of the SET OF tag, rather than of the IMPLICIT [0]
tag, is to be included in the message digest calculation along with tag, is to 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 signedAttributes field is absent, then only the octets When the signedAttributes field is absent, then only the octets
comprising the value of the signedData encapContentInfo eContent comprising the value of the signedData encapContentInfo eContent
OCTET STRING (e.g., the contents of a file) are input to the message OCTET STRING (e.g., the contents of a file) are input to the message
skipping to change at page 11, line 12 skipping to change at page 11, line 4
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 three 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; and
symmetric key-encryption keys: the content-encryption key is
mail list keys: the content-encryption key is encrypted in a encrypted in a previously distributed symmetric key-encryption
previously distributed symmetric key. key.
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 13, line 29 skipping to change at page 13, line 23
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. Per-recipient information is represented in the type RecipientInfo.
RecipientInfo has a different format for the three key management RecipientInfo has a different format for the three key management
techniques that are supported: key transport, key agreement, and techniques that are supported: key transport, key agreement, and
previously distributed mail list keys. Any of the three key previously distributed symmetric key-encryption keys. Any of the
management techniques can be used for each recipient of the same three key management techniques can be used for each recipient of the
encrypted content. In all cases, the content-encryption key is same encrypted content. In all cases, the content-encryption key is
transferred to one or more recipient in encrypted form. transferred to one or more recipient in encrypted form.
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
mlri [2] MailListRecipientInfo } kekri [2] KEKRecipientInfo }
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 {
skipping to change at page 16, line 5 skipping to change at page 15, line 49
ukm is optional. With some key agreement algorithms, the sender ukm is optional. With some key agreement algorithms, the sender
provides a User Keying Material (UKM) to ensure that a different provides a User Keying Material (UKM) to ensure that a different
key is generated each time the same two parties generate a key is generated each time the same two parties generate a
pairwise key. pairwise key.
keyEncryptionAlgorithm identifies the key-encryption algorithm, keyEncryptionAlgorithm identifies the key-encryption algorithm,
and any associated parameters, used to encrypt the content- and any associated parameters, used to encrypt the content-
encryption key in the key-encryption key. The key-encryption encryption key in the key-encryption key. The key-encryption
process is described in Section 6.4. process is described in Section 6.4.
recipientEncryptedKeys includes a recipient identifier and the recipientEncryptedKeys includes a recipient identifier and
encrypted key for one or more recipients. The encrypted key for one or more recipients. The
KeyAgreeRecipientIdentifier is a CHOICE with two alternatives KeyAgreeRecipientIdentifier is a CHOICE with two alternatives
specifying the recipient's certificate, and thereby the specifying the recipient's certificate, and thereby the
recipient's public key, that was used by the sender to generate a recipient's public key, that was used by the sender to generate a
pairwise key. The recipient's certificate must contain a key pairwise key-encryption key. The recipient's certificate must
agreement public key. The content-encryption key is encrypted in contain a key agreement public key. The content-encryption key is
the pairwise key. The issuerAndSerialNumber alternative encrypted in the pairwise key-encryption key. The
identifies the recipient's certificate by the issuer's issuerAndSerialNumber alternative identifies the recipient's
distinguished name and the certificate serial number; the certificate by the issuer's distinguished name and the certificate
RecipientKeyIdentifier is described below. The encryptedKey is serial number; the RecipientKeyIdentifier is described below. The
the result of encrypting the content-encryption key in the encryptedKey is the result of encrypting the content-encryption
pairwise key generated using the key agreement algorithm. key in the pairwise key-encryption key generated using the key
agreement algorithm.
The fields of type RecipientKeyIdentifier have the following The fields of type RecipientKeyIdentifier have the following
meanings: meanings:
subjectKeyIdentifier identifies the recipient's certificate by the subjectKeyIdentifier identifies the recipient's certificate by the
X.509 subjectKeyIdentifier extension value. X.509 subjectKeyIdentifier extension value.
date is optional. When present, the date specifies which of the date is optional. When present, the date specifies which of the
recipient's previously distributed UKMs was used by the sender. recipient's previously distributed UKMs was used by the sender.
other is optional. When present, this field contains additional other is optional. When present, this field contains additional
information used by the recipient to locate the public keying information used by the recipient to locate the public keying
material used by the sender. material used by the sender.
6.2.3 MailListRecipientInfo Type 6.2.3 KEKRecipientInfo Type
Recipient information using previously distributed symmetric keys is Recipient information using previously distributed symmetric keys is
represented in the type MailListRecipientInfo. Each instance of represented in the type KEKRecipientInfo. Each instance of
MailListRecipientInfo will transfer the content-encryption key to one KEKRecipientInfo will transfer the content-encryption key to one or
or more recipients who have the previously distributed key-encryption more recipients who have the previously distributed key-encryption
key. key.
MailListRecipientInfo ::= SEQUENCE { KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4 version CMSVersion, -- always set to 4
mlkid MailListKeyIdentifier, kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
MailListKeyIdentifier ::= SEQUENCE { KEKIdentifier ::= SEQUENCE {
kekIdentifier OCTET STRING, keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL, date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL } other OtherKeyAttribute OPTIONAL }
The fields of type MailListRecipientInfo have the following meanings: The fields of type KEKRecipientInfo have the following meanings:
version is the syntax version number. It shall always be 4. version is the syntax version number. It shall always be 4.
mlkid specifies a symmetric key encryption key that was previously kekid specifies a symmetric key-encryption key that was previously
distributed to the sender and one or more recipients. distributed to the sender and one or more recipients.
keyEncryptionAlgorithm identifies the key-encryption algorithm, keyEncryptionAlgorithm identifies the key-encryption algorithm,
and any associated parameters, used to encrypt the content- and any associated parameters, used to encrypt the content-
encryption key in the key-encryption key. The key-encryption encryption key with the key-encryption key. The key-encryption
process is described in Section 6.4. process is described in Section 6.4.
encryptedKey is the result of encrypting the content-encryption encryptedKey is the result of encrypting the content-encryption
key in the key-encryption key. key in the key-encryption key.
The fields of type MailListKeyIdentifier have the following meanings: The fields of type KEKIdentifier have the following meanings:
kekIdentifier 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.3 Content-encryption Process 6.3 Content-encryption Process
skipping to change at page 22, line 4 skipping to change at page 22, line 5
originator. Placement of the macAlgorithm field facilitates one- originator. Placement of the macAlgorithm field facilitates one-
pass processing by the recipient. pass processing by the recipient.
encapContentInfo is the content that is authenticated, as defined encapContentInfo is the content that is authenticated, as defined
in section 5.2. in section 5.2.
authenticatedAttributes is a collection of attributes that are authenticatedAttributes is a collection of attributes that are
authenticated. The field is optional, but it must be present if authenticated. The field is optional, but it must be present if
the content type of the EncapsulatedContentInfo value being the content type of the EncapsulatedContentInfo value being
authenticated is not id-data. Each AuthenticatedAttribute in the authenticated is not id-data. Each AuthenticatedAttribute in the
SET SET must be DER encoded. Useful attribute types are defined in
must be DER encoded. Useful attribute types are defined in
Section 11. If the field is present, it must contain, at a Section 11. If the field is present, it must contain, at a
minimum, the following two attributes: 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. 11.1 defines the content-type attribute.
A mac-value attribute, having as its value the message A mac-value attribute, having as its value the message
authentication code of the content. Section 11.5 defines the authentication code of the content. Section 11.5 defines the
mac-value attribute. mac-value attribute.
skipping to change at page 23, line 4 skipping to change at page 22, line 51
computationally infeasible to find any two distinct messages of any computationally infeasible to find any two distinct messages of any
length that have the same MAC. length that have the same MAC.
If authenticatedAttributes field is present, the content-type If authenticatedAttributes field is present, the content-type
attribute (as described in Section 11.1) and the mac-value attribute attribute (as described in Section 11.1) and the mac-value attribute
(as described in section 11.5) must be included, and the input to the (as described in section 11.5) must be included, and the input to the
MAC calculation process is the DER encoding of MAC calculation process is the DER encoding of
authenticatedAttributes. A separate encoding of the authenticatedAttributes. A separate encoding of the
authenticatedAttributes field is performed for MAC calculation. The authenticatedAttributes field is performed for MAC calculation. The
IMPLICIT [0] tag in the authenticatedAttributes field is not used for IMPLICIT [0] tag in the authenticatedAttributes field is not used for
the the DER encoding, rather an EXPLICIT SET OF tag is used. The DER
DER encoding, rather an EXPLICIT SET OF tag is used. The DER
encoding of the SET OF tag, rather than of the IMPLICIT [0] tag, is encoding of the SET OF tag, rather than of the IMPLICIT [0] tag, is
to be included in the MAC calculation along with the length and to be included in the MAC calculation along with the length and
content octets of the authenticatedAttributes value. content octets of the authenticatedAttributes value.
The fact that the MAC is computed on part of a DER encoding does not
mean that DER is the required method of representing that part for
data transfer. Indeed, it is expected that some implementations will
store objects in forms other than their DER encodings, but such
practices do not affect MAC computation.
The input to the MAC calculation process includes the MAC input data, The input to the MAC calculation process includes the MAC input data,
defined above, and an authentication key conveyed in a recipientInfo defined above, and an authentication key conveyed in a recipientInfo
structure. The details of MAC calculation depend on the MAC structure. The details of MAC calculation depend on the MAC
algorithm employed (e.g., DES-MAC and HMAC). The object identifier, algorithm employed (e.g., DES-MAC and HMAC). The object identifier,
along with any parameters, that specifies the MAC algorithm employed along with any parameters, that specifies the MAC algorithm employed
by the originator is carried in the macAlgorithm field. The MAC by the originator is carried in the macAlgorithm field. The MAC
value generated by the originator is encoded as an OCTET STRING and value generated by the originator is encoded as an OCTET STRING and
carried in the mac field. carried in the mac field.
9.3 MAC Validation 9.3 MAC Validation
skipping to change at page 25, line 46 skipping to change at page 25, line 37
revocation lists (CRLs). It is intended that the set contain revocation lists (CRLs). It is intended that the set contain
information sufficient to determine whether the certificates and information sufficient to determine whether the certificates and
attribute certificates with which the set is associated are revoked attribute certificates with which the set is associated are revoked
or not. However, there may be more CRLs than necessary or there may or not. However, there may be more CRLs than necessary or there may
be fewer CRLs than necessary. be fewer CRLs than necessary.
The CertificateList may contain a CRL, an Authority Revocation List The CertificateList may contain a CRL, an Authority Revocation List
(ARL), a Delta Revocation List, or an Attribute Certificate (ARL), a Delta Revocation List, or an Attribute Certificate
Revocation List. All of these lists share a common syntax. Revocation List. All of these lists share a common syntax.
CRLs are specified in X.509, and they are profiled for use in the
Internet in RFC TBD.
The definition of CertificateList is imported from X.509. The definition of CertificateList is imported from X.509.
CertificateRevocationLists ::= SET OF CertificateList CertificateRevocationLists ::= SET OF CertificateList
10.2.2 CertificateChoices 10.2.2 CertificateChoices
The CertificateChoices type gives either a PKCS #6 extended The CertificateChoices type gives either a PKCS #6 extended
certificate [PKCS #6], an X.509 certificate, or an X.509 attribute certificate [PKCS #6], an X.509 certificate, or an X.509 attribute
certificate. The PKCS #6 extended certificate is obsolete. It is certificate. The PKCS #6 extended certificate is obsolete. PKCS #5
included for backward compatibility, and its use should be avoided. certificates are included for backward compatibility, and their use
should be avoided. The Internet profile of X.509 certificates is
specified in RFC TBD.
The definitions of Certificate and AttributeCertificate are imported The definitions of Certificate and AttributeCertificate are imported
from X.509. from X.509.
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509 certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57
10.2.3 CertificateSet 10.2.3 CertificateSet
skipping to change at page 27, line 43 skipping to change at page 27, line 36
11 Useful Attributes 11 Useful Attributes
This section defines attributes that may used with signed-data or This section defines attributes that may used with signed-data or
authenticated-data. Some of the attributes defined in this section authenticated-data. Some of the attributes defined in this section
were originally defined in PKCS #9 [PKCS #9], others were not were originally defined in PKCS #9 [PKCS #9], others were not
previously defined. The attributes are not listed in any particular previously defined. The attributes are not listed in any particular
order. order.
Additional attributes are defined in many places, notably the S/MIME Additional attributes are defined in many places, notably the S/MIME
Version 3 Message Specification [MSG] and the Enhanced Security Version 3 Message Specification [RFC TBD2] and the Enhanced Security
Services for S/MIME [ESS], which also include recommendations on the Services for S/MIME [RFC TBD3], which also include recommendations on
placement of these attributes. the placement of these attributes.
11.1 Content Type 11.1 Content Type
The content-type attribute type specifies the content type of the The content-type attribute type specifies the content type of the
ContentInfo value being signed in signed-data. The content-type ContentInfo value being signed in signed-data. The content-type
attribute type is required if there are any authenticated attributes attribute type is required if there are any authenticated attributes
present. present.
The content-type attribute must be a signed attribute or an The content-type attribute must be a signed attribute or an
authenticated attribute; it cannot be an unsigned attribute or authenticated attribute; it cannot be an unsigned attribute or
skipping to change at page 34, line 8 skipping to change at page 33, line 43
modified to list SHA-1 in the bullet item about digestAlgorithm. The modified to list SHA-1 in the bullet item about digestAlgorithm. The
following object identifier is added to the list in section 10.1.2 of following object identifier is added to the list in section 10.1.2 of
RFC 2313: RFC 2313:
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 } oiw(14) secsig(3) algorithm(2) 26 }
12.3 Key Management Algorithms 12.3 Key Management Algorithms
CMS accommodates three general key management techniques: key CMS accommodates three general key management techniques: key
agreement, key transport, and mail list keys. agreement, key transport, and previously distributed symmetric key-
encryption keys.
12.3.1 Key Agreement Algorithms 12.3.1 Key Agreement Algorithms
CMS implementations must include key agreement using X9.42 CMS implementations must include key agreement using X9.42
Ephemeral-Static Diffie-Hellman. CMS implementations must include Ephemeral-Static Diffie-Hellman. CMS implementations must include
key agreement of Triple-DES pairwise key-encryption keys and Triple- key agreement of Triple-DES pairwise key-encryption keys and Triple-
DES wrapping Triple-DES content-encryption keys. CMS implementations DES wrapping Triple-DES content-encryption keys. CMS implementations
should include key agreement of RC2 pairwise key-encryption keys and should include key agreement of RC2 pairwise key-encryption keys and
RC2 wrapping RC2 content-encryption keys. The key wrap algorithm is RC2 wrapping RC2 content-encryption keys. The key wrap algorithm is
described in section 12.6. described in section 12.6.
skipping to change at page 34, line 45 skipping to change at page 34, line 33
originator must be the originatorKey alternative. The originator must be the originatorKey alternative. The
originatorKey algorithm fields must contain the dh-public-number originatorKey algorithm fields must contain the dh-public-number
object identifier with absent parameters. The originatorKey object identifier with absent parameters. The originatorKey
publicKey field must contain the sender's ephemeral public key. publicKey field must contain the sender's ephemeral public key.
The dh-public-number object identifier is: The dh-public-number object identifier is:
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 } us(840) ansi-x942(10046) number-type(2) 1 }
ukm must be absent. ukm may be absent. The ukm is used to ensure that a different
key-encryption key is generated when the ephemeral private key
might be used more than once.
keyEncryptionAlgorithm must be the id-alg-ESDHwith3DES algorithm keyEncryptionAlgorithm must be the id-alg-ESDHwith3DES algorithm
identifier with absent parameters. The id-alg-ESDHwith3DES identifier with absent parameters. The id-alg-ESDHwith3DES
algorithm identifier is: algorithm identifier is:
id-alg-ESDHwith3DES OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-ESDHwith3DES OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 1 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 1 }
recipientEncryptedKeys contains an identifier and an encrypted key recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier must contain either the KeyAgreeRecipientIdentifier must contain either the
issuerAndSerialNumber identifying the recipient's certificate or issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static public key. certificate contains the recipient's static public key.
RecipientEncryptedKey EncryptedKey must contain the content- RecipientEncryptedKey EncryptedKey must contain the content-
encryption Triple-DES key wrapped in the pairwise key agreement encryption Triple-DES key wrapped in the pairwise key agreement
Triple-DES key. Triple-DES key.
skipping to change at page 35, line 15 skipping to change at page 35, line 7
for each recipient. The RecipientEncryptedKey for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier must contain either the KeyAgreeRecipientIdentifier must contain either the
issuerAndSerialNumber identifying the recipient's certificate or issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static public key. certificate contains the recipient's static public key.
RecipientEncryptedKey EncryptedKey must contain the content- RecipientEncryptedKey EncryptedKey must contain the content-
encryption Triple-DES key wrapped in the pairwise key agreement encryption Triple-DES key wrapped in the pairwise key agreement
Triple-DES key. Triple-DES key.
12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman with RC2 12.3.1.2 X9.42 Ephemeral-Static Diffie-Hellman with RC2
Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1
[RFC TBD1]. When using Ephemeral-Static Diffie-Hellman with RC2, the [RFC TBD1]. When using Ephemeral-Static Diffie-Hellman with RC2, the
EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are used as EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are used as
follows: follows:
version must be 3. version must be 3.
originator must be the originatorKey alternative. The originator must be the originatorKey alternative. The
originatorKey algorithm fields must contain the dh-public-number originatorKey algorithm fields must contain the dh-public-number
object identifier with absent parameters. The originatorKey object identifier with absent parameters. The originatorKey
publicKey field must contain the sender's ephemeral public key. publicKey field must contain the sender's ephemeral public key.
The dh-public-number object identifier is: The dh-public-number object identifier is:
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 } us(840) ansi-x942(10046) number-type(2) 1 }
ukm must be absent. ukm may be absent. The ukm is used to ensure that a different
key-encryption key is generated if the ephemeral private key might
be used for more than once.
keyEncryptionAlgorithm must be the id-alg-ESDHwithRC2 algorithm keyEncryptionAlgorithm must be the id-alg-ESDHwithRC2 algorithm
identifier with absent parameters. The id-alg-ESDHwithRC2 identifier with absent parameters. The id-alg-ESDHwithRC2
algorithm identifier is: algorithm identifier is:
id-alg-ESDHwithRC2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-ESDHwithRC2 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 2 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 2 }
recipientEncryptedKeys contains an identifier and an encrypted key recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey for each recipient. The RecipientEncryptedKey
skipping to change at page 36, line 31 skipping to change at page 36, line 24
RFC 2313 specifies the transport of content-encryption keys, RFC 2313 specifies the transport of content-encryption keys,
including Triple-DES and RC2 keys. The algorithm identifier for RSA including Triple-DES and RC2 keys. The algorithm identifier for RSA
is: is:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
The AlgorithmIdentifier parameters field must be present, and the The AlgorithmIdentifier parameters field must be present, and the
parameters field must contain NULL. parameters field must contain NULL.
12.3.3 Mail List Key Algorithms The use of RSA encryption, as defined in RFC 2313, to provide
confidentiality has a known vulnerability concerns. The vulnerability
is primarily relevant to usage in interactive applications rather
than to store-and-forward environments. Further information and
proposed countermeasures are discussed in the Security Considerations
section of this document.
CMS implementations may include mail list key management. Mail list 12.3.3 Symmetric Key-Encryption Key Algorithms
key management implementations must include Triple-DES mail list keys
wrapping Triple-DES content-encryption keys. Mail list key
management implementations should include key transport of RC2
content-encryption keys. The key wrap algorithm is specified in
section 12.6.
Key mail list key algorithm identifiers are located in the CMS implementations may include symmetric key-encryption key
EnvelopedData RecipientInfo MailListRecipientInfo management. Such implementations must include Triple-DES key-
keyEncryptionAlgorithm field. encryption keys wrapping Triple-DES content-encryption keys, and such
implementations should include Triple-DES key-encryption keys
wrapping RC2 content-encryption keys. The key wrap algorithm is
specified in section 12.6.
Symmetric key-encryption key algorithm identifiers are located in the
EnvelopedData RecipientInfo KEKRecipientInfo keyEncryptionAlgorithm
field.
Wrapped content-encryption keys are located in the EnvelopedData Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfo MailListRecipientInfo encryptedKey field. RecipientInfo KEKRecipientInfo encryptedKey field.
12.3.3.1 Triple-DES Key Wrap 12.3.3.1 Triple-DES Key Wrap
Mail list key encryption with Triple-DES has the algorithm Triple-DES key encryption has the algorithm identifier:
identifier:
id-alg-3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 3 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 3 }
The AlgorithmIdentifier parameter field must be NULL. The AlgorithmIdentifier parameter field must be NULL.
Distribution of the Triple-DES mail list keying material used to Distribution of the Triple-DES key-encryption key used to encrypt the
encrypt the content-encryption key is out of the scope of this Triple-DES content-encryption key is out of the scope of this
document. document.
12.3.3.2 RC2 Key Wrap 12.3.3.2 RC2 Key Wrap
Mail list key encryption with RC2 has the algorithm identifier: RC2 key encryption has the algorithm identifier:
id-alg-RC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-RC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 4 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 4 }
The AlgorithmIdentifier parameter field must be RC2wrapParameter: The AlgorithmIdentifier parameter field must be RC2wrapParameter:
RC2wrapParameter ::= RC2ParameterVersion RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER RC2ParameterVersion ::= INTEGER
The RC2 effective-key-bits (key size) greater than 32 and less than The RC2 effective-key-bits (key size) greater than 32 and less than
256 is encoded in the RC2ParameterVersion. For the effective-key- 256 is encoded in the RC2ParameterVersion. For the effective-key-
bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
and 58 respectively. These values are not simply the RC2 key length. and 58 respectively. These values are not simply the RC2 key length.
Note that the value 160 must be encoded as two octets (00 A0), Note that the value 160 must be encoded as two octets (00 A0),
because the one octet (A0) encoding represents a negative number. because the one octet (A0) encoding represents a negative number.
Distribution of the RC2 mail list keying material used to encrypt the Distribution of the RC2 key-encryption key used to encrypt the RC2
content-encryption key is out of the scope of this document. content-encryption key is out of the scope of this document.
12.4 Content Encryption Algorithms 12.4 Content Encryption Algorithms
CMS implementations must include Triple-DES in CBC mode. CMS CMS implementations must include Triple-DES in CBC mode. CMS
implementations should include RC2 in CBC mode. implementations should include RC2 in CBC mode.
Content encryption algorithms identifiers are located in the Content encryption algorithms identifiers are located in the
EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field
and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm
skipping to change at page 39, line 37 skipping to change at page 39, line 32
MAC value, constrained to multiples of eight between 16 and 64: MAC value, constrained to multiples of eight between 16 and 64:
DESMACLength ::= INTEGER -- may be 16, 24, 32, 40, 48, 56, or 64 DESMACLength ::= INTEGER -- may be 16, 24, 32, 40, 48, 56, or 64
12.6 CMS Key Wrap Algorithm 12.6 CMS Key Wrap Algorithm
CMS implementations must implement the key wrap algorithm specified CMS implementations must implement the key wrap algorithm specified
in this section. in this section.
Key Transport algorithms allow for the content-encryption key to be Key Transport algorithms allow for the content-encryption key to be
directly encrypted; however, key agreement and mail list key directly encrypted; however, key agreement and symmetric key-
algorithms encrypt the content-encryption key with a second (possibly encryption key algorithms encrypt the content-encryption key with a
different) symmetric encryption algorithm. This section describes second symmetric encryption algorithm. This section describes how
how the content-encryption key is formatted and encrypted. the content-encryption key is formatted and encrypted.
Key agreement algorithms generate a pairwise key-encryption key, and Key agreement algorithms generate a pairwise key-encryption key, and
this key wrap algorithm is used to encrypt the content-encryption key this key wrap algorithm is used to encrypt the content-encryption key
in that pairwise key-encryption key. Similarly, this key wrap with the pairwise key-encryption key. Similarly, this key wrap
algorithm is used to encrypt the content-encryption key in a mail algorithm is used to encrypt the content-encryption key in a
list key. previously distributed key-encryption key.
The key-encryption key is generated by the key agreement algorithm or The key-encryption key is generated by the key agreement algorithm or
distributed as a mail list key. With key agreement, the minimum distributed out of band. For key agreement of RC2 key-encryption
number of bits needed to form the key-encryption key must be used. keys, 128 bits must be generated as input to the key expansion
As an example, only the first 40 bits of Diffie-Hellman generated process used to compute the RC2 effective key [RFC 2268].
keying material are used for a RC2/40 key-encryption key.
The block size of the key-encryption algorithm must be implicitly The block size of the key-encryption algorithm must be implicitly
determined from the KeyEncryptionAlgorithmIdentifier field. determined from the KeyEncryptionAlgorithmIdentifier field.
Likewise, the size of the content-encryption key must be implicitly Likewise, the size of the content-encryption key must be implicitly
determined from the ContentEncryptionAlgorithmIdentifier field. determined from the ContentEncryptionAlgorithmIdentifier field.
Since the same algorithm identifier is used for both 2-key and 3-key Since the same algorithm identifier is used for both 2-key and 3-key
Triple DES, three keys are always wrapped for Triple-DES. Thus, 2- Triple-DES, three keys are always wrapped for Triple-DES. Thus, 2-
key Triple-DES provides three keys where the first and third keys are key Triple-DES provides three keys where the first and third keys are
the same. the same.
12.6.1 Sum of Sums Key Checksum 12.6.1 Sum of Sums Key Checksum
The Sum of Sums [SUM] key checksum algorithm is: The Sum of Sums [SUM] key checksum algorithm is:
1. Initialize two 16 bit integers, sum1 and sum2, to zero. 1. Initialize two 16 bit integers, sum1 and sum2, to zero.
2. Loop through the octets of the content-encryption key, most 2. Loop through the octets of the content-encryption key, most
significant octet to least significant octet. significant octet to least significant octet.
2a. Create a 16 bit integer, called temp, by concatenating 2a. Create a 16 bit integer, called temp, by concatenating
eight zero bits and the key octet. eight zero bits and the key octet.
2b. sum1 = sum1 + temp. 2b. sum1 = sum1 + temp.
2c. sum2 = sum2 + sum1. 2c. sum2 = sum2 + sum1.
3. Use sum2 as the checksum value. 3. Use sum2 as the checksum value.
12.6.2 Key Wrap 12.6.2 Key Wrap
1. Modify the content-encryption key to meet any restrictions on the key. 1. Modify the content-encryption key to meet any restrictions on the key.
For example, adjust the parity bits for DES and Triple-DES keys. For example, adjust the parity bits for each DES key comprising a
Triple-DES key.
2. Compute a 16-bit key checksum value on the content-encryption key as 2. Compute a 16-bit key checksum value on the content-encryption key as
described above. described above.
3. Generate a 32-bit random salt value. 3. Generate a 32-bit random salt value.
4. Concatenate the salt, content-encryption key, and key checksum value. 4. Concatenate the salt, content-encryption key, and key checksum value.
5. Randomly generate the number of pad octets necessary to make the result 5. Randomly generate the number of pad octets necessary to make the result
a multiple of block size of the key-encryption algorithm (the Triple-DES a multiple of block size of the key-encryption algorithm (the Triple-DES
block size is 8 bytes), then append them to the result. block size is 8 bytes), then append them to the result.
6. Encrypt the result with the key-encryption algorithm key. Use an IV 6. Encrypt the result with the key-encryption algorithm key. Use an IV
with each octet equal to 'A5' hexadecimal. with each octet equal to 'A5' hexadecimal.
skipping to change at page 41, line 4 skipping to change at page 40, line 49
the parameters. The IV must still be the constant above. the parameters. The IV must still be the constant above.
12.6.3 Key Unwrap 12.6.3 Key Unwrap
The key unwrap algorithm is: The key unwrap algorithm is:
1. Decrypt the ciphertext using the key-encryption key. Use an IV 1. Decrypt the ciphertext using the key-encryption key. Use an IV
with each octet equal to 'A5' hexadecimal. with each octet equal to 'A5' hexadecimal.
2. Decompose the result into the content-encryption key and key checksum 2. Decompose the result into the content-encryption key and key checksum
values. The salt and pad values are discarded. values. The salt and pad values are discarded.
3. Compute a 16-bit key checksum value on the content-encryption key 3. Compute a 16-bit key checksum value on the content-encryption key
as as described above.
described above. 4. If computed key checksum value does not 4. If computed key checksum value does not match the decrypted key
match the decrypted key checksum checksum value, then there is an error.
value, then there is an error. 5. If there are restrictions on
keys, then check if the content-encryption 5. If there are restrictions on keys, then check if the
key meets these restrictions. For example, check for odd parity content-encryption key meets these restrictions. For example,
of each check for odd parity of each octet in each DES key that makes up
octet in a DES or Triple-DES key. If any restriction is a Triple-DES key. If any restriction is incorrect, then there is
incorrect then an error.
there is an error.
Appendix A: ASN.1 Module Appendix A: ASN.1 Module
CryptographicMessageSyntax CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at page 43, line 8 skipping to change at page 43, line 8
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos } signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo SignerInfos ::= SET OF SignerInfo
EncapsulatedContentInfo ::= SEQUENCE { EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL } eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
SignerInfo ::= SEQUENCE { SignerInfo ::= SEQUENCE {
version CMSVersion, version CMSVersion,
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier, signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue, signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
skipping to change at page 44, line 5 skipping to change at page 43, line 51
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
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
mlri [2] MailListRecipientInfo } kekri [2] KEKRecipientInfo }
EncryptedKey ::= OCTET STRING EncryptedKey ::= OCTET STRING
KeyTransRecipientInfo ::= SEQUENCE { KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2 version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier, rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE { RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
skipping to change at page 45, line 4 skipping to change at page 45, line 4
KeyAgreeRecipientIdentifier ::= CHOICE { KeyAgreeRecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
rKeyId [0] IMPLICIT RecipientKeyIdentifier } rKeyId [0] IMPLICIT RecipientKeyIdentifier }
RecipientKeyIdentifier ::= SEQUENCE { RecipientKeyIdentifier ::= SEQUENCE {
subjectKeyIdentifier SubjectKeyIdentifier, subjectKeyIdentifier SubjectKeyIdentifier,
date GeneralizedTime OPTIONAL, date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL } other OtherKeyAttribute OPTIONAL }
SubjectKeyIdentifier ::= OCTET STRING SubjectKeyIdentifier ::= OCTET STRING
MailListRecipientInfo ::= SEQUENCE { KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4 version CMSVersion, -- always set to 4
mlkid MailListKeyIdentifier, kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
MailListKeyIdentifier ::= SEQUENCE { KEKIdentifier ::= SEQUENCE {
kekIdentifier OCTET STRING, keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL, date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL } other OtherKeyAttribute OPTIONAL }
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
skipping to change at page 47, line 49 skipping to change at page 47, line 50
signatureAlgorithm SignatureAlgorithmIdentifier, signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature } signature Signature }
ExtendedCertificateInfo ::= SEQUENCE { ExtendedCertificateInfo ::= SEQUENCE {
version CMSVersion, version CMSVersion,
certificate Certificate, certificate Certificate,
attributes UnauthAttributes } attributes UnauthAttributes }
Signature ::= BIT STRING Signature ::= BIT STRING
-- Algorithm Identifiers and Parameters
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
END -- of CryptographicMessageSyntax END -- of CryptographicMessageSyntax
References References
3DES Tuchman, W. "Hellman Presents No Shortcut Solutions To DES". 3DES Tuchman, W. "Hellman Presents No Shortcut Solutions To DES".
IEEE Spectrum, v. 16, n. 7, pp40-41. July 1979. IEEE Spectrum, v. 16, n. 7, pp40-41. July 1979.
DES American National Standards Institute. ANSI X3.106, DES American National Standards Institute. ANSI X3.106,
"American National Standard for Information Systems - Data "American National Standard for Information Systems - Data
Link Encryption". 1983. Link Encryption". 1983.
DES MAC National Institute of Standards and Technology. FIPS Pub 113: DES MAC National Institute of Standards and Technology. FIPS Pub 113:
Computer Data Authentication. May 1985. Computer Data Authentication. May 1985.
DSS National Institute of Standards and Technology. DSS National Institute of Standards and Technology.
FIPS Pub 186: Digital Signature Standard. 19 May 1994. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
ESS Hoffman, P. Enhanced Security Services for S/MIME.
Internet draft, draft-ietf-smime-ess-*.txt.
MSG Ramsdell, B. S/MIME Version 3 Message Specification.
Internet Draft, draft-ietf-smime-msg-*.txt.
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 #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.
RFC 1321 Rivest, R. The MD5 Message-Digest Algorithm. April 1992. RFC 1321 Rivest, R. The MD5 Message-Digest Algorithm. April 1992.
RFC 1750 Eastlake, D.; S. Crocker; J. Schiller. Randomness RFC 1750 Eastlake, D.; S. Crocker; J. Schiller. Randomness
Recommendations for Security. December 1994. Recommendations for Security. December 1994.
skipping to change at page 49, line 49 skipping to change at page 48, line 43
RFC 2268 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. RFC 2268 Rivest, R. A Description of the RC2 (r) Encryption Algorithm.
March 1998. March 1998.
RFC 2313 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. RFC 2313 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5.
March 1998. March 1998.
RFC 2315 Kaliski, B. PKCS #7: Cryptographic Message Syntax, RFC 2315 Kaliski, B. PKCS #7: Cryptographic Message Syntax,
Version 1.5. March 1998. Version 1.5. March 1998.
RFC 2437 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0.
October 1998.
RFC TBD Housley, R., W. Ford, W. Polk, D. Solo. Internet
X.509 Public Key Infrastructure: Certificate and CRL
Profile. (currently draft-ietf-pkix-ipki-part1-*.txt)
RFC TBD1 Rescorla, E. Ephemeral-Static Diffie-Hellman Key RFC TBD1 Rescorla, E. Ephemeral-Static Diffie-Hellman Key
Agreement Method. (currently draft-ietf-smime-x942). Agreement Method. (currently draft-ietf-smime-x942-*.txt)
RFC TBD2 Ramsdell, B. S/MIME Version 3 Message Specification.
(currently draft-ietf-smime-msg-*.txt)
SHA1 National Institute of Standards and Technology. RFC TBD3 Hoffman, P. Enhanced Security Services for S/MIME.
(currently draft-ietf-smime-ess-*.txt)
SHA1 National Institute of Standards and Technology.
FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995.
SUM Fletcher, J. An Arithmetic Checksum for Serial SUM Fletcher, J. An Arithmetic Checksum for Serial
Transmissions. Reprint UCRL-82569, Lawrence Livermore Transmissions. Reprint UCRL-82569, Lawrence Livermore
Laboraory, University of California. May 1979. Laboraory, University of California. May 1979.
X.208 CCITT. Recommendation X.208: Specification of Abstract X.208 CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
X.209 CCITT. Recommendation X.209: Specification of Basic X.209 CCITT. Recommendation X.209: Specification of Basic Encoding
Encoding
Rules for Abstract Syntax Notation One (ASN.1). 1988. Rules for Abstract Syntax Notation One (ASN.1). 1988.
X.501 CCITT. Recommendation X.501: The Directory - Models. X.501 CCITT. Recommendation X.501: The Directory - Models. 1988.
1988.
X.509 CCITT. Recommendation X.509: The Directory - X.509 CCITT. Recommendation X.509: The Directory - Authentication
Authentication
Framework. 1988. Framework. 1988.
Security Considerations Security Considerations
The Cryptographic Message Syntax provides a method for digitally The Cryptographic Message Syntax provides a method for digitally
signing data, digesting data, encrypting data, and authenticating signing data, digesting data, encrypting data, and authenticating
data. data.
Implementations must protect the signer's private key. Compromise of Implementations must protect the signer's private key. Compromise of
the signer's private key permits masquerade. the signer's private key permits masquerade.
Implementations must protect the key management private key, the mail Implementations must protect the key management private key, the
list key, and the content-encryption key. Compromise of the key key-encryption key, and the content-encryption key. Compromise of
management private key or the mail list key may result in the the key management private key or the key-encryption key may result
disclosure of all messages protected with that key. Similarly, in the disclosure of all messages protected with that key.
compromise of the content-encryption key may result in disclosure of Similarly, compromise of the content-encryption key may result in
the associated encrypted content. disclosure of the associated encrypted content.
Implementations must protect the key management private key and the Implementations must protect the key management private key and the
message-authentication key. Compromise of the key management private message-authentication key. Compromise of the key management private
key permits masquerade of authenticated data. Similarly, compromise key permits masquerade of authenticated data. Similarly, compromise
of the message-authentication key may result in undetectable of the message-authentication key may result in undetectable
modification of the authenticated content. modification of the authenticated content.
Implementations must randomly generate content-encryption keys, Implementations must randomly generate content-encryption keys,
message-authentication keys, initialization vectors (Ivs), salt message-authentication keys, initialization vectors (IVs), salt
values, and padding. Also, the generation of public/private key values, and padding. Also, the generation of public/private key
pairs relies on a random numbers. The use of inadequate pseudo- pairs relies on a random numbers. The use of inadequate pseudo-
random number generators (PRNGs) to generate cryptographic keys can random number generators (PRNGs) to generate cryptographic keys can
result in little or no security. An attacker may find it much easier result in little or no security. An attacker may find it much easier
to to reproduce the PRNG environment that produced the keys, searching
reproduce the PRNG environment that produced the keys, searching the the resulting small set of possibilities, rather than brute force
resulting small set of possibilities, rather than brute force
searching the whole key space. The generation of quality random searching the whole key space. The generation of quality random
numbers is difficult. RFC 1750 offers important guidance in this numbers is difficult. RFC 1750 offers important guidance in this
area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG
technique. technique.
The countersignature unauthenticated attribute includes a digital The countersignature unauthenticated attribute includes a digital
signature that is computed on the content signature value, thus the signature that is computed on the content signature value, thus the
countersigning process need not know the original signed content. countersigning process need not know the original signed content.
This structure permits implementation efficiency advantages; however, This structure permits implementation efficiency advantages; however,
this structure may also permit the countersigning of an inappropriate this structure may also permit the countersigning of an inappropriate
signature value. Therefore, implementations that perform signature value. Therefore, implementations that perform
countersignatures should either validate the original signature value countersignatures should either validate the original signature value
prior to countersigning it (this validation requires processing of prior to countersigning it (this validation requires processing of
the original content), or implementations should perform the original content), or implementations should perform
countersigning in a context that ensures that only appropriate countersigning in a context that ensures that only appropriate
signature values are countersigned. signature values are countersigned.
Users of CMS, particularly those employing CMS to support interactive Users of CMS, particularly those employing CMS to support interactive
applications, should be aware that PKCS #1 [RFC 2313] is vulnerable applications, should be aware that PKCS #1 Version 1.5 [RFC 2313] is
to adaptive chosen ciphertext attacks when applied for encryption vulnerable to adaptive chosen ciphertext attacks when applied for
purposes. Exploitation of this identified vulnerability, revealing encryption purposes. Exploitation of this identified vulnerability,
the result of a particular RSA decryption, requires access to an revealing the result of a particular RSA decryption, requires access
oracle which will respond to a large number of ciphertexts (based on to an oracle which will respond to a large number of ciphertexts
currently available results, hundreds of thousands or more), which (based on currently available results, hundreds of thousands or
are constructed adaptively in response to previously-received replies more), which are constructed adaptively in response to previously-
providing information on the successes or failures of attempted received replies providing information on the successes or failures
decryption operations. As a result, the attack appears significantly of attempted decryption operations. As a result, the attack appears
less feasible to perpetrate for store-and-forward S/MIME environments significantly less feasible to perpetrate for store-and-forward
than for directly interactive protocols. Where CMS constructs are S/MIME environments than for directly interactive protocols. Where
applied as an intermediate encryption layer within an interactive CMS constructs are applied as an intermediate encryption layer within
request-response communications environment, exploitation could be an interactive request-response communications environment,
more feasible. exploitation could be more feasible.
An updated version of PKCS #1 has been published, PKCS #1 Version An updated version of PKCS #1 has been published, PKCS #1 Version 2.0
2.0. This new document may succeed RFC 2313. To resolve the [RFC 2437]. This new document will supersede RFC 2313. PKCS#1
adaptive chosen ciphertext vulnerability, the new document specifies Version 2.0 preserves support for the encryption padding format
and recommends use of Optimal Asymmetric Encryption Padding (OAEP) defined in PKCS#1 Version 1.5 [RFC 2313], and it also defines a new
when RSA encryption is applied to provide secrecy. Designers of alternative. To resolve the adaptive chosen ciphertext
protocols and systems employing CMS for interactive environments vulnerability, the PKCS #1 Version 2.0 specifies and recommends use
should either consider usage of OAEP, or should ensure that of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption
information which could reveal the success or failure of attempted is used to provide confidentiality. Designers of protocols and
PKCS #1 decryption operations is not provided. Support for OAEP may systems employing CMS for interactive environments should either
consider usage of OAEP, or should ensure that information which could
reveal the success or failure of attempted PKCS #1 Version 1.5
decryption operations is not provided. Support for OAEP will likely
be added to a future version of the CMS specification. be added to a future version of the CMS specification.
Acknowledgments
This document is the result of contributions from many professionals.
I appreciate the hard work of all members of the IETF S/MIME Working
Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve
Dusse, Paul Hoffman, Scott Hollenbeck, Burt Kaliski, John Linn, John
Pawling, Blake Ramsdell, Jim Schaad, and Dave Solo for their efforts
and support.
Author Address Author Address
Russell Housley Russell Housley
SPYRUS SPYRUS
381 Elden Street 381 Elden Street
Suite 1120 Suite 1120
Herndon, VA 20170 Herndon, VA 20170
USA USA
 End of changes. 

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