draft-ietf-smime-rfc2630bis-01.txt   draft-ietf-smime-rfc2630bis-02.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet Draft RSA Laboratories Internet Draft RSA Laboratories
expires in six months June 2001 expires in six months August 2001
Cryptographic Message Syntax Cryptographic Message Syntax
<draft-ietf-smime-rfc2630bis-01.txt> <draft-ietf-smime-rfc2630bis-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
This document describes the Cryptographic Message Syntax (CMS). This This document describes the Cryptographic Message Syntax (CMS). This
syntax is used to digitally sign, digest, authenticate, or encrypt syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages. arbitrary messages.
The CMS is derived from PKCS #7 version 1.5 as specified in RFC 2315 The CMS is derived from PKCS #7 version 1.5 as specified in RFC 2315
[PKCS#7]. Wherever possible, backward compatibility is preserved; [PKCS#7]. 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.
[*** NEW ***] Once approved, this draft will obsolete RFC 2630. The [*** NEW ***] Once approved, this draft will obsolete RFC 2630. The
discussion of specific cryptographic algorithms has been moved to a discussion of specific cryptographic algorithms has been moved to a
separate document. Separation of the protocol and algorithm separate document [CMSALG]. Separation of the protocol and algorithm
specifications allows the IETF to select different mandatory to specifications allows the IETF to update each document independently.
implement algorithms in the future without reissuing this protocol No mandatory to implement algorithms are specified. Rather,
document. However, implementations of the CMS MUST support the protocols that reply on the CMS are expected to choose appropriate
mandatory to implement algorithms specified in [CMSALG], or its algorithms for their environment. The algorithms may be selected
successor. from [CMSALG] or elsewhere.
Look for [*** NEW ***]. This string is used to identify text that is Look for [*** NEW ***]. This string is used to identify text that is
significantly different than RFC 2630. Editorial changes were made significantly different than RFC 2630. However, editorial changes
that are not flagged with this string. Also, the final page of this were made that are not flagged with this string.
document contains a change history.
This draft is being discussed on the "ietf-smime" mailing list. To This draft is being discussed on the "ietf-smime" mailing list. To
join the list, send a message to <ietf-smime-request@imc.org> with join the list, send a message to <ietf-smime-request@imc.org> with
the single word "subscribe" in the body of the message. Also, there the single word "subscribe" in the body of the message. Also, there
is a Web site for the mailing list at <http://www.imc.org/ietf- is a Web site for the mailing list at <http://www.imc.org/ietf-
smime/>. smime/>.
Table of Contents Table of Contents
Status of this Memo ................................................ 1 Status of this Memo ................................................ 1
skipping to change at page 5, line 49 skipping to change at page 5, line 49
This document defines one protection content, ContentInfo. This document defines one protection content, ContentInfo.
ContentInfo encapsulates a single identified content type, and the ContentInfo encapsulates a single identified content type, and the
identified type may provide further encapsulation. This document identified type may provide further encapsulation. This document
defines six content types: data, signed-data, enveloped-data, defines six content types: data, signed-data, enveloped-data,
digested-data, encrypted-data, and authenticated-data. Additional digested-data, encrypted-data, and authenticated-data. Additional
content types can be defined outside this document. content types can be defined outside this document.
An implementation that conforms to this specification MUST implement An implementation that conforms to this specification MUST implement
the protection content, ContentInfo, and MUST implement the data, the protection content, ContentInfo, and MUST implement the data,
signed-data, and enveloped-data content types. The other content signed-data, and enveloped-data content types. The other content
types MAY be implemented if desired. types MAY be implemented.
As a general design philosophy, each content type permits single pass As a general design philosophy, each content type permits 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) [X.509-88] encoding in a single pass since the lengths of the (DER) [X.509-88] encoding in a single pass since the lengths of the
various components may not be known in advance. However, signed various components may not be known in advance. However, signed
attributes within the signed-data content type and authenticated attributes within the signed-data content type and authenticated
attributes within the authenticated-data content types require DER attributes within the authenticated-data content type need to be
encoding. Signed attributes and authenticated attributes must be
transmitted in DER form to ensure that recipients can verify a transmitted in DER form to ensure that recipients can verify a
content that contains one or more unrecognized attributes. The CMS content that contains one or more unrecognized attributes. Signed
signed attributes and authenticated attributes MUST be encoded with attributes and authenticated attributes are the only data types used
DER. in the CMS that require DER encoding.
3 General Syntax 3 General Syntax
The CMS associates a content type identifier with a content. The The CMS associates a content type identifier with a content. The
syntax MUST have ASN.1 type ContentInfo: syntax MUST have ASN.1 type ContentInfo:
ContentInfo ::= SEQUENCE { ContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType } content [0] EXPLICIT ANY DEFINED BY contentType }
skipping to change at page 7, line 49 skipping to change at page 7, line 48
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 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 verify the signature digest and the signer's public key are used to verify the signature
value. The signer's public key is referenced either by an issuer value. The signer's public key is referenced either by an issuer
distinguished name along with an issuer-specific serial number or by distinguished name along with an issuer-specific serial number or by
a subject key identifier that uniquely identifies the certificate a subject key identifier that uniquely identifies the certificate
containing the public key. The signer's certificate MAY be included containing the public key. The signer's certificate can be included
in the SignedData certificates field. 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
EncapsulatedContentInfo, the third part describes the per-signer EncapsulatedContentInfo, the third part describes the per-signer
information type SignerInfo, and the fourth, fifth, and sixth parts information type SignerInfo, and the fourth, fifth, and sixth parts
describe the message digest calculation, signature generation, and describe the message digest calculation, signature generation, and
signature verification processes, respectively. signature verification processes, respectively.
5.1 SignedData Type 5.1 SignedData Type
skipping to change at page 8, line 36 skipping to change at page 8, line 34
certificates [0] IMPLICIT CertificateSet OPTIONAL, certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos } signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo SignerInfos ::= SET OF SignerInfo
The fields of type SignedData have the following meanings: The fields of type SignedData have the following meanings:
[*** NEW ***] version is the syntax version number. If no [*** NEW ***] version is the syntax version number. The
attribute certificates are present in the certificates field, the appropriate value depends on certificates, eContentType, and
encapsulated content type is id-data, and all of the elements of SignerInfo. The version MUST be assigned as follows:
SignerInfos are version 1, then the value of version MUST be 1.
If version 1 attribute certificates are present, the encapsulated IF (certificates is present) AND
content type is other than id-data, or any of the elements of (any version 2 attribute certificates are present)
SignerInfos are version 3, then the value of version MUST be 3. THEN version MUST be 4
If version 2 attribute certificates are present, then the value of ELSE
version MUST be 4. IF ((certificates is present) AND
(any version 1 attribute certificates are present)) OR
(encapContentInfo eContentType is other than id-data) OR
(any SignerInfo structures are version 3)
THEN version MUST be 3
ELSE version MUST be 1
digestAlgorithms is a collection of message digest algorithm digestAlgorithms is a collection of message digest algorithm
identifiers. There MAY be any number of elements in the identifiers. There MAY be any number of elements in the
collection, including zero. Each element identifies the message collection, including zero. Each element identifies the message
digest algorithm, along with any associated parameters, used by digest algorithm, along with any associated parameters, used by
one or more signer. The collection is intended to list the one or more signer. The collection is intended to list the
message digest algorithms employed by all of the signers, in any message digest algorithms employed by all of the signers, in any
order, to facilitate one-pass signature verification. The message order, to facilitate one-pass signature verification.
digesting process is described in Section 5.4. Implementations MAY fail to validate signatures that use a digest
algorithm that is not included in this set. The message digesting
process is described in Section 5.4.
encapContentInfo is the signed content, consisting of a content encapContentInfo is the signed content, consisting of a content
type identifier and the content itself. Details of the type identifier and the content itself. Details of the
EncapsulatedContentInfo type are discussed in section 5.2. EncapsulatedContentInfo type are discussed in section 5.2.
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). As discussed above, if from a previous set of certificates). The signer's certificate
attribute certificates are present, then the value of version MUST MAY be included. The use of version 1 attribute certificates is
be 3. strongly discouraged.
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
details of the SignerInfo type are discussed in section 5.3. details of the SignerInfo type are discussed in section 5.3.
Since each signer can employ a digital signature technique and
future specifications could update the syntax, all implementations
MUST gracefully handle unimplemented versions of SignerInfo.
Further, since all implementations will not support every possible
signature algorithm, all implementations MUST gracefully handle
unimplemented signature algorithms when they are encountered.
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
The fields of type EncapsulatedContentInfo have the following The fields of type EncapsulatedContentInfo have the following
meanings: meanings:
eContentType is an object identifier. The object identifier MUST eContentType is an object identifier. The object identifier
uniquely specify the content type. uniquely specifies the content type.
eContent is the content itself, carried as an octet string. The eContent is the content itself, carried as an octet string. The
eContent need not be DER encoded. eContent need not be DER encoded.
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 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" MUST be id-data (as defined in section 4), and the content
field of the EncapsulatedContentInfo value should be omitted. field of the EncapsulatedContentInfo value MUST be omitted.
5.3 SignerInfo Type 5.3 SignerInfo Type
Per-signer information is represented in the type SignerInfo: Per-signer information is represented in the type SignerInfo:
SignerInfo ::= SEQUENCE { SignerInfo ::= SEQUENCE {
version CMSVersion, version CMSVersion,
sid SignerIdentifier, sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
skipping to change at page 11, line 9 skipping to change at page 11, line 21
The fields of type SignerInfo have the following meanings: The fields of type SignerInfo have the following meanings:
version is the syntax version number. If the SignerIdentifier is version is the syntax version number. If the SignerIdentifier is
the CHOICE issuerAndSerialNumber, then the version MUST be 1. If the CHOICE issuerAndSerialNumber, then the version MUST be 1. If
the SignerIdentifier is subjectKeyIdentifier, then the version the SignerIdentifier is subjectKeyIdentifier, then the version
MUST be 3. MUST be 3.
sid specifies the signer's certificate (and thereby the signer's sid specifies the signer's certificate (and thereby the signer's
public key). The signer's public key is needed by the recipient public key). The signer's public key is needed by the recipient
to verify the signature. SignerIdentifier provides three to verify the signature. SignerIdentifier provides two
alternatives for specifying the signer's public key. The alternatives for specifying the signer's public key. The
issuerAndSerialNumber alternative identifies the signer's issuerAndSerialNumber alternative identifies the signer's
certificate by the issuer's distinguished name and the certificate certificate by the issuer's distinguished name and the certificate
serial number; the subjectKeyIdentifier identifies the signer's serial number; the subjectKeyIdentifier identifies the signer's
certificate by the X.509 subjectKeyIdentifier extension value. certificate by the X.509 subjectKeyIdentifier extension value.
Implementations MUST support the reception of the Implementations MUST support the reception of the
issuerAndSerialNumber and subjectKeyIdentifier forms of issuerAndSerialNumber and subjectKeyIdentifier forms of
SignerIdentifier. When generating a SignerIdentifier, SignerIdentifier. When generating a SignerIdentifier,
implementations MAY support one of the forms (either implementations MAY support one of the forms (either
issuerAndSerialNumber or subjectKeyIdentifier) and always use it, issuerAndSerialNumber or subjectKeyIdentifier) and always use it,
or implementations MAY arbitrarily mix the two forms. or implementations MAY arbitrarily mix the two forms.
digestAlgorithm identifies the message digest algorithm, and any digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the signer. The message digest is associated parameters, used by the signer. The message digest is
computed on either the content being signed or the content computed on either the content being signed or the content
together with the signed attributes using the process described in together with the signed attributes using the process described in
section 5.4. The message digest algorithm should be among those section 5.4. The message digest algorithm SHOULD be among those
listed in the digestAlgorithms field of the associated SignerData. listed in the digestAlgorithms field of the associated SignerData.
Implementations MAY fail to validate signatures that use a digest
algorithm that is not included in the SignedData digestAlgorithms
set.
signedAttributes is a collection of attributes that are signed. signedAttrs is a collection of attributes that are signed. The
The field is optional, but it MUST be present if the content type field is optional, but it MUST be present if the content type of
of the EncapsulatedContentInfo value being signed is not id-data. 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. The content-type 11.1 defines the content-type attribute. [*** NEW ***]
attribute is not required when used as part of a However, the content-type attribute MUST NOT be used as part of
countersignature unsigned attribute as defined in section 11.4. 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
message digest and the signer's private key. [*** NEW ***] This message digest and the signer's private key. [*** NEW ***] The
field MUST be present; however, the details of the signature details of the signature depend on the signature algorithm
depend on the signature algorithm employed. employed.
unsignedAttributes is a collection of attributes that are not unsignedAttrs is a collection of attributes that are not signed.
signed. The field is optional. Useful attribute types, such as The field is optional. Useful attribute types, such as
countersignatures, are defined in Section 11. countersignatures, are defined in Section 11.
The fields of type SignedAttribute and UnsignedAttribute have the The fields of type SignedAttribute and UnsignedAttribute have the
following meanings: following meanings:
attrType indicates the type of attribute. It is an object attrType indicates the type of attribute. It is an object
identifier. identifier.
attrValues is a set of values that comprise the attribute. The attrValues is a set of values that comprise the attribute. The
type of each value in the set can be determined uniquely by type of each value in the set can be determined uniquely by
attrType. attrType. The attrType can impose restrictions on the number of
items in the set.
5.4 Message Digest Calculation Process 5.4 Message Digest Calculation Process
The message digest calculation process computes a message digest on The message digest calculation process computes a message digest on
either the content being signed or the content together with the either the content being signed or the content together with the
signed attributes. In either case, the initial input to the message signed attributes. In either case, the initial input to the message
digest calculation process is the "value" of the encapsulated content digest calculation process is the "value" of the encapsulated content
being signed. Specifically, the initial input is the being signed. Specifically, the initial input is the
encapContentInfo eContent OCTET STRING to which the signing process encapContentInfo eContent OCTET STRING to which the signing process
is applied. Only the octets comprising the value of the eContent is applied. Only the octets comprising the value of the eContent
OCTET STRING are input to the message digest algorithm, not the tag OCTET STRING are input to the message digest algorithm, not the tag
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 signedAttrs field is present. When the field is absent,
absent, the result is just the message digest of the content as the result is just the message digest of the content as described
described above. When the field is present, however, the result is above. When the field is present, however, the result is the message
the message digest of the complete DER encoding of the digest of the complete DER encoding of the SignedAttrs value
SignedAttributes value contained in the signedAttributes field. contained in the signedAttrs field. Since the SignedAttrs value,
Since the SignedAttributes value, when present, must contain the when present, must contain the content-type and the message-digest
content type and the content message digest attributes, those values attributes, those values are indirectly included in the result. The
are indirectly included in the result. The content type attribute is content-type attribute MUST NOT be included in a countersignature
not required when used as part of a countersignature unsigned unsigned attribute as defined in section 11.4. A separate encoding
attribute as defined in section 11.4. A separate encoding of the of the signedAttrs field is performed for message digest calculation.
signedAttributes field is performed for message digest calculation. The IMPLICIT [0] tag in the signedAttributes is not used for the DER
The IMPLICIT [0] tag in the signedAttributes field is not used for encoding, rather an EXPLICIT SET OF tag is used. That is, the DER
the DER encoding, rather an EXPLICIT SET OF tag is used. That is, encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0]
the DER encoding of the EXPLICIT SET OF tag, rather than of the tag, MUST be included in the message digest calculation along with
IMPLICIT [0] tag, MUST be included in the message digest calculation the length and content octets of the SignedAttributes value.
along with the length and content octets of the SignedAttributes
value.
When the signedAttributes field is absent, only the octets comprising When the signedAttrs field is absent, only the octets comprising the
the value of the signedData encapContentInfo eContent OCTET STRING value of the signedData encapContentInfo eContent OCTET STRING (e.g.,
(e.g., the contents of a file) are input to the message digest the contents of a file) are input to the message digest calculation.
calculation. This has the advantage that the length of the content This has the advantage that the length of the content being signed
being signed need not be known in advance of the signature generation need not be known in advance of the signature generation process.
process.
Although the encapContentInfo eContent OCTET STRING tag and length Although the encapContentInfo eContent OCTET STRING tag and length
octets are not included in the message digest calculation, they are octets are not included in the message digest calculation, they are
protected by other means. The length octets are protected by the protected by other means. The length octets are protected by the
nature of the message digest algorithm since it is computationally nature of the message digest algorithm since it is computationally
infeasible to find any two distinct messages of any length that have infeasible to find any two distinct messages of any length that have
the same message digest. the same message digest.
5.5 Message Signature Generation Process 5.5 Message Signature Generation Process
skipping to change at page 13, line 37 skipping to change at page 13, line 51
value generated by the signer MUST be encoded as an OCTET STRING and value generated by the signer MUST be encoded as an OCTET STRING and
carried in the signature field. carried in the signature field.
5.6 Message Signature Verification Process 5.6 Message Signature Verification Process
The input to the signature verification process includes the result The input to the signature verification process includes the result
of the message digest calculation process and the signer's public of the message digest calculation process and the signer's public
key. The recipient MAY obtain the correct public key for the signer key. The recipient MAY obtain the correct public key for the signer
by any means, but the preferred method is from a certificate obtained by any means, but the preferred method is from a certificate obtained
from the SignedData certificates field. The selection and validation from the SignedData certificates field. The selection and validation
of the signer's public key may be based on certification path of the signer's public key MAY be based on certification path
validation (see [PROFILE]) as well as other external context, but is validation (see [PROFILE]) as well as other external context, but is
beyond the scope of this document. The details of the signature beyond the scope of this document. The details of the signature
verification depend on the signature algorithm employed. verification depend on the signature algorithm employed.
The recipient MUST NOT rely on any message digest values computed by The recipient MUST NOT rely on any message digest values computed by
the originator. If the signedData signerInfo includes the originator. If the SignedData signerInfo includes
signedAttributes, then the content message digest MUST be calculated signedAttributes, then the content message digest MUST be calculated
as described in section 5.4. For the signature to be valid, the as described in section 5.4. For the signature to be valid, the
message digest value calculated by the recipient MUST be the same as message digest value calculated by the recipient MUST be the same as
the value of the messageDigest attribute included in the the value of the messageDigest attribute included in the
signedAttributes of the signedData signerInfo. signedAttributes of the SignedData signerInfo.
If the SignedData signerInfo includes signedAttributes, then the
content-type attribute value MUST match the SignedData
encapContentInfo eContentType value.
6 Enveloped-data Content Type 6 Enveloped-data Content Type
The enveloped-data content type consists of an encrypted content of The enveloped-data content type consists of an encrypted content of
any type and encrypted content-encryption keys for one or more any type and encrypted content-encryption keys for one or more
recipients. The combination of the encrypted content and one recipients. The combination of the encrypted content and one
encrypted content-encryption key for a recipient is a "digital encrypted content-encryption key for a recipient is a "digital
envelope" for that recipient. Any type of content can be enveloped envelope" for that recipient. Any type of content can be enveloped
for an arbitrary number of recipients using any of the three key for an arbitrary number of recipients using any of the three key
management techniques for each recipient. management techniques for each recipient.
skipping to change at page 15, line 36 skipping to change at page 16, line 4
EnvelopedData ::= SEQUENCE { EnvelopedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo, encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
OriginatorInfo ::= SEQUENCE { OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL, certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
RecipientInfos ::= SET 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
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
The fields of type EnvelopedData have the following meanings: The fields of type EnvelopedData have the following meanings:
[*** NEW ***] version is the syntax version number. If [*** NEW ***] version is the syntax version number. The
originatorInfo is present, then version MUST be 2, unless the appropriate value depends on originatorInfo, RecipientInfo, and
certificate set in the originatorInfo contains version 2 attribute unprotectedAttrs. The version MUST be assigned as follows:
certificates, then version MUST be 3. If any of the RecipientInfo
structures included have a version other than 0, then the version IF ((originatorInfo is present) AND
MUST be 2. If unprotectedAttrs is present, then version MUST be (any version 2 attribute certificates are present)) OR
2. If originatorInfo is absent, all of the RecipientInfo (any RecipientInfo structures include pwri) OR
structures are version 0, and unprotectedAttrs is absent, then (any RecipientInfo structures include ori)
version MUST be 0. THEN version is 3
ELSE
IF (originatorInfo is present) OR
(unprotectedAttrs is present) OR
(any RecipientInfo structures are a version other than 0)
THEN version is 2
ELSE version is 0
originatorInfo optionally provides information about the originatorInfo optionally provides information about the
originator. It is present only if required by the key management originator. It is present only if required by the key management
algorithm. It MAY contain certificates and CRLs: algorithm. It may contain certificates and CRLs:
certs is a collection of certificates. certs MAY contain certs is a collection of certificates. certs may contain
originator certificates associated with several different key originator certificates associated with several different key
management algorithms. certs MAY also contain attribute management algorithms. certs may also contain attribute
certificates associated with the originator. The certificates certificates associated with the originator. The certificates
contained in certs are intended to be sufficient to build contained in certs are intended to be sufficient for all
certification paths from a recognized "root" or "top-level recipients to build certification paths from a recognized
certification authority" to all recipients. However, certs MAY "root" or "top-level certification authority." However, certs
contain more certificates than necessary, and there MAY be may contain more certificates than necessary, and there may be
certificates sufficient to make certification paths from two or certificates sufficient to make certification paths from two or
more independent top-level certification authorities. more independent top-level certification authorities.
Alternatively, certs MAY contain fewer certificates than Alternatively, certs may contain fewer certificates than
necessary, if it is expected that recipients have an alternate necessary, if it is expected that recipients have an alternate
means of obtaining necessary certificates (e.g., from a means of obtaining necessary certificates (e.g., from a
previous set of certificates). previous set of certificates).
crls is a collection of CRLs. It is intended that the set crls is a collection of CRLs. It is intended that the set
contain information sufficient to determine whether or not the contain information sufficient to determine whether or not the
certificates in the certs field are valid, but such certificates in the certs field are valid, but such
correspondence is not necessary. There MAY be more CRLs than correspondence is not necessary. There MAY be more CRLs than
necessary, and there MAY also be fewer CRLs than necessary. necessary, and there MAY also be fewer CRLs than necessary.
recipientInfos is a collection of per-recipient information. recipientInfos is a collection of per-recipient information.
There MUST be at least one element in the collection. There MUST be at least one element in the collection.
encryptedContentInfo is the encrypted content information. [*** encryptedContentInfo is the encrypted content information.
NEW ***] The field MUST be present.
unprotectedAttrs is a collection of attributes that are not unprotectedAttrs is a collection of attributes that are not
encrypted. The field is optional. Useful attribute types are encrypted. The field is optional. Useful attribute types are
defined in Section 11. defined in Section 11.
The fields of type EncryptedContentInfo have the following meanings: The fields of type EncryptedContentInfo have the following meanings:
contentType indicates the type of content. contentType indicates the type of content.
contentEncryptionAlgorithm identifies the content-encryption contentEncryptionAlgorithm identifies the content-encryption
algorithm, and any associated parameters, used to encrypt the algorithm, and any associated parameters, used to encrypt the
content. The content-encryption process is described in Section content. The content-encryption process is described in Section
6.3. The same content-encryption algorithm and content-encryption 6.3. The same content-encryption algorithm and content-encryption
key MUST be used for all recipients. key are used for all recipients.
encryptedContent is the result of encrypting the content. The encryptedContent is the result of encrypting the content. The
field is optional, and if the field is not present, its intended field is optional, and if the field is not present, its intended
value MUST be supplied by other means. value must be supplied by other means.
The recipientInfos field comes before the encryptedContentInfo field The recipientInfos field comes before the encryptedContentInfo field
so that an EnvelopedData value may be processed in a single pass. so that an EnvelopedData value may be processed in a single pass.
6.2 RecipientInfo Type 6.2 RecipientInfo Type
[*** NEW ***] Per-recipient information is represented in the type [*** NEW ***] Per-recipient information is represented in the type
RecipientInfo. RecipientInfo has a different format for each of the RecipientInfo. RecipientInfo has a different format for each of the
supported key management techniques. Any of the key management supported key management techniques. Any of the key management
techniques can be used for each recipient of the same encrypted techniques can be used for each recipient of the same encrypted
content. In all cases, the content-encryption key is transferred to content. In all cases, the content-encryption key is transferred to
one or more recipient in encrypted form. one or more recipient in encrypted form.
[*** NEW ***] All implementations MUST support the mandatory to [*** NEW ***] Since all implementations will not support every
implement key management algorithms are specified in [CMSALG], or its possible key management algorithm, all implementations MUST
successor. Use of a companion document enables the IETF to change gracefully handle unimplemented algorithms when they are encountered.
the mandatory to implement algorithms without updating this protocol For example, if a recipient receives a content-encryption key
specification. Since the companion algorithm specification will encrypted in their RSA public key using RSA-OAEP and the
undoubtedly change and implementation updates will certainly take implementation only supports RSA PKCS #1 v1.5, then a graceful
time, all implementations MUST gracefully handle unimplemented failure must be implemented.
algorithms when they are encountered.
[*** NEW ***] Implementations MUST support key transport, key [*** NEW ***] Implementations MUST support key transport, key
agreement, and previously distributed symmetric key-encryption keys, agreement, and previously distributed symmetric key-encryption keys,
as represented by ktri, kari, and kekri, respectively. as represented by ktri, kari, and kekri, respectively.
Implementations MAY support the password-based key management as Implementations MAY support the password-based key management as
represented by pwri. Implementations MAY support any other key represented by pwri. Implementations MAY support any other key
management technique as represented by ori. Since each recipient can management technique as represented by ori. Since each recipient can
employ a different key management technique and future specifications employ a different key management technique and future specifications
could define additional key management techniques, all could define additional key management techniques, all
implementations MUST gracefully handle unimplemented alternatives implementations MUST gracefully handle unimplemented alternatives
within the RecipientInfo CHOICE, all implementations MUST gracefully
handle unimplemented versions of otherwise supported alternatives
within the RecipientInfo CHOICE, and all implementations MUST within the RecipientInfo CHOICE, and all implementations MUST
gracefully handle unimplemented or unknown ori alternatives. gracefully handle unimplemented or unknown ori alternatives.
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo, kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo, pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo } ori [4] OtherRecipientInfo }
EncryptedKey ::= OCTET STRING EncryptedKey ::= OCTET STRING
6.2.1 KeyTransRecipientInfo Type 6.2.1 KeyTransRecipientInfo Type
Per-recipient information using key transport is represented in the Per-recipient information using key transport is represented in the
type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo
transfers the content-encryption key to one recipient. transfers the content-encryption key to one recipient.
KeyTransRecipientInfo ::= SEQUENCE { KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2 version CMSVersion, -- always set to 0 or 2
skipping to change at page 18, line 33 skipping to change at page 19, line 6
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 MUST be 0. is the CHOICE issuerAndSerialNumber, then the version MUST be 0.
If the RecipientIdentifier is subjectKeyIdentifier, then the If the RecipientIdentifier is subjectKeyIdentifier, then the
version MUST be 2. version MUST 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 the sender to protect the content-encryption key. The
RecipientIdentifier provides two alternatives for specifying the RecipientIdentifier provides two alternatives for specifying the
recipient's certificate, and thereby the recipient's public key. recipient's certificate, and thereby the recipient's public key.
The recipient's certificate MUST contain a key transport public The recipient's certificate must contain a key transport public
key. The content-encryption key is encrypted with the recipient's key. Therefore, a recipient X.509 version 3 certificate that
contains a key usage extension MUST assert the keyEncipherment
bit. The content-encryption key is encrypted with the recipient's
public key. The issuerAndSerialNumber alternative identifies the public key. The issuerAndSerialNumber alternative identifies the
recipient's certificate by the issuer's distinguished name and the recipient's certificate by the issuer's distinguished name and the
certificate serial number; the subjectKeyIdentifier identifies the certificate serial number; the subjectKeyIdentifier identifies the
recipient's certificate by the X.509 subjectKeyIdentifier recipient's certificate by the X.509 subjectKeyIdentifier
extension value. [*** NEW ***] Implementations MUST support both extension value. [*** NEW ***] For recipient processing,
alternatives for specifying the recipient's certificate. implementations MUST support both of these alternatives for
specifying the recipient's certificate; and for sender processing,
implementations MUST support at least one of these alternatives.
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.
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 that transfer the content-encryption key to one or more recipients that
uses the same key agreement algorithm and domain parameters for that use the same key agreement algorithm and domain parameters for that
algorithm. algorithm.
KeyAgreeRecipientInfo ::= SEQUENCE { KeyAgreeRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 3 version CMSVersion, -- always set to 3
originator [0] EXPLICIT OriginatorIdentifierOrKey, originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys } recipientEncryptedKeys RecipientEncryptedKeys }
OriginatorIdentifierOrKey ::= CHOICE { OriginatorIdentifierOrKey ::= CHOICE {
skipping to change at page 20, line 20 skipping to change at page 20, line 42
the X.509 subjectKeyIdentifier extension value. The originatorKey the X.509 subjectKeyIdentifier extension value. The originatorKey
alternative includes the algorithm identifier and sender's key alternative includes the algorithm identifier and sender's key
agreement public key. This alternative permits originator agreement public key. This alternative permits originator
anonymity since the public key is not certified. [*** NEW ***] anonymity since the public key is not certified. [*** NEW ***]
Implementations MUST support all three alternatives for specifying Implementations MUST support all three alternatives for specifying
the sender's public key. the sender's public key.
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. [*** NEW ***] Implementations SHOULD support UKM pairwise key. [*** NEW ***] Implementations MUST support
processing. Implementations that do not process UKMs MUST recipient processing of a KeyAgreeRecipientInfo SEQUENCE that
gracefully handle the presence of UKMs. includes a ukm field. Implementations that do not support key
agreement algorithms that make use of UKMs MUST gracefully handle
the presence of UKMs.
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 with 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.
recipientEncryptedKeys includes a recipient identifier and 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-encryption key. The recipient's certificate MUST pairwise key-encryption key. The recipient's certificate must
contain a key agreement public key. The content-encryption key is contain a key agreement public key. Therefore, a recipient X.509
version 3 certificate that contains a key usage extension MUST
assert the keyAgreement bit. The content-encryption key is
encrypted in the pairwise key-encryption key. The encrypted in the pairwise key-encryption 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-encryption key generated using the key key in the pairwise key-encryption key generated using the key
agreement algorithm. [*** NEW ***] Implementations MUST support agreement algorithm. [*** NEW ***] Implementations MUST support
both alternatives for specifying the recipient's certificate. both alternatives for specifying the recipient's certificate.
The fields of type RecipientKeyIdentifier have the following The fields of type RecipientKeyIdentifier have the following
skipping to change at page 22, line 14 skipping to change at page 22, line 38
other is optional. When present, this field contains additional other is optional. When present, this field contains additional
information used by the recipient to determine the key-encryption information used by the recipient to determine the key-encryption
key used by the sender. key used by the sender.
6.2.4 [*** NEW ***] PasswordRecipientInfo Type 6.2.4 [*** NEW ***] PasswordRecipientInfo Type
Recipient information using a password or shared secret value is Recipient information using a password or shared secret value is
represented in the type PasswordRecipientInfo. Each instance of represented in the type PasswordRecipientInfo. Each instance of
PasswordRecipientInfo will transfer the content-encryption key to one PasswordRecipientInfo will transfer the content-encryption key to one
or more recipients who posses the password or shared secret value. or more recipients who possess the password or shared secret value.
The PasswordRecipientInfo Type is specified in RFC <TBD> [PWRI]. The The PasswordRecipientInfo Type is specified in RFC <TBD> [PWRI]. The
PasswordRecipientInfo structure is repeated here for completeness. PasswordRecipientInfo structure is repeated here for completeness.
PasswordRecipientInfo ::= SEQUENCE { PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0 version CMSVersion, -- Always set to 0
keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
OPTIONAL, OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
skipping to change at page 22, line 44 skipping to change at page 23, line 20
keyEncryptionAlgorithm identifies the encryption algorithm, and keyEncryptionAlgorithm identifies the encryption algorithm, and
any associated parameters, used to encrypt the content-encryption any associated parameters, used to encrypt the content-encryption
key with the key-encryption key. key with the key-encryption key.
encryptedKey is the result of encrypting the content-encryption encryptedKey is the result of encrypting the content-encryption
key with the key-encryption key. key with the key-encryption key.
6.2.5 [*** NEW ***] OtherRecipientInfo Type 6.2.5 [*** NEW ***] OtherRecipientInfo Type
Recipient information for key additional key management techniques Recipient information for additional key management techniques are
are represented in the type OtherRecipientInfo. The represented in the type OtherRecipientInfo. The OtherRecipientInfo
OtherRecipientInfo type allows key management techniques beyond key type allows key management techniques beyond key transport, key
transport, key agreement, previously distributed symmetric key- agreement, previously distributed symmetric key-encryption keys, and
encryption keys, and password-based key management to be specified in password-based key management to be specified in future documents.
future documents. An object identifier MUST uniquely identify such An object identifier uniquely identifies such key management
key management techniques. techniques.
OtherRecipientInfo ::= SEQUENCE { OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER, oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType } oriValue ANY DEFINED BY oriType }
The fields of type OtherRecipientInfo have the following meanings: The fields of type OtherRecipientInfo have the following meanings:
oriType identifies the key management technique. oriType identifies the key management technique.
oriValue contains the protocol data elements needed by a recipient oriValue contains the protocol data elements needed by a recipient
using the identified key management technique. using the identified key management technique.
skipping to change at page 23, line 24 skipping to change at page 23, line 49
The content-encryption key for the desired content-encryption The content-encryption key for the desired content-encryption
algorithm is randomly generated. The data to be protected is padded algorithm is randomly generated. The data to be protected is padded
as described below, then the padded data is encrypted using the as described below, then the padded data is encrypted using the
content-encryption key. The encryption operation maps an arbitrary content-encryption key. The encryption operation maps an arbitrary
string of octets (the data) to another string of octets (the string of octets (the data) to another string of octets (the
ciphertext) under control of a content-encryption key. The encrypted ciphertext) under control of a content-encryption key. The encrypted
data is included in the envelopedData encryptedContentInfo data is included in the envelopedData encryptedContentInfo
encryptedContent OCTET STRING. encryptedContent OCTET STRING.
The input to the content-encryption process is the "value" of the
content being enveloped. Only the value octets of the envelopedData
encryptedContentInfo encryptedContent OCTET STRING are encrypted; the
OCTET STRING tag and length octets are not encrypted.
Some content-encryption algorithms assume the input length is a Some content-encryption algorithms assume the input length is a
multiple of k octets, where k is greater than one. For such multiple of k octets, where k is greater than one. For such
algorithms, the input shall be padded at the trailing end with algorithms, the input shall be padded at the trailing end with
k-(lth mod k) octets all having value k-(lth mod k), where lth is k-(lth mod k) octets all having value k-(lth mod k), where lth is
the length of the input. In other words, the input is padded at the length of the input. In other words, the input is padded at
the trailing end with one of the following strings: the trailing end with one of the following strings:
01 -- if lth mod k = k-1 01 -- if lth mod k = k-1
02 02 -- if lth mod k = k-2 02 02 -- if lth mod k = k-2
. .
skipping to change at page 24, line 6 skipping to change at page 24, line 25
including input values that are already a multiple of the block size, including input values that are already a multiple of the block size,
and no padding string is a suffix of another. This padding method is and no padding string is a suffix of another. This padding method is
well defined if and only if k is less than 256. well defined if and only if k is less than 256.
6.4 Key-encryption Process 6.4 Key-encryption Process
The input to the key-encryption process -- the value supplied to the The input to the key-encryption process -- the value supplied to the
recipient's key-encryption algorithm --is just the "value" of the recipient's key-encryption algorithm --is just the "value" of the
content-encryption key. content-encryption key.
Any of the three key management techniques can be used for each Any of the aforementioned key management techniques can be used for
recipient of the same encrypted content. each recipient of the same encrypted content.
7 Digested-data Content Type 7 Digested-data Content Type
The digested-data content type consists of content of any type and a The digested-data content type consists of content of any type and a
message digest of the content. message digest of the content.
Typically, the digested-data content type is used to provide content Typically, the digested-data content type is used to provide content
integrity, and the result generally becomes an input to the integrity, and the result generally becomes an input to the
enveloped-data content type. enveloped-data content type.
skipping to change at page 27, line 10 skipping to change at page 27, line 29
The authenticated-data content type shall have ASN.1 type The authenticated-data content type shall have ASN.1 type
AuthenticatedData: AuthenticatedData:
AuthenticatedData ::= SEQUENCE { AuthenticatedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm, macAlgorithm MessageAuthenticationCodeAlgorithm,
digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode, mac MessageAuthenticationCode,
unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
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 MUST be 0. [*** NEW ***] version is the syntax version number. The version
MUST be assigned as follows:
IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present))
THEN version is 1
ELSE version is 0
originatorInfo optionally provides information about the originatorInfo optionally provides information about the
originator. It is present only if required by the key management originator. It is present only if required by the key
algorithm. It MAY contain certificates, attribute certificates, management algorithm. It MAY contain certificates, attribute
and CRLs, as defined in Section 6.1. certificates, and CRLs, as defined in Section 6.1.
recipientInfos is a collection of per-recipient information, as recipientInfos is a collection of per-recipient information, as
defined in Section 6.1. There MUST be at least one element in the defined in Section 6.1. There MUST be at least one element in
collection. the collection.
macAlgorithm is a message authentication code (MAC) algorithm macAlgorithm is a message authentication code (MAC) algorithm
identifier. It identifies the MAC algorithm, along with any identifier. It identifies the MAC algorithm, along with any
associated parameters, used by the originator. Placement of the associated parameters, used by the originator. Placement of
macAlgorithm field facilitates one-pass processing by the the macAlgorithm field facilitates one-pass processing by the
recipient. recipient.
digestAlgorithm identifies the message digest algorithm, and any digestAlgorithm identifies the message digest algorithm, and
associated parameters, used to compute a message digest on the any associated parameters, used to compute a message digest on
encapsulated content if authenticated attributes are present. The the encapsulated content if authenticated attributes are
message digesting process is described in Section 9.2. Placement present. The message digesting process is described in Section
of the digestAlgorithm field facilitates one-pass processing by 9.2. Placement of the digestAlgorithm field facilitates one-
the recipient. If the digestAlgorithm field is present, then the pass processing by the recipient. If the digestAlgorithm field
authenticatedAttributes field MUST also be present. is present, then the authAttrs field MUST also be present.
encapContentInfo is the content that is authenticated, as defined encapContentInfo is the content that is authenticated, as
in section 5.2. defined in section 5.2.
authenticatedAttributes is a collection of authenticated authAttrs is a collection of authenticated attributes. The
attributes. The authenticatedAttributes structure is optional, authAttrs structure is optional, but it MUST be present if the
but it MUST be present if the content type of the content type of the EncapsulatedContentInfo value being
EncapsulatedContentInfo value being authenticated is not id-data. authenticated is not id-data. If the authAttrs field is
If the authenticatedAttributes field is present, then the present, then the digestAlgorithm field MUST also be present.
digestAlgorithm field MUST also be present. Each Each attribute in the SET MUST be DER encoded. Useful
AuthenticatedAttribute in the SET MUST be DER encoded. Useful attribute types are defined in Section 11. If the authAttrs
attribute types are defined in Section 11. If the field is present, it MUST contain, at a minimum, the following
authenticatedAttributes field is present, it MUST contain, at a 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 authenticated. of the EncapsulatedContentInfo value being authenticated.
Section 11.1 defines the content-type attribute. Section 11.1 defines the content-type attribute.
A message-digest attribute, having as its value the message A message-digest attribute, having as its value the message
digest of the content. Section 11.2 defines the message-digest digest of the content. Section 11.2 defines the message-digest
attribute. attribute.
mac is the message authentication code. mac is the message authentication code.
unauthenticatedAttributes is a collection of attributes that are unauthAttrs is a collection of attributes that are not
not authenticated. The field is optional. To date, no attributes authenticated. The field is optional. To date, no attributes
have been defined for use as unauthenticated attributes, but other have been defined for use as unauthenticated attributes, but other
useful attribute types are defined in Section 11. 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 The MAC calculation process computes a message authentication code
(MAC) on either the message being authenticated or a message digest (MAC) on either the message being authenticated or a message digest
of message being authenticated together with the originator's of message being authenticated together with the originator's
authenticated attributes. authenticated attributes.
If authenticatedAttributes field is absent, the input to the MAC If authAttrs field is absent, the input to the MAC calculation
calculation process is the value of the encapContentInfo eContent process is the value of the encapContentInfo eContent OCTET STRING.
OCTET STRING. Only the octets comprising the value of the eContent Only the octets comprising the value of the eContent OCTET STRING are
OCTET STRING are input to the MAC algorithm; the tag and the length input to the MAC algorithm; the tag and the length octets are
octets are omitted. This has the advantage that the length of the omitted. This has the advantage that the length of the content being
content being authenticated need not be known in advance of the MAC authenticated need not be known in advance of the MAC generation
generation process. process.
If authenticatedAttributes field is present, the content-type If authAttrs field is present, the content-type attribute (as
attribute (as described in Section 11.1) and the message-digest described in Section 11.1) and the message-digest attribute (as
attribute (as described in section 11.2) MUST be included, and the described in section 11.2) MUST be included, and the input to the MAC
input to the MAC calculation process is the DER encoding of calculation process is the DER encoding of authAttrs. A separate
authenticatedAttributes. A separate encoding of the encoding of the authAttrs field is performed for message digest
authenticatedAttributes field is performed for message digest calculation. The IMPLICIT [2] tag in the authAttrs field is not used
calculation. The IMPLICIT [2] tag in the authenticatedAttributes for the DER encoding, rather an EXPLICIT SET OF tag is used. That
field is not used for the DER encoding, rather an EXPLICIT SET OF tag is, the DER encoding of the SET OF tag, rather than of the IMPLICIT
is used. That is, the DER encoding of the SET OF tag, rather than of [2] tag, is to be included in the message digest calculation along
the IMPLICIT [2] tag, is to be included in the message digest with the length and content octets of the authAttrs value.
calculation along with the length and content octets of the
authenticatedAttributes value.
The message digest calculation process computes a message digest on The message digest calculation process computes a message digest on
the content being authenticated. The initial input to the message the content being authenticated. The initial input to the message
digest calculation process is the "value" of the encapsulated content digest calculation process is the "value" of the encapsulated content
being authenticated. Specifically, the input is the encapContentInfo being authenticated. Specifically, the input is the encapContentInfo
eContent OCTET STRING to which the authentication process is applied. eContent OCTET STRING to which the authentication process is applied.
Only the octets comprising the value of the encapContentInfo eContent Only the octets comprising the value of the encapContentInfo eContent
OCTET STRING are input to the message digest algorithm, not the tag OCTET STRING are input to the message digest algorithm, not the tag
or the length octets. This has the advantage that the length of the or the length octets. This has the advantage that the length of the
content being authenticated need not be known in advance. Although content being authenticated need not be known in advance. Although
skipping to change at page 29, line 36 skipping to change at page 30, line 10
structure. The details of MAC calculation depend on the MAC structure. The details of MAC calculation depend on the MAC
algorithm employed (e.g., HMAC). The object identifier, along with algorithm employed (e.g., HMAC). The object identifier, along with
any parameters, that specifies the MAC algorithm employed by the any parameters, that specifies the MAC algorithm employed by the
originator is carried in the macAlgorithm field. The MAC value originator is carried in the macAlgorithm field. The MAC value
generated by the originator is encoded as an OCTET STRING and carried generated by the originator is encoded as an OCTET STRING and carried
in the mac field. in the mac field.
9.3 MAC Verification 9.3 MAC Verification
The input to the MAC verification process includes the input data The input to the MAC verification process includes the input data
(determined based on the presence or absence of the (determined based on the presence or absence of the authAttrs field,
authenticatedAttributes field, as defined in 9.2), and the as defined in 9.2), and the authentication key conveyed in
authentication key conveyed in recipientInfo. The details of the MAC recipientInfo. The details of the MAC verification process depend on
verification process depend on the MAC algorithm employed. the MAC algorithm employed.
The recipient MUST NOT rely on any MAC values or message digest The recipient MUST NOT rely on any MAC values or message digest
values computed by the originator. The content is authenticated as values computed by the originator. The content is authenticated as
described in section 9.2. If the originator includes authenticated described in section 9.2. If the originator includes authenticated
attributes, then the content of the authenticatedAttributes is attributes, then the content of the authAttrs is authenticated as
authenticated as described in section 9.2. For authentication to described in section 9.2. For authentication to succeed, the message
succeed, the message MAC value calculated by the recipient MUST be MAC value calculated by the recipient MUST be the same as the value
the same as the value of the mac field. Similarly, for of the mac field. Similarly, for authentication to succeed when the
authentication to succeed when the authenticatedAttributes field is authAttrs field is present, the content message digest value
present, the content message digest value calculated by the recipient calculated by the recipient MUST be the same as the message digest
MUST be the same as the message digest value included in the value included in the authAttrs message-digest attribute.
authenticatedAttributes message-digest attribute.
If the AuthenticatedData includes authAttrs, then the content-type
attribute value MUST match the AuthenticatedData encapContentInfo
eContentType value.
10 Useful Types 10 Useful Types
This section is divided into two parts. The first part defines This section is divided into two parts. The first part defines
algorithm identifiers, and the second part defines other useful algorithm identifiers, and the second part defines other useful
types. types.
10.1 Algorithm Identifier Types 10.1 Algorithm Identifier Types
All of the algorithm identifiers have the same type: All of the algorithm identifiers have the same type:
AlgorithmIdentifier. The definition of AlgorithmIdentifier is AlgorithmIdentifier. The definition of AlgorithmIdentifier is
imported from X.509 [X.509-88]. imported from X.509 [X.509-88].
[*** NEW ***] There are many alternatives for each algorithm type. There are many alternatives for each algorithm type.
For each of these five types, CMS implementations MUST support the
mandatory to implement algorithms specified in [CMSALG], or its
successor.
10.1.1 DigestAlgorithmIdentifier 10.1.1 DigestAlgorithmIdentifier
The DigestAlgorithmIdentifier type identifies a message-digest The DigestAlgorithmIdentifier type identifies a message-digest
algorithm. Examples include SHA-1, MD2, and MD5. A message-digest algorithm. Examples include SHA-1, MD2, and MD5. A message-digest
algorithm maps an octet string (the message) to another octet string algorithm maps an octet string (the message) to another octet string
(the message digest). (the message digest).
DigestAlgorithmIdentifier ::= AlgorithmIdentifier DigestAlgorithmIdentifier ::= AlgorithmIdentifier
skipping to change at page 31, line 28 skipping to change at page 31, line 50
content-encryption key. The decryption operation is the inverse of content-encryption key. The decryption operation is the inverse of
the encryption operation. Context determines which operation is the encryption operation. Context determines which operation is
intended. intended.
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
10.1.5 MessageAuthenticationCodeAlgorithm 10.1.5 MessageAuthenticationCodeAlgorithm
The MessageAuthenticationCodeAlgorithm type identifies a message The MessageAuthenticationCodeAlgorithm type identifies a message
authentication code (MAC) algorithm. Examples include DES-MAC and authentication code (MAC) algorithm. Examples include DES-MAC and
HMAC. A MAC algorithm supports generation and verification HMAC-SHA-1. A MAC algorithm supports generation and verification
operations. The MAC generation and verification operations use the operations. The MAC generation and verification operations use the
same symmetric key. Context determines which operation is intended. same symmetric key. Context determines which operation is intended.
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
10.1.6 [*** NEW ***] KeyDerivationAlgorithmIdentifier 10.1.6 [*** NEW ***] KeyDerivationAlgorithmIdentifier
The KeyDerivationAlgorithmIdentifier type is specified in RFC <TBD> The KeyDerivationAlgorithmIdentifier type is specified in RFC <TBD>
[PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated [PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated
here for completeness. here for completeness.
skipping to change at page 32, line 6 skipping to change at page 32, line 28
This section defines types that are used other places in the This section defines types that are used other places in the
document. The types are not listed in any particular order. document. The types are not listed in any particular order.
10.2.1 CertificateRevocationLists 10.2.1 CertificateRevocationLists
The CertificateRevocationLists type gives a set of certificate The CertificateRevocationLists type gives a set of certificate
revocation lists (CRLs). It is intended that the set contain revocation lists (CRLs). It is intended that the set contain
information sufficient to determine whether the certificates and information sufficient to determine whether the certificates and
attribute certificates with which the set is associated are revoked. attribute certificates with which the set is associated are revoked.
However, there MAY be more CRLs than necessary or there MAY be fewer However, there may be more CRLs than necessary or there MAY be fewer
CRLs than necessary. CRLs than necessary.
The CertificateList MAY contain a CRL, an Authority Revocation List The CertificateList may contain a CRL, an Authority Revocation List
(ARL), a Delta Revocation List, or an Attribute Certificate (ARL), a Delta CRL, or an Attribute Certificate Revocation List. All
Revocation List. All of these lists share a common syntax. of these lists share a common syntax.
CRLs are specified in X.509 [X.509-97], and they are profiled for use CRLs are specified in X.509 [X.509-97], and they are profiled for use
in the Internet in RFC 2459 [PROFILE]. in the Internet in RFC 2459 [PROFILE].
The definition of CertificateList is imported from X.509. The definition of CertificateList is imported from X.509.
CertificateRevocationLists ::= SET OF CertificateList CertificateRevocationLists ::= SET OF CertificateList
10.2.2 CertificateChoices 10.2.2 CertificateChoices
skipping to change at page 33, line 6 skipping to change at page 33, line 27
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2 } -- See X.509 v2AttrCert [2] IMPLICIT AttributeCertificateV2 } -- See X.509
10.2.3 CertificateSet 10.2.3 CertificateSet
The CertificateSet type provides a set of certificates. It is The CertificateSet type provides a set of certificates. It is
intended that the set be sufficient to contain chains from a intended that the set be sufficient to contain chains from a
recognized "root" or "top-level certification authority" to all of recognized "root" or "top-level certification authority" to all of
the sender certificates with which the set is associated. However, the sender certificates with which the set is associated. However,
there MAY be more certificates than necessary, or there MAY be fewer there may be more certificates than necessary, or there MAY be fewer
than necessary. than necessary.
The precise meaning of a "chain" is outside the scope of this The precise meaning of a "chain" is outside the scope of this
document. Some applications MAY impose upper limits on the length of document. Some applications may impose upper limits on the length of
a chain; others MAY enforce certain relationships between the a chain; others may enforce certain relationships between the
subjects and issuers of certificates within a chain. subjects and issuers of certificates within a chain.
CertificateSet ::= SET OF CertificateChoices CertificateSet ::= SET OF CertificateChoices
10.2.4 IssuerAndSerialNumber 10.2.4 IssuerAndSerialNumber
The IssuerAndSerialNumber type identifies a certificate, and thereby The IssuerAndSerialNumber type identifies a certificate, and thereby
an entity and a public key, by the distinguished name of the an entity and a public key, by the distinguished name of the
certificate issuer and an issuer-specific certificate serial number. certificate issuer and an issuer-specific certificate serial number.
skipping to change at page 34, line 36 skipping to change at page 35, line 4
Additional attributes are defined in many places, notably the S/MIME Additional attributes are defined in many places, notably the S/MIME
Version 3 Message Specification [MSG] and the Enhanced Security Version 3 Message Specification [MSG] and the Enhanced Security
Services for S/MIME [ESS], which also include recommendations on the Services for S/MIME [ESS], which also include recommendations on the
placement of these attributes. placement of these attributes.
11.1 Content Type 11.1 Content Type
[*** NEW ***] The content-type attribute type specifies the content [*** NEW ***] The content-type attribute type specifies the content
type of the ContentInfo within signed-data or authenticated-data. type of the ContentInfo within signed-data or authenticated-data.
The content-type attribute type MUST be present whenever signed The content-type attribute type MUST be present whenever signed
attributes are present in signed-data or authenticated attributes attributes are present in signed-data or authenticated attributes
present in authenticated-data. present in authenticated-data. The content-type attribute value MUST
match the encapContentInfo eContentType value in the signed-data or
authenticated-data.
[*** NEW ***] The content-type attribute MUST be a signed attribute [*** NEW ***] The content-type attribute MUST be a signed attribute
or an authenticated attribute; it MUST NOT be an unsigned attribute, or an authenticated attribute; it MUST NOT be an unsigned attribute,
unauthenticated attribute, or unprotected attribute. unauthenticated attribute, or unprotected attribute.
The following object identifier identifies the content-type The following object identifier identifies the content-type
attribute: attribute:
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
Content-type attribute values have ASN.1 type ContentType: Content-type attribute values have ASN.1 type ContentType:
ContentType ::= OBJECT IDENTIFIER ContentType ::= OBJECT IDENTIFIER
A content-type attribute MUST have a single attribute value, even
though the syntax is defined as a SET OF AttributeValue. There MUST Even though the syntax is defined as a SET OF AttributeValue, a
NOT be zero or multiple instances of AttributeValue present. content-type attribute MUST have a single attribute value; zero or
multiple instances of AttributeValue are not permitted.
The SignedAttributes and AuthAttributes syntaxes are each defined as The SignedAttributes and AuthAttributes syntaxes are each defined as
a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT
include multiple instances of the content-type attribute. Similarly, include multiple instances of the content-type attribute. Similarly,
the AuthAttributes in an AuthenticatedData MUST NOT include multiple the AuthAttributes in an AuthenticatedData MUST NOT include multiple
instances of the content-type attribute. instances of the content-type attribute.
11.2 Message Digest 11.2 Message Digest
The message-digest attribute type specifies the message digest of the The message-digest attribute type specifies the message digest of the
skipping to change at page 35, line 48 skipping to change at page 36, line 20
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
Message-digest attribute values have ASN.1 type MessageDigest: Message-digest attribute values have ASN.1 type MessageDigest:
MessageDigest ::= OCTET STRING MessageDigest ::= OCTET STRING
A message-digest attribute MUST have a single attribute value, even A message-digest attribute MUST have a single attribute value, even
though the syntax is defined as a SET OF AttributeValue. There MUST though the syntax is defined as a SET OF AttributeValue. There MUST
NOT be zero or multiple instances of AttributeValue present. NOT be zero or multiple instances of AttributeValue present.
The SignedAttributes syntax is defined as a SET OF Attributes. The The SignedAttributes syntax and AuthAttributes syntax are each
SignedAttributes in a signerInfo MUST NOT include multiple instances defined as a SET OF Attributes. The SignedAttributes in a signerInfo
of the message-digest attribute. MUST include only one instance of the message-digest attribute.
Similarly, the AuthAttributes in an AuthenticatedData MUST include
only one instance of the message-digest attribute.
11.3 Signing Time 11.3 Signing Time
The signing-time attribute type specifies the time at which the The signing-time attribute type specifies the time at which the
signer (purportedly) performed the signing process. The signing-time signer (purportedly) performed the signing process. The signing-time
attribute type is intended for use in signed-data. attribute type is intended for use in signed-data.
[*** NEW ***] The signing-time attribute MAY be a signed attribute; [*** NEW ***] The signing-time attribute MUST be a signed attribute
it MUST NOT be an unsigned attribute, authenticated attribute, or an authenticated attribute; it MUST NOT be an unsigned attribute,
unauthenticated attribute, or unprotected attribute. unauthenticated attribute, or unprotected attribute.
The following object identifier identifies the signing-time The following object identifier identifies the signing-time
attribute: attribute:
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
Signing-time attribute values have ASN.1 type SigningTime: Signing-time attribute values have ASN.1 type SigningTime:
skipping to change at page 36, line 50 skipping to change at page 37, line 23
MUST be determined as follows: MUST be determined as follows:
Where YY is greater than or equal to 50, the year MUST be Where YY is greater than or equal to 50, the year MUST be
interpreted as 19YY; and interpreted as 19YY; and
Where YY is less than 50, the year MUST be interpreted as 20YY. Where YY is less than 50, the year MUST be interpreted as 20YY.
GeneralizedTime values MUST be expressed in Greenwich Mean Time GeneralizedTime values MUST be expressed in Greenwich Mean Time
(Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ),
even where the number of seconds is zero. GeneralizedTime values even where the number of seconds is zero. GeneralizedTime values
MUST not include fractional seconds. MUST NOT include fractional seconds.
A signing-time attribute MUST have a single attribute value, even A signing-time attribute MUST have a single attribute value, even
though the syntax is defined as a SET OF AttributeValue. There MUST though the syntax is defined as a SET OF AttributeValue. There MUST
not be zero or multiple instances of AttributeValue present. NOT be zero or multiple instances of AttributeValue present.
The SignedAttributes syntax is defined as a SET OF Attributes. The The SignedAttributes syntax and the AuthAttributes syntax are each
SignedAttributes in a signerInfo MUST not include multiple instances defined as a SET OF Attributes. The SignedAttributes in a signerInfo
of the signing-time attribute. MUST NOT include multiple instances of the signing-time attribute.
Similarly, the AuthAttributes in an AuthenticatedData MUST NOT
include multiple instances of the signing-time attribute.
No requirement is imposed concerning the correctness of the signing No requirement is imposed concerning the correctness of the signing
time, and acceptance of a purported signing time is a matter of a time, and acceptance of a purported signing time is a matter of a
recipient's discretion. It is expected, however, that some signers, recipient's discretion. It is expected, however, that some signers,
such as time-stamp servers, will be trusted implicitly. such as time-stamp servers, will be trusted implicitly.
11.4 Countersignature 11.4 Countersignature
The countersignature attribute type specifies one or more signatures The countersignature attribute type specifies one or more signatures
on the contents octets of the DER encoding of the signatureValue on the contents octets of the DER encoding of the signatureValue
skipping to change at page 37, line 38 skipping to change at page 38, line 13
The following object identifier identifies the countersignature The following object identifier identifies the countersignature
attribute: attribute:
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }
Countersignature attribute values have ASN.1 type Countersignature: Countersignature attribute values have ASN.1 type Countersignature:
Countersignature ::= SignerInfo Countersignature ::= SignerInfo
Countersignature values have the same meaning as SignerInfo values [*** NEW ***] Countersignature values have the same meaning as
for ordinary signatures, except that: SignerInfo values for ordinary signatures, except that:
1. The signedAttributes field MUST contain a message-digest 1. The signedAttributes field MUST NOT contain a content-type
attribute if it contains any other attributes, but need not attribute; there is no content type for countersignatures.
contain a content-type attribute, as there is no content type for
countersignatures.
2. The input to the message-digesting process is the contents 2. The signedAttributes field MUST contain a message-digest
attribute if it contains any other attributes.
3. The input to the message-digesting process is the contents
octets of the DER encoding of the signatureValue field of the octets of the DER encoding of the signatureValue field of the
SignerInfo value with which the attribute is associated. SignerInfo value with which the attribute is associated.
A countersignature attribute can have multiple attribute values. The A countersignature attribute can have multiple attribute values. The
syntax is defined as a SET OF AttributeValue, and there MUST be one syntax is defined as a SET OF AttributeValue, and there MUST be one
or more instances of AttributeValue present. or more instances of AttributeValue present.
The UnsignedAttributes syntax is defined as a SET OF Attributes. The The UnsignedAttributes syntax is defined as a SET OF Attributes. The
UnsignedAttributes in a signerInfo MAY include multiple instances of UnsignedAttributes in a signerInfo may include multiple instances of
the countersignature attribute. the countersignature attribute.
A countersignature, since it has type SignerInfo, can itself contain A countersignature, since it has type SignerInfo, can itself contain
a countersignature attribute. Thus, it is possible to construct a countersignature attribute. Thus, it is possible to construct
arbitrarily long series of countersignatures. arbitrarily long series of countersignatures.
Appendix A: CMS ASN.1 Module Appendix A: CMS ASN.1 Module
CryptographicMessageSyntax CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
skipping to change at page 41, line 15 skipping to change at page 41, line 15
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo, encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
OriginatorInfo ::= SEQUENCE { OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL, certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }
RecipientInfos ::= SET OF RecipientInfo -- [*** OLD ***]
-- RecipientInfos ::= SET OF RecipientInfo
-- [*** NEW ***]
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE { EncryptedContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING EncryptedContent ::= OCTET STRING
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
skipping to change at page 43, line 17 skipping to change at page 43, line 22
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
digest Digest } digest Digest }
Digest ::= OCTET STRING Digest ::= OCTET STRING
EncryptedData ::= SEQUENCE { EncryptedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
encryptedContentInfo EncryptedContentInfo, encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
-- [*** OLD ***]
-- AuthenticatedData ::= SEQUENCE {
-- version CMSVersion,
-- originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
-- recipientInfos RecipientInfos,
-- macAlgorithm MessageAuthenticationCodeAlgorithm,
-- digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
-- encapContentInfo EncapsulatedContentInfo,
-- authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL,
-- mac MessageAuthenticationCode,
-- unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL }
-- [*** NEW ***]
AuthenticatedData ::= SEQUENCE { AuthenticatedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
macAlgorithm MessageAuthenticationCodeAlgorithm, macAlgorithm MessageAuthenticationCodeAlgorithm,
digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode, mac MessageAuthenticationCode,
unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
AuthAttributes ::= SET SIZE (1..MAX) OF Attribute AuthAttributes ::= SET SIZE (1..MAX) OF Attribute
UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute
MessageAuthenticationCode ::= OCTET STRING MessageAuthenticationCode ::= OCTET STRING
DigestAlgorithmIdentifier ::= AlgorithmIdentifier DigestAlgorithmIdentifier ::= AlgorithmIdentifier
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
skipping to change at page 44, line 30 skipping to change at page 44, line 48
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) }
UserKeyingMaterial ::= OCTET STRING UserKeyingMaterial ::= OCTET STRING
UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial
OtherKeyAttribute ::= SEQUENCE { OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER, keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL } keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
-- CMS Attributes -- The CMS Attributes
MessageDigest ::= OCTET STRING MessageDigest ::= OCTET STRING
SigningTime ::= Time SigningTime ::= Time
Time ::= CHOICE { Time ::= CHOICE {
utcTime UTCTime, utcTime UTCTime,
generalTime GeneralizedTime } generalTime GeneralizedTime }
Countersignature ::= SignerInfo Countersignature ::= SignerInfo
-- Attribute Object Identifiers -- Attribute Object Identifiers
skipping to change at page 50, line 26 skipping to change at page 50, line 26
and then the Triple-DES key can be used to decrypt the content. and then the Triple-DES key can be used to decrypt the content.
Therefore, implementers must ensure that key-encryption algorithms Therefore, implementers must ensure that key-encryption algorithms
are as strong or stronger than content-encryption algorithms. are as strong or stronger than content-encryption algorithms.
Section 12.6 specifies key wrap algorithms used to encrypt a Triple- Section 12.6 specifies key wrap algorithms used to encrypt a Triple-
DES [3DES] content-encryption key with a Triple-DES key-encryption DES [3DES] content-encryption key with a Triple-DES key-encryption
key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key- key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key-
encryption key. The key wrap algorithms make use of CBC mode encryption key. The key wrap algorithms make use of CBC mode
[MODES]. These key wrap algorithms have been reviewed for use with [MODES]. These key wrap algorithms have been reviewed for use with
Triple and RC2. They have not been reviewed for use with other Triple and RC2. They have not been reviewed for use with other
cryptographic modes or other encryption algorithms. Therefore, if a cryptographic modes or other encryption algorithms. Therefore, if an
CMS implementation wishes to support ciphers in addition to Triple- implementation of the CMS wishes to support ciphers in addition to
DES or RC2, then additional key wrap algorithms need to be defined to Triple-DES or RC2, then additional key wrap algorithms need to be
support the additional ciphers. defined to support the additional ciphers.
Implementers should be aware that cryptographic algorithms become Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptoanalysis techniques are developed and weaker with time. As new cryptoanalysis techniques are developed and
computing performance improves, the work factor to break a particular computing performance improves, the work factor to break a particular
cryptographic algorithm will reduce. Therefore, cryptographic cryptographic algorithm will reduce. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms algorithm implementations should be modular allowing new algorithms
to be readily inserted. That is, implementers should be prepared for to be readily inserted. That is, implementers should be prepared for
the set of mandatory to implement algorithms to change over time. the set of mandatory to implement algorithms to change over time.
The countersignature unauthenticated attribute includes a digital The countersignature unsigned attribute includes a digital signature
signature that is computed on the content signature value, thus the that is computed on the content signature value, thus the
countersigning process need not know the original signed content. countersigning process need not know the original signed content.
This structure permits implementation efficiency advantages; however, This structure permits implementation efficiency advantages; however,
this structure may also permit the countersigning of an inappropriate this structure may also permit the countersigning of an inappropriate
signature value. Therefore, implementations that perform signature value. Therefore, implementations that perform
countersignatures should either verify the original signature value countersignatures should either verify the original signature value
prior to countersigning it (this verification requires processing of prior to countersigning it (this verification requires processing of
the original content), or implementations should perform the original content), or implementations should perform
countersigning in a context that ensures that only appropriate countersigning in a context that ensures that only appropriate
signature values are countersigned. signature values are countersigned.
Users of CMS, particularly those employing CMS to support interactive Users of the CMS, particularly those employing the CMS to support
applications, should be aware that PKCS #1 Version 1.5 as specified interactive applications, should be aware that PKCS #1 Version 1.5 as
in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext specified in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen
attacks when applied for encryption purposes. Exploitation of this ciphertext attacks when applied for encryption purposes.
identified vulnerability, revealing the result of a particular RSA Exploitation of this identified vulnerability, revealing the result
decryption, requires access to an oracle which will respond to a of a particular RSA decryption, requires access to an oracle which
large number of ciphertexts (based on currently available results, will respond to a large number of ciphertexts (based on currently
hundreds of thousands or more), which are constructed adaptively in available results, hundreds of thousands or more), which are
response to previously-received replies providing information on the constructed adaptively in response to previously-received replies
successes or failures of attempted decryption operations. As a providing information on the successes or failures of attempted
result, the attack appears significantly less feasible to perpetrate decryption operations. As a result, the attack appears significantly
for store-and-forward S/MIME environments than for directly less feasible to perpetrate for store-and-forward S/MIME environments
interactive protocols. Where CMS constructs are applied as an than for directly interactive protocols. Where the CMS constructs
intermediate encryption layer within an interactive request-response are applied as an intermediate encryption layer within an interactive
communications environment, exploitation could be more feasible. request-response communications environment, exploitation could be
more feasible.
An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0
[NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1 [NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1
Version 2.0 preserves support for the encryption padding format Version 2.0 preserves support for the encryption padding format
defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new
alternative. To resolve the adaptive chosen ciphertext alternative. To resolve the adaptive chosen ciphertext
vulnerability, the PKCS #1 Version 2.0 specifies and recommends use vulnerability, the PKCS #1 Version 2.0 specifies and recommends use
of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption
is used to provide confidentiality. Designers of protocols and is used to provide confidentiality. Designers of protocols and
systems employing CMS for interactive environments should either systems employing the CMS for interactive environments should either
consider usage of OAEP, or should ensure that information which could consider usage of OAEP, or should ensure that information which could
reveal the success or failure of attempted PKCS #1 Version 1.5 reveal the success or failure of attempted PKCS #1 Version 1.5
decryption operations is not provided. Support for OAEP will likely 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 this specification.
Acknowledgments Acknowledgments
This document is the result of contributions from many professionals. This document is the result of contributions from many professionals.
I appreciate the hard work of all members of the IETF S/MIME Working I appreciate the hard work of all members of the IETF S/MIME Working
Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson,
Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman,
Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt
Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau,
Jim Schaad, and Dave Solo for their efforts and support. Jim Schaad, and Dave Solo for their efforts and support.
skipping to change at page 53, line 4 skipping to change at line 2359
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE. OR FITNESS FOR A PARTICULAR PURPOSE.
Change History
<< This section to be deleted before RFC >>
This section lists major changes since the previous revision.
Changes from -00 to -01:
1. Section 6.2. Revised RecipientInfo structure. Changed MUST implement.
Included Password-based key management and { OID, ANY } alternative for
future key management technique specifications.
2. Section 6.2.4. New discussion of PasswordRecipientInfo.
3. Section 6.2.5. New discussion of OtherRecipientInfo.
4. Section 10.1.6. New discussion of KeyDerivationAlgorithmIdentifier.
5. ASN.1 Module. Updated RecipientInfo. IMPORTed PasswordRecipientInfo.
Added OtherRecipientInfo.
 End of changes. 

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