draft-ietf-smime-cms-05.txt   draft-ietf-smime-cms-06.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet Draft SPYRUS Internet Draft SPYRUS
expires in six months May 1998 expires in six months June 1998
Cryptographic Message Syntax Cryptographic Message Syntax
<draft-ietf-smime-cms-05.txt> <draft-ietf-smime-cms-06.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/>.
Acknowledgements Acknowledgments
This document is the result of contributions from many professionals. This document is the result of contributions from many professionals.
I appreciate the hard work of all members of the IETF S/MIME Working I appreciate the hard work of all members of the IETF S/MIME Working
Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve
Dusse, Paul Hoffman, Scott Hollenbeck, Burt Kaliski, John Pawling, Dusse, Paul Hoffman, Scott Hollenbeck, Burt Kaliski, John Pawling,
Blake Ramsdell, Jim Schaad, and Dave Solo for their efforts and Blake Ramsdell, Jim Schaad, and Dave Solo for their efforts and
support. support.
1 Introduction 1 Introduction
skipping to change at page 2, line 42 skipping to change at page 2, line 42
The Cryptographic Message Syntax values are generated using ASN.1, The Cryptographic Message Syntax values are generated using ASN.1,
using BER-encoding. Values are typically represented as octet using BER-encoding. Values are typically represented as octet
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 is general enough to support many The Cryptographic Message Syntax (CMS) is general enough to support
different content types. This document defines six content types: many different content types. This document defines one protection
content, ContentInfo. ContentInfo encapsulates one or more
protection content type. This document defines six content types:
data, signed-data, enveloped-data, digested-data, encrypted-data, and data, signed-data, enveloped-data, digested-data, encrypted-data, and
authenticated-data. Also, additional content types can be defined authenticated-data. Additional content types can be defined outside
outside this document. this document.
An implementation that conforms to this specification must implement An implementation that conforms to this specification must implement
the data, signed-data, and enveloped-data content types. The other the protection content type and the data, signed-data, and enveloped-
content types may be implemented if desired. data content types. The other content types may be implemented if
desired.
As a general design philosophy, content types permit single pass As a general design philosophy, content types 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 associates a protection content type The Cryptographic Message Syntax (CMS) associates a protection
with a protection content. The syntax shall have ASN.1 type content type with a protection content. The syntax shall have ASN.1
ContentInfo: 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:
contentType indicates the type of protection content. It is an contentType indicates the type of protection content. It is an
skipping to change at page 4, line 9 skipping to change at page 4, line 18
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
The data content type is intended to refer to arbitrary octet The data content type is intended to refer to arbitrary octet
strings, such as ASCII text files; the interpretation is left to the strings, such as ASCII text files; the interpretation is left to the
application. Such strings need not have any internal structure application. Such strings need not have any internal structure
(although they could have their own ASN.1 definition or other (although they could have their own ASN.1 definition or other
structure). structure).
The data content type is generally used in conjunction with the The data content type is generally encapsulated in the signed-data,
signed-data, enveloped-data, digested-data, encrypted-data, and enveloped-data, digested-data, encrypted-data, or authenticated-data
authenticated-data protection content types. The data content type content type. Object identifiers other than id-data may be used to
is encapsulated in one of these protection content types. identify the specific type of encapsulated content, but such usage is
outside the scope of this specification.
5 Signed-data Content Type 5 Signed-data Content Type
The signed-data content type consists of a content of any type and The signed-data content type consists of a content of any type and
zero or more signature values. Any number of signers in parallel can zero or more signature values. Any number of signers in parallel can
sign any type of content. sign any type of content.
The typical application of the signed-data content type represents The typical application of the signed-data content type represents
one signer's digital signature on content of the data content type. one signer's digital signature on content of the data content type.
Another typical application disseminates certificates and certificate Another typical application disseminates certificates and certificate
skipping to change at page 5, line 8 skipping to change at page 5, line 17
SignerInfo values for all the signers are collected together with SignerInfo values for all the signers are collected together with
the content into a SignedData value, as defined in Section 5.1. the 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 five parts. The first part describes This section is divided into six parts. The first part describes the
the top-level type SignedData, the second part describes the per- top-level type SignedData, the second part describes
signer information type SignerInfo, and the third, fourth, and fifth EncapsulatedContentInfo, the third part describes the per-signer
parts describe the message digest calculation, signature generation, information type SignerInfo, and the fourth, fifth, and sixth parts
and signature validation processes, respectively. describe the message digest calculation, signature generation, and
signature validation processes, respectively.
5.1 SignedData Type 5.1 SignedData Type
The following object identifier identifies the signed-data content The following object identifier identifies the signed-data content
type: type:
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
The signed-data content type shall have ASN.1 type SignedData: The signed-data content type shall have ASN.1 type SignedData:
skipping to change at page 7, line 7 skipping to change at page 7, line 14
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" should be id-data (as defined in section 4), and the content "signed" should be id-data (as defined in section 4), and the content
field of the EncapsulatedContentInfo value should be omitted. field of the EncapsulatedContentInfo value should be omitted.
5.2 EncapsulatedContentInfo Type 5.2 EncapsulatedContentInfo Type
Per-signer information is represented in the type SignerInfo: 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
The fields of type EncapsulatedContentInfo have the following The fields of type EncapsulatedContentInfo have the following
meanings: meanings:
skipping to change at page 13, line 26 skipping to change at page 13, line 32
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. In all cases, the content- previously distributed mail list keys. In all cases, the content-
encryption key is transferred to one or more recipient in encrypted encryption key is transferred to one or more recipient in encrypted
form. form.
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
mlri MailListRecipientInfo } mlri [2] MailListRecipientInfo }
EncryptedKey ::= OCTET STRING EncryptedKey ::= OCTET STRING
6.2.1 KeyTransRecipientInfo Type 6.2.1 KeyTransRecipientInfo Type
Per-recipient information using key transport is represented in the Per-recipient information using key transport is represented in the
type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo
transfers the content-encryption key to one recipient. transfers the content-encryption key to one recipient.
KeyTransRecipientInfo ::= SEQUENCE { KeyTransRecipientInfo ::= SEQUENCE {
version Version, -- always set to 0 or 2 version Version, -- always set to 0 or 2
rid EntityIdentifier, rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
EntityIdentifier ::= CHOICE { RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier } subjectKeyIdentifier [0] SubjectKeyIdentifier }
The fields of type KeyTransRecipientInfo have the following meanings: The fields of type KeyTransRecipientInfo have the following meanings:
version is the syntax version number. If the RecipientIdentifier version is the syntax version number. If the RecipientIdentifier
is the CHOICE issuerAndSerialNumber, then the version shall be 0. is the CHOICE issuerAndSerialNumber, then the version shall be 0.
If the RecipientIdentifier is rKeyId, then the version shall be 2. If the RecipientIdentifier is subjectKeyIdentifier, then the
version shall be 2.
rid specifies the recipient's certificate or key that was used by rid specifies the recipient's certificate or key that was used by
the sender to protect the content-encryption key. the sender to protect the content-encryption key. The
RecipientIdentifier provides two alternatives for specifying the
recipient's certificate, and thereby the recipient's public key.
The recipient's certificate must contain a key transport public
key. The content-encryption key is encrypted with the recipient's
public key. The issuerAndSerialNumber alternative identifies the
recipient's certificate by the issuer's distinguished name and the
certificate serial number; the subjectKeyIdentifier identifies the
recipient's certificate by the X.509 subjectKeyIdentifier
extension value.
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 for the recipient. The key-encryption process is encryption key for the recipient. The key-encryption process is
described in Section 6.4. described in Section 6.4.
encryptedKey is the result of encrypting the content-encryption encryptedKey is the result of encrypting the content-encryption
key for the recipient. key for the recipient.
The EntityIdentifier is a CHOICE with two alternatives specifying the
recipient's certificate, and thereby the recipient's public key. The
recipient's certificate must contain a key transport public key. The
content-encryption key is encrypted with the recipient's public key.
The issuerAndSerialNumber alternative identifies the recipient's
certificate by the issuer's distinguished name and the certificate
serial number; the subjectKeyIdentifier identifies the recipient's
certificate by the X.509 subjectKeyIdentifier extension value.
6.2.2 KeyAgreeRecipientInfo Type 6.2.2 KeyAgreeRecipientInfo Type
Recipient information using key agreement is represented in the type Recipient information using key agreement is represented in the type
KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will
transfer the content-encryption key to one or more recipient. transfer the content-encryption key to one or more recipient.
KeyAgreeRecipientInfo := SEQUENCE { KeyAgreeRecipientInfo ::= SEQUENCE {
version Version, -- always set to 3 version Version, -- always set to 3
originatorCert [0] EXPLICIT EntityIdentifier, originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys } recipientEncryptedKeys RecipientEncryptedKeys }
RecipientEncryptedKeys ::= SEQUEENCE OF RecipientEncryptedKey OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
RecipientEncryptedKey := SEQUENCE { OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING }
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
RecipientEncryptedKey ::= SEQUENCE {
rid RecipientIdentifier, rid RecipientIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE { RecipientIdentifier ::= 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,
skipping to change at page 15, line 4 skipping to change at page 15, line 18
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE { RecipientIdentifier ::= 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
The fields of type KeyAgreeRecipientInfo have the following meanings: The fields of type KeyAgreeRecipientInfo have the following meanings:
version is the syntax version number. It shall always be 3. version is the syntax version number. It shall always be 3.
originatorCert is a CHOICE with two alternatives specifying the originator is a CHOICE with three alternatives specifying the
sender's certificate, and thereby the sender's public key. The sender's key agreement public key. The sender uses the
sender's certificate must contain a key agreement public key, and corresponding private key and the recipient's public key to
the sender uses the corresponding private key and the recipient's generate a pairwise key. The content-encryption key is encrypted
public key to generate a pairwise key. The content-encryption key in the pairwise key. The issuerAndSerialNumber alternative
is encrypted in the pairwise key. The issuerAndSerialNumber identifies the sender's certificate, and thereby the sender's
alternative identifies the sender's certificate by the issuer's public key, by the issuer's distinguished name and the certificate
distinguished name and the certificate serial number; the serial number. The subjectKeyIdentifier alternative identifies
subjectKeyIdentifier alternative identifies the sender's the sender's certificate, and thereby the sender's public key, by
certificate by the X.509 subjectKeyIdentifier extension value. the X.509 subjectKeyIdentifier extension value. The originatorKey
alternative includes the algorithm identifier and sender's key
agreement public key. Permitting originator anonymity since the
public key is not certified.
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 the
encrypted key for one or more recipients. The RecipientIdentifier encrypted key for one or more recipients. The RecipientIdentifier
is a CHOICE with two alternatives specifying the recipient's is a CHOICE with two alternatives specifying the recipient's
certificate, and thereby the recipient's public key, that was used certificate, and thereby the recipient's public key, that was used
by the sender to generate a pairwise key. The recipient's by the sender to generate a pairwise key. The recipient's
certificate must contain a key agreement public key. The certificate must contain a key agreement public key. The content-
content-encryption key is encrypted in the pairwise key. The encryption key is encrypted in the pairwise key. The
issuerAndSerialNumber alternative identifies the recipient's issuerAndSerialNumber alternative identifies the recipient's
certificate by the issuer's distinguished name and the certificate certificate by the issuer's distinguished name and the certificate
serial number; the RecipientKeyIdentifier is described below. The serial number; the RecipientKeyIdentifier is described below. The
encryptedKey is the result of encrypting the content-encryption encryptedKey is the result of encrypting the content-encryption
key in the pairwise key generated using the key agreement key in the pairwise key generated using the key agreement
algorithm. algorithm.
The fields of type RecipientKeyIdentifier have the following The fields of type RecipientKeyIdentifier have the following
meanings: meanings:
skipping to change at page 16, line 18 skipping to change at page 16, line 36
material used by the sender. material used by the sender.
6.2.3 MailListRecipientInfo Type 6.2.3 MailListRecipientInfo 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 MailListRecipientInfo. Each instance of
MailListRecipientInfo will transfer the content-encryption key to one MailListRecipientInfo will transfer the content-encryption key to one
or more recipients who have the previously distributed key-encryption or more recipients who have the previously distributed key-encryption
key. key.
MailListRecipientInfo := SEQUENCE { MailListRecipientInfo ::= SEQUENCE {
version Version, -- always set to 4 version Version, -- always set to 4
mlid MailListKeyIdentifier, mlkid MailListKeyIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
MailListKeyIdentifier ::= SEQUENCE { MailListKeyIdentifier ::= SEQUENCE {
kekIdentifier OCTET STRING, kekIdentifier 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 MailListRecipientInfo 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.
mlKeyId specifies a symmetric key encryption key that was mlkid specifies a symmetric key encryption key that was previously
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 in 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 MailListKeyIdentifier have the following meanings:
skipping to change at page 18, line 43 skipping to change at page 19, line 16
DigestedData ::= SEQUENCE { DigestedData ::= SEQUENCE {
version Version, version Version,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
digest Digest } digest Digest }
Digest ::= OCTET STRING Digest ::= OCTET STRING
The fields of type DigestedData have the following meanings: The fields of type DigestedData have the following meanings:
version is the syntax version number. It shall be 0. version is the syntax version number. If the encapsulated content
type is id-data, then the value of version shall be 0; however, if
the encapsulated content type is other than id-data, then the
value of version shall be 2.
digestAlgorithm identifies the message digest algorithm, and any digestAlgorithm identifies the message digest algorithm, and any
associated parameters, under which the content is digested. The associated parameters, under which the content is digested. The
message-digesting process is the same as in Section 5.4 in the message-digesting process is the same as in Section 5.4 in the
case when there are no signed attributes. case when there are no signed attributes.
encapContentInfo is the content that is digested, as defined in encapContentInfo is the content that is digested, as defined in
section 5.2. section 5.2.
digest is the result of the message-digesting process. digest is the result of the message-digesting process.
skipping to change at page 21, line 9 skipping to change at page 21, line 34
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
MessageAuthenticationCode ::= OCTET STRING MessageAuthenticationCode ::= OCTET STRING
The fields of type AuthenticatedData have the following meanings: The fields of type AuthenticatedData have the following meanings:
version is the syntax version number. It shall be 0. version is the syntax version number. It shall be 0.
originatorInfo optionally provides information about the originatorInfo optionally provides information about the
originator. It is present only if required by the key management originator. It is present only if required by the key management
algorithm. It may contain certificates, CRLs, and user keying algorithm. It may contain certificates and CRLs, as defined in
material (UKMs), as defined in Section 6.1. 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 the defined in Section 6.1. There must be at least one element in the
collection. collection.
macAlgorithm is a message authentication code algorithm macAlgorithm is a message authentication code algorithm
identifier. It identifies the message authentication code identifier. It identifies the message authentication code
algorithm, along with any associated parameters, used by the algorithm, along with any associated parameters, used by the
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.
skipping to change at page 21, line 44 skipping to change at page 22, line 20
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.
mac is the message authentication code. mac is the message authentication code.
unauthenticatedAttributes is a collection of attributes that are unauthenticatedAttributes is a collection of attributes that are
not authenticated. The field is optional. Useful attribute types not authenticated. The field is optional. To date, no attributes
are defined in Section 11. have been defined for use as unauthenticated attributes, but other
useful attribute types are defined in Section 11.
9.2 MAC Generation 9.2 MAC Generation
The MAC calculation process computes a message authentication code on The MAC calculation process computes a message authentication code on
either the message content or the content together with the either the message content or the content together with the
originator's authenticated attributes. originator's authenticated attributes.
If there are no authenticated attributes, the MAC input data is the If there are no authenticated attributes, the MAC input data is the
content octets of the DER encoding of the content field of the content octets of the DER encoding of the content field of the
ContentInfo value to which the MAC process is applied. Only the ContentInfo value to which the MAC process is applied. Only the
skipping to change at page 23, line 15 skipping to change at page 23, line 39
9.3 MAC Validation 9.3 MAC Validation
The input to the MAC validation process includes the input data The input to the MAC validation process includes the input data
(determined based on the presence or absence of authenticated (determined based on the presence or absence of authenticated
attributes, as defined in 9.2), and the authentication key conveyed attributes, as defined in 9.2), and the authentication key conveyed
in recipientInfo. The details of the MAC validation process depend in recipientInfo. The details of the MAC validation process depend
on the MAC algorithm employed. on the MAC algorithm employed.
The recipient may not rely on any MAC values computed by the The recipient may not rely on any MAC values computed by the
originator. If the originator includes authenticated attributes, originator. If the originator includes authenticated attributes,
then the content of the authenticatedAttributes must be autenticated then the content of the authenticatedAttributes must be authenticated
as described in section 9.2. For the MAC to be valid, the message as described in section 9.2. For the MAC to be valid, the message
MAC value calculated by the recipient must be the same as the value MAC value calculated by the recipient must be the same as the value
of the macValue attribute included in the authenticatedAttributes. of the macValue attribute included in the authenticatedAttributes.
Likewise, the attribute MAC value calculated by the recipient must be Likewise, the attribute MAC value calculated by the recipient must be
the same as the value of the mac field included in the the same as the value of the mac field included in the
authenticatedData. authenticatedData.
10 Useful Types 10 Useful Types
This section is divided into two parts. The first part defines This section is divided into two parts. The first part defines
skipping to change at page 34, line 40 skipping to change at page 35, line 4
EnvelopedData ::= SEQUENCE { EnvelopedData ::= SEQUENCE {
version Version, version Version,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo } encryptedContentInfo EncryptedContentInfo }
OriginatorInfo ::= SEQUENCE { OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL, certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }
RecipientInfos ::= SET OF RecipientInfo RecipientInfos ::= SET OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE { EncryptedContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING EncryptedContent ::= OCTET STRING
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
mlri MailListRecipientInfo } mlri [2] MailListRecipientInfo }
EncryptedKey ::= OCTET STRING EncryptedKey ::= OCTET STRING
KeyTransRecipientInfo ::= SEQUENCE { KeyTransRecipientInfo ::= SEQUENCE {
version Version, -- always set to 0 or 2 version Version, -- always set to 0 or 2
rid EntityIdentifier, rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
EntityIdentifier ::= CHOICE { RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier } subjectKeyIdentifier [0] SubjectKeyIdentifier }
KeyAgreeRecipientInfo := SEQUENCE { KeyAgreeRecipientInfo ::= SEQUENCE {
version Version, -- always set to 3 version Version, -- always set to 3
originatorCert [0] EXPLICIT EntityIdentifier, originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys } recipientEncryptedKeys RecipientEncryptedKeys }
RecipientEncryptedKeys ::= SEQUEENCE OF RecipientEncryptedKey OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
RecipientEncryptedKey := SEQUENCE { OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING }
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
RecipientEncryptedKey ::= SEQUENCE {
rid RecipientIdentifier, rid RecipientIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE { RecipientIdentifier ::= 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
skipping to change at page 35, line 45 skipping to change at page 36, line 15
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 { MailListRecipientInfo ::= SEQUENCE {
version Version, -- always set to 4 version Version, -- always set to 4
mlid MailListKeyIdentifier, mlkid MailListKeyIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
MailListKeyIdentifier ::= SEQUENCE { MailListKeyIdentifier ::= SEQUENCE {
kekIdentifier OCTET STRING, kekIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL, date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL } other OtherKeyAttribute OPTIONAL }
DigestedData ::= SEQUENCE { DigestedData ::= SEQUENCE {
version Version, version Version,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
digest Digest } digest Digest }
 End of changes. 

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