draft-ietf-smime-rfc2630bis-03.txt   draft-ietf-smime-rfc2630bis-04.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet Draft RSA Laboratories Internet Draft RSA Laboratories
expires in six months August 2001 expires in six months September 2001
Cryptographic Message Syntax Cryptographic Message Syntax
<draft-ietf-smime-rfc2630bis-03.txt> <draft-ietf-smime-rfc2630bis-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 Once approved, this draft will obsolete RFC 2630. The discussion of
discussion of specific cryptographic algorithms has been moved to a specific cryptographic algorithms has been moved to a separate
separate document [CMSALG]. Separation of the protocol and algorithm document [CMSALG]. Separation of the protocol and algorithm
specifications allows the IETF to update each document independently. specifications allows the IETF to update each document independently.
No mandatory to implement algorithms are specified. Rather, No mandatory to implement algorithms are specified. Rather,
protocols that reply on the CMS are expected to choose appropriate protocols that reply on the CMS are expected to choose appropriate
algorithms for their environment. The algorithms may be selected algorithms for their environment. The algorithms may be selected
from [CMSALG] or elsewhere. from [CMSALG] or elsewhere.
Look for [*** NEW ***]. This string is used to identify text that is
significantly different than RFC 2630. However, editorial changes
were made that are not flagged with this string.
This draft is being discussed on the "ietf-smime" mailing list. To This draft is being discussed on the "ietf-smime" mailing list. To
join the list, send a message to <ietf-smime-request@imc.org> with join the list, send a message to <ietf-smime-request@imc.org> with
the single word "subscribe" in the body of the message. Also, there the single word "subscribe" in the body of the message. Also, there
is a Web site for the mailing list at <http://www.imc.org/ietf- is a Web site for the mailing list at <http://www.imc.org/ietf-
smime/>. smime/>.
Table of Contents Table of Contents
Status of this Memo ................................................ 1 Status of this Memo ................................................ 1
Abstract ........................................................... 1 Abstract ........................................................... 1
skipping to change at page 8, line 40 skipping to change at page 8, line 40
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. The version is the syntax version number. The appropriate value
appropriate value depends on certificates, eContentType, and depends on certificates, eContentType, and SignerInfo. The
SignerInfo. The version MUST be assigned as follows: version MUST be assigned as follows:
IF (certificates is present) AND IF (certificates is present) AND
(any version 2 attribute certificates are present) (any version 2 attribute certificates are present)
THEN version MUST be 4 THEN version MUST be 4
ELSE ELSE
IF ((certificates is present) AND IF ((certificates is present) AND
(any version 1 attribute certificates are present)) OR (any version 1 attribute certificates are present)) OR
(encapContentInfo eContentType is other than id-data) OR (encapContentInfo eContentType is other than id-data) OR
(any SignerInfo structures are version 3) (any SignerInfo structures are version 3)
THEN version MUST be 3 THEN version MUST be 3
skipping to change at page 10, line 39 skipping to change at page 10, line 39
within EncapsulatedContentInfo is absent, then the signatureValue is within EncapsulatedContentInfo is absent, then the signatureValue is
calculated and the eContentType is assigned as though the eContent calculated and the eContentType is assigned as though the eContent
value was present. value was present.
In the degenerate case where there are no signers, the In the degenerate case where there are no signers, the
EncapsulatedContentInfo value being "signed" is irrelevant. In this EncapsulatedContentInfo value being "signed" is irrelevant. In this
case, the content type within the EncapsulatedContentInfo value being case, the content type within the EncapsulatedContentInfo value being
"signed" MUST be id-data (as defined in section 4), and the content "signed" MUST be id-data (as defined in section 4), and the content
field of the EncapsulatedContentInfo value MUST be omitted. field of the EncapsulatedContentInfo value MUST be omitted.
5.2.1 [*** NEW ***] Compatibility with PKCS #7 5.2.1 Compatibility with PKCS #7
This section contains a word of warning to implementers that wish to This section contains a word of warning to implementers that wish to
support both the CMS and PKCS #7 [PKCS#7]. Both the CMS and PKCS #7 support both the CMS and PKCS #7 [PKCS#7] SignedData content types.
identify the type of the encapsulated content with an object Both the CMS and PKCS #7 identify the type of the encapsulated
identifier, but the ASN.1 type of the content itself was variable in content with an object identifier, but the ASN.1 type of the content
PKCS #7. The definition for eContent, in PKCS #7 this was: itself is variable in PKCS #7 SignedData content type.
PKCS #7 defines content as:
content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
In the CMS, the definition for eContent is: The CMS defines eContent as:
eContent [0] EXPLICIT OCTET STRING OPTIONAL eContent [0] EXPLICIT OCTET STRING OPTIONAL
The newer definition is much easier to use in most applications, and
it is compatible with both S/MIME v2 and S/MIME v3. However, there
are some deployed applications that use the older PKCS #7 definition.
For example, Microsoft AuthentiCode does not sign an OCTET STRING.
To achive backward compatibility with PKCS #7, CMS implementations The CMS definition is much easier to use in most applications, and it
MAY examine the value of the eContentType, and then adjust the is compatible with both S/MIME v2 and S/MIME v3. S/MIME signed
expected encoding of eContent based on the object identifier value. messages using the CMS and PKCS #7 are compatible because identical
For example, to support Microsoft AuthentiCode, the following signed message formats are specified in RFC 2311 for S/MIME v2
information might be included: [OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. S/MIME v2 encapsulates
the MIME content in a Data type (that is, an OCTET STRING) carried in
the SignedData contentInfo content ANY field, and S/MIME v3 carries
the MIME content in the SignedData encapContentInfo eContent OCTET
STRING. Therefore, in both S/MIME v2 and S/MIME v3, the MIME content
is placed in an OCTET STRING and the message digest is computed over
the identical portions of the content. That is, the message digest
is computed over the octets comprising the value of the OCTET STRING,
neither the tag nor length octets are included.
eContentType Object Identifier = { 1 3 6 1 4 1 311 2 1 4 } There are incompatibilities between the CMS and PKCS #7 signedData
eContent Type = SpcIndirectDataContext -- Microsoft code signing types when the encapsulated content is not formatted using the Data
type. For example, when an RFC 2634 [ESS] signed receipt is
encapsulated in the CMS signedData type, then the Receipt SEQUENCE is
encoded in the signedData encapContentInfo eContent OCTET STRING and
the message digest is computed using the entire Receipt SEQUENCE
encoding (including tag, length and value octets). However, if an
RFC 2634 signed receipt is encapsulated in the PKCS #7 signedData
type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the
SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET
STRING). Therefore, the message digest is computed using only the
value octets of the Receipt SEQUENCE encoding.
The following strategy can be used to achieve backward compatibility
with PKCS #7 when processing SignedData content types. If the
implementation is unable to ASN.1 decode the signedData type using
the CMS signedData encapContentInfo eContent OCTET STRING syntax,
then the implementation MAY attempt to decode the signedData type
using the PKCS #7 SignedData contentInfo content ANY syntax and
compute the message digest accordingly.
The following strategy can be used to achieve backward compatibility
with PKCS #7 when creating a SignedData content type in which the
encapsulated content is not formatted using the Data type.
Implementations MAY examine the value of the eContentType, and then
adjust the expected DER encoding of eContent based on the object
identifier value. For example, to support Microsoft AuthentiCode,
the following information MAY be included:
eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 }
eContent contains DER encoded AuthentiCode signing information
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 12, line 41 skipping to change at page 13, line 27
signedAttrs is a collection of attributes that are signed. The signedAttrs is a collection of attributes that are signed. The
field is optional, but it MUST be present if the content type of field is optional, but it MUST be present if the content type 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. [*** NEW ***] 11.1 defines the content-type attribute. However, the content-
However, the content-type attribute MUST NOT be used as part of type attribute MUST NOT be used as part of a countersignature
a countersignature unsigned attribute as defined in section unsigned attribute as defined in section 11.4.
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 ***] The message digest and the signer's private key. The details of the
details of the signature depend on the signature algorithm signature depend on the signature algorithm employed.
employed.
unsignedAttrs is a collection of attributes that are not signed. unsignedAttrs is a collection of attributes that are not 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.
skipping to change at page 17, line 5 skipping to change at page 17, line 39
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. The version is the syntax version number. The appropriate value
appropriate value depends on originatorInfo, RecipientInfo, and depends on originatorInfo, RecipientInfo, and unprotectedAttrs.
unprotectedAttrs. The version MUST be assigned as follows: The version MUST be assigned as follows:
IF ((originatorInfo is present) AND IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present)) OR (any version 2 attribute certificates are present)) OR
(any RecipientInfo structures include pwri) OR (any RecipientInfo structures include pwri) OR
(any RecipientInfo structures include ori) (any RecipientInfo structures include ori)
THEN version is 3 THEN version is 3
ELSE ELSE
IF (originatorInfo is present) OR IF (originatorInfo is present) OR
(unprotectedAttrs is present) OR (unprotectedAttrs is present) OR
(any RecipientInfo structures are a version other than 0) (any RecipientInfo structures are a version other than 0)
skipping to change at page 18, line 25 skipping to change at page 19, line 11
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 Per-recipient information is represented in the type RecipientInfo.
RecipientInfo. RecipientInfo has a different format for each of the RecipientInfo has a different format for each of the supported key
supported key management techniques. Any of the key management management techniques. Any of the key management techniques can be
techniques can be used for each recipient of the same encrypted used for each recipient of the same encrypted content. In all cases,
content. In all cases, the content-encryption key is transferred to the content-encryption key is transferred to one or more recipient in
one or more recipient in encrypted form. encrypted form.
[*** NEW ***] Since all implementations will not support every Since all implementations will not support every possible key
possible key management algorithm, all implementations MUST management algorithm, all implementations MUST gracefully handle
gracefully handle unimplemented algorithms when they are encountered. unimplemented algorithms when they are encountered. For example, if
For example, if a recipient receives a content-encryption key a recipient receives a content-encryption key encrypted in their RSA
encrypted in their RSA public key using RSA-OAEP and the public key using RSA-OAEP and the implementation only supports RSA
implementation only supports RSA PKCS #1 v1.5, then a graceful PKCS #1 v1.5, then a graceful failure must be implemented.
failure must be implemented.
[*** NEW ***] Implementations MUST support key transport, key Implementations MUST support key transport, key agreement, and
agreement, and previously distributed symmetric key-encryption keys, previously distributed symmetric key-encryption keys, as represented
as represented by ktri, kari, and kekri, respectively. by ktri, kari, and kekri, respectively. Implementations MAY support
Implementations MAY support the password-based key management as the password-based key management as represented by pwri.
represented by pwri. Implementations MAY support any other key Implementations MAY support any other key management technique as
management technique as represented by ori. Since each recipient can represented by ori. Since each recipient can employ a different key
employ a different key management technique and future specifications management technique and future specifications could define
could define additional key management techniques, all additional key management techniques, all implementations MUST
implementations MUST gracefully handle unimplemented alternatives gracefully handle unimplemented alternatives within the RecipientInfo
within the RecipientInfo CHOICE, all implementations MUST gracefully CHOICE, all implementations MUST gracefully handle unimplemented
handle unimplemented versions of otherwise supported alternatives versions of otherwise supported alternatives within the RecipientInfo
within the RecipientInfo CHOICE, and all implementations MUST CHOICE, and all implementations MUST gracefully handle unimplemented
gracefully handle unimplemented or unknown ori alternatives. 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
skipping to change at page 19, line 50 skipping to change at page 20, line 35
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. Therefore, a recipient X.509 version 3 certificate that key. Therefore, a recipient X.509 version 3 certificate that
contains a key usage extension MUST assert the keyEncipherment contains a key usage extension MUST assert the keyEncipherment
bit. The content-encryption key is encrypted with the recipient's 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 ***] For recipient processing, extension value. For recipient processing, implementations MUST
implementations MUST support both of these alternatives for support both of these alternatives for specifying the recipient's
specifying the recipient's certificate; and for sender processing, certificate; and for sender processing, implementations MUST
implementations MUST support at least one of these alternatives. 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
skipping to change at page 21, line 24 skipping to change at page 22, line 9
corresponding private key and the recipient's public key to corresponding private key and the recipient's public key to
generate a pairwise key. The content-encryption key is encrypted generate a pairwise key. The content-encryption key is encrypted
in the pairwise key. The issuerAndSerialNumber alternative in the pairwise key. The issuerAndSerialNumber alternative
identifies the sender's certificate, and thereby the sender's identifies the sender's certificate, and thereby the sender's
public key, by the issuer's distinguished name and the certificate public key, by the issuer's distinguished name and the certificate
serial number. The subjectKeyIdentifier alternative identifies serial number. The subjectKeyIdentifier alternative identifies
the sender's certificate, and thereby the sender's public key, by the sender's certificate, and thereby the sender's public key, by
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. Implementations
Implementations MUST support all three alternatives for specifying MUST support all three alternatives for specifying the sender's
the sender's public key. 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 MUST support pairwise key. Implementations MUST support recipient processing
recipient processing of a KeyAgreeRecipientInfo SEQUENCE that of a KeyAgreeRecipientInfo SEQUENCE that includes a ukm field.
includes a ukm field. Implementations that do not support key Implementations that do not support key agreement algorithms that
agreement algorithms that make use of UKMs MUST gracefully handle make use of UKMs MUST gracefully handle the presence of UKMs.
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
skipping to change at page 22, line 9 skipping to change at page 22, line 41
pairwise key-encryption key. The recipient's certificate must pairwise key-encryption key. The recipient's certificate must
contain a key agreement public key. Therefore, a recipient X.509 contain a key agreement public key. Therefore, a recipient X.509
version 3 certificate that contains a key usage extension MUST version 3 certificate that contains a key usage extension MUST
assert the keyAgreement bit. The content-encryption key is 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. Implementations MUST support both
both alternatives for specifying the recipient's certificate. alternatives for specifying the recipient's certificate.
The fields of type RecipientKeyIdentifier have the following The fields of type RecipientKeyIdentifier have the following
meanings: meanings:
subjectKeyIdentifier identifies the recipient's certificate by the subjectKeyIdentifier identifies the recipient's certificate by the
X.509 subjectKeyIdentifier extension value. X.509 subjectKeyIdentifier extension value.
date is optional. When present, the date specifies which of the date is optional. When present, the date specifies which of the
recipient's previously distributed UKMs was used by the sender. recipient's previously distributed UKMs was used by the sender.
skipping to change at page 23, line 23 skipping to change at page 24, line 6
keyIdentifier identifies the key-encryption key that was keyIdentifier identifies the key-encryption key that was
previously distributed to the sender and one or more recipients. previously distributed to the sender and one or more recipients.
date is optional. When present, the date specifies a single key- date is optional. When present, the date specifies a single key-
encryption key from a set that was previously distributed. encryption key from a set that was previously distributed.
other is optional. When present, this field contains additional other is optional. When present, this field contains additional
information used by the recipient to determine the key-encryption information used by the recipient to determine the key-encryption
key used by the sender. key used by the sender.
6.2.4 [*** NEW ***] PasswordRecipientInfo Type 6.2.4 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 possess 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 {
skipping to change at page 24, line 8 skipping to change at page 24, line 39
absent, the key-encryption key is supplied from an external absent, the key-encryption key is supplied from an external
source, for example a hardware crypto token such as a smart card. source, for example a hardware crypto token such as a smart card.
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 OtherRecipientInfo Type
Recipient information for additional key management techniques are Recipient information for additional key management techniques are
represented in the type OtherRecipientInfo. The OtherRecipientInfo represented in the type OtherRecipientInfo. The OtherRecipientInfo
type allows key management techniques beyond key transport, key type allows key management techniques beyond key transport, key
agreement, previously distributed symmetric key-encryption keys, and agreement, previously distributed symmetric key-encryption keys, and
password-based key management to be specified in future documents. password-based key management to be specified in future documents.
An object identifier uniquely identifies such key management An object identifier uniquely identifies such key management
techniques. techniques.
OtherRecipientInfo ::= SEQUENCE { OtherRecipientInfo ::= SEQUENCE {
skipping to change at page 28, line 31 skipping to change at page 29, line 19
unauthAttrs [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:
[*** NEW ***] version is the syntax version number. The version version is the syntax version number. The version MUST be
MUST be assigned as follows: assigned as follows:
IF ((originatorInfo is present) AND IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present)) (any version 2 attribute certificates are present))
THEN version is 1 THEN version is 1
ELSE version is 0 ELSE version is 0
originatorInfo optionally provides information about the originatorInfo optionally provides information about the
originator. It is present only if required by the key management originator. It is present only if required by the key management
algorithm. It MAY contain certificates, attribute certificates, algorithm. It MAY contain certificates, attribute certificates,
and CRLs, as defined in Section 6.1. and CRLs, as defined in Section 6.1.
skipping to change at page 32, line 44 skipping to change at page 33, line 33
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-SHA-1. 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 KeyDerivationAlgorithmIdentifier
The KeyDerivationAlgorithmIdentifier type is specified in RFC <TBD> The KeyDerivationAlgorithmIdentifier type is specified in RFC <TBD>
[PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated [PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated
here for completeness. here for completeness.
Key derivation algorithms convert a password or shared secret value Key derivation algorithms convert a password or shared secret value
into a key-encryption key. into a key-encryption key.
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
skipping to change at page 33, line 34 skipping to change at page 34, line 27
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 <TBD> [PROFILE]. in the Internet in RFC <TBD> [PROFILE].
The definition of CertificateList is imported from X.509. The definition of CertificateList is imported from X.509.
CertificateRevocationLists ::= SET OF CertificateList CertificateRevocationLists ::= SET OF CertificateList
10.2.2 CertificateChoices 10.2.2 CertificateChoices
[*** NEW ***] The CertificateChoices type gives either a PKCS #6 The CertificateChoices type gives either a PKCS #6 extended
extended certificate [PKCS#6], an X.509 certificate, a version 1 certificate [PKCS#6], an X.509 certificate, a version 1 X.509
X.509 attribute certificate (ACv1) [X.509-97], or a version 2 X.509 attribute certificate (ACv1) [X.509-97], or a version 2 X.509
attribute certificate (ACv2) [X.509-00]. The PKCS #6 extended attribute certificate (ACv2) [X.509-00]. The PKCS #6 extended
certificate is obsolete. The PKCS #6 certificate is included for certificate is obsolete. The PKCS #6 certificate is included for
backward compatibility, and PKCS #6 certificates SHOULD NOT be used. backward compatibility, and PKCS #6 certificates SHOULD NOT be used.
The ACv1 is also obsolete. ACv1 is included for backward The ACv1 is also obsolete. ACv1 is included for backward
compatibility, and ACv1 SHOULD NOT be used. The Internet profile of compatibility, and ACv1 SHOULD NOT be used. The Internet profile of
X.509 certificates is specified in the "Internet X.509 Public Key X.509 certificates is specified in the "Internet X.509 Public Key
Infrastructure: Certificate and CRL Profile" [PROFILE]. The Internet Infrastructure: Certificate and CRL Profile" [PROFILE]. The Internet
profile of ACv2 is specified in the "An Internet Attribute profile of ACv2 is specified in the "An Internet Attribute
Certificate Profile for Authorization" [ACPROFILE]. Certificate Profile for Authorization" [ACPROFILE].
The definition of Certificate is imported from X.509. The definition of Certificate is imported from X.509.
[*** NEW ***] The definitions of AttributeCertificate are imported The definitions of AttributeCertificate are imported from X.509-1997
from X.509-1997 and X.509-2000. The definition from X.509-1997 is and X.509-2000. The definition from X.509-1997 is assigned to
assigned to AttributeCertificateV1 (see Appendix B), and the AttributeCertificateV1 (see Appendix B), and the definition from
definition from X.509-2000 is assigned to AttributeCertificateV2. X.509-2000 is assigned to AttributeCertificateV2.
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509 certificate Certificate, -- See X.509
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
skipping to change at page 35, line 44 skipping to change at page 36, line 34
defined in a previous version of this specification [OLDCMS]. The defined in a previous version of this specification [OLDCMS]. The
attributes are not listed in any particular order. attributes are not listed in any particular order.
Additional attributes are defined in many places, notably the S/MIME Additional attributes are defined in many places, notably the S/MIME
Version 3 Message Specification [MSG] and the Enhanced Security Version 3 Message Specification [MSG] and the Enhanced Security
Services for S/MIME [ESS], which also include recommendations on the Services for S/MIME [ESS], which also include recommendations on the
placement of these attributes. placement of these attributes.
11.1 Content Type 11.1 Content Type
[*** NEW ***] The content-type attribute type specifies the content The content-type attribute type specifies the content type of the
type of the ContentInfo within signed-data or authenticated-data. ContentInfo within signed-data or authenticated-data. The content-
The content-type attribute type MUST be present whenever signed type attribute type MUST be present whenever signed attributes are
attributes are present in signed-data or authenticated attributes present in signed-data or authenticated attributes present in
present in authenticated-data. The content-type attribute value MUST authenticated-data. The content-type attribute value MUST match the
match the encapContentInfo eContentType value in the signed-data or encapContentInfo eContentType value in the signed-data or
authenticated-data. authenticated-data.
[*** NEW ***] The content-type attribute MUST be a signed attribute The content-type attribute MUST be a signed attribute or an
or an authenticated attribute; it MUST NOT be an unsigned attribute, 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:
skipping to change at page 36, line 37 skipping to change at page 37, line 27
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
encapContentInfo eContent OCTET STRING being signed in signed-data encapContentInfo eContent OCTET STRING being signed in signed-data
(see section 5.4) or authenticated in authenticated-data (see section (see section 5.4) or authenticated in authenticated-data (see section
9.2). For signed-data, the message digest is computed using the 9.2). For signed-data, the message digest is computed using the
signer's message digest algorithm. For authenticated-data, the signer's message digest algorithm. For authenticated-data, the
message digest is computed using the originator's message digest message digest is computed using the originator's message digest
algorithm. algorithm.
[*** NEW ***] Within signed-data, the message-digest signed attribute Within signed-data, the message-digest signed attribute type MUST be
type MUST be present when there are any signed attributes present. present when there are any signed attributes present. Within
Within authenticated-data, the message-digest authenticated attribute authenticated-data, the message-digest authenticated attribute type
type MUST be present when there are any authenticated attributes MUST be present when there are any authenticated attributes present.
present.
[*** NEW ***] The message-digest attribute MUST be a signed attribute The message-digest attribute MUST be a signed attribute or an
or an authenticated attribute; it MUST NOT be an unsigned attribute, 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 message-digest The following object identifier identifies the message-digest
attribute: attribute:
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
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 and AuthAttributes syntax are each The SignedAttributes syntax and AuthAttributes syntax are each
defined as a SET OF Attributes. The SignedAttributes in a signerInfo defined as a SET OF Attributes. The SignedAttributes in a signerInfo
skipping to change at page 37, line 15 skipping to change at page 38, line 4
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 and AuthAttributes syntax are each The SignedAttributes syntax and AuthAttributes syntax are each
defined as a SET OF Attributes. The SignedAttributes in a signerInfo defined as a SET OF Attributes. The SignedAttributes in a signerInfo
MUST include only one instance of the message-digest attribute. MUST include only one instance of the message-digest attribute.
Similarly, the AuthAttributes in an AuthenticatedData MUST include Similarly, the AuthAttributes in an AuthenticatedData MUST include
only one instance of the message-digest attribute. 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 MUST be a signed attribute The signing-time attribute MUST be a signed attribute or an
or an authenticated attribute; it MUST NOT be an unsigned attribute, 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 38, line 40 skipping to change at page 39, line 29
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
field of a SignerInfo value in signed-data. Thus, the field of a SignerInfo value in signed-data. Thus, the
countersignature attribute type countersigns (signs in serial) countersignature attribute type countersigns (signs in serial)
another signature. another signature.
[*** NEW ***] The countersignature attribute MUST be an unsigned The countersignature attribute MUST be an unsigned attribute; it MUST
attribute; it MUST NOT be a signed attribute, an authenticated NOT be a signed attribute, an authenticated attribute, an
attribute, an unauthenticated attribute, or an unprotected attribute. unauthenticated attribute, or an unprotected attribute.
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
[*** NEW ***] Countersignature values have the same meaning as Countersignature values have the same meaning as SignerInfo values
SignerInfo values for ordinary signatures, except that: for ordinary signatures, except that:
1. The signedAttributes field MUST NOT contain a content-type 1. The signedAttributes field MUST NOT contain a content-type
attribute; there is no content type for countersignatures. attribute; there is no content type for countersignatures.
2. The signedAttributes field MUST contain a message-digest 2. The signedAttributes field MUST contain a message-digest
attribute if it contains any other attributes. attribute if it contains any other attributes.
3. The input to the message-digesting process is the contents 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.
skipping to change at page 40, line 11 skipping to change at page 41, line 11
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)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) } pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) }
-- [*** NEW ***] A new OID was assigned for this updated module.
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
-- The types and values defined in this module are exported for use in -- The types and values defined in this module are exported for use in
-- the other ASN.1 modules. Other applications may use them for their -- the other ASN.1 modules. Other applications may use them for their
-- own purposes. -- own purposes.
IMPORTS IMPORTS
skipping to change at page 40, line 34 skipping to change at page 41, line 32
Name Name
FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) FROM InformationFramework { joint-iso-itu-t ds(5) modules(1)
informationFramework(1) 3 } informationFramework(1) 3 }
-- Directory Authentication Framework (X.509-2000) -- Directory Authentication Framework (X.509-2000)
AlgorithmIdentifier, Certificate, CertificateList, AlgorithmIdentifier, Certificate, CertificateList,
CertificateSerialNumber CertificateSerialNumber
FROM AuthenticationFramework { joint-iso-itu-t ds(5) FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 4 } module(1) authenticationFramework(7) 4 }
-- [*** NEW ***]
-- Attribute Certificate Definitions (X.509-2000) -- Attribute Certificate Definitions (X.509-2000)
AttributeCertificate AttributeCertificate
FROM AttributeCertificateDefinitions { joint-iso-itu-t FROM AttributeCertificateDefinitions { joint-iso-itu-t
ds(5) module(1) attributeCertificateDefinitions(32) 4 } ds(5) module(1) attributeCertificateDefinitions(32) 4 }
-- [*** NEW ***]
-- Indirectly from Directory Authentication Framework (X.509-1997) -- Indirectly from Directory Authentication Framework (X.509-1997)
AttributeCertificateV1 AttributeCertificateV1
FROM AttributeCertificateVersion1 { iso(1) member-body(2) FROM AttributeCertificateVersion1 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) v1AttrCert(15) } ; modules(0) v1AttrCert(15) } ;
-- Cryptographic Message Syntax -- Cryptographic Message Syntax
ContentInfo ::= SEQUENCE { ContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType } content [0] EXPLICIT ANY DEFINED BY contentType }
skipping to change at page 42, line 15 skipping to change at page 43, 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 }
-- [*** OLD ***]
-- RecipientInfos ::= SET OF RecipientInfo
-- [*** NEW ***]
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 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
-- [*** OLD ***]
-- RecipientInfo ::= CHOICE {
-- ktri KeyTransRecipientInfo,
-- kari [1] KeyAgreeRecipientInfo,
-- kekri [2] KEKRecipientInfo }
-- [*** NEW ***]
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo, kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientInfo, pwri [3] PasswordRecipientInfo,
ori [4] OtherRecipientInfo } ori [4] OtherRecipientInfo }
EncryptedKey ::= OCTET STRING EncryptedKey ::= OCTET STRING
KeyTransRecipientInfo ::= SEQUENCE { KeyTransRecipientInfo ::= SEQUENCE {
skipping to change at page 44, line 4 skipping to change at page 44, line 40
KEKRecipientInfo ::= SEQUENCE { KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4 version CMSVersion, -- always set to 4
kekid KEKIdentifier, kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
KEKIdentifier ::= SEQUENCE { KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING, keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL, date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL } other OtherKeyAttribute OPTIONAL }
-- [*** NEW ***]
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 }
-- [*** NEW ***]
OtherRecipientInfo ::= SEQUENCE { OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER, oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType } oriValue ANY DEFINED BY oriType }
DigestedData ::= SEQUENCE { DigestedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
digest Digest } digest Digest }
Digest ::= OCTET STRING Digest ::= OCTET STRING
EncryptedData ::= SEQUENCE { EncryptedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
skipping to change at page 44, line 30 skipping to change at page 45, line 17
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,
authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode, mac MessageAuthenticationCode,
unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }
skipping to change at page 45, line 22 skipping to change at page 45, line 44
DigestAlgorithmIdentifier ::= AlgorithmIdentifier DigestAlgorithmIdentifier ::= AlgorithmIdentifier
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
-- [*** NEW ***]
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
CertificateRevocationLists ::= SET OF CertificateList CertificateRevocationLists ::= SET OF CertificateList
-- [*** OLD ***]
-- CertificateChoices ::= CHOICE {
-- certificate Certificate, - - See X.509
-- extendedCertificate [0] IMPLICIT ExtendedCertificate, - - Obsolete
-- attrCert [1] IMPLICIT AttributeCertificate } - - See X.509 & X9.57
-- [*** NEW ***]
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509 certificate Certificate, -- See X.509
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
-- [*** NEW ***]
AttributeCertificateV2 ::= AttributeCertificate -- See X.509-2000 AttributeCertificateV2 ::= AttributeCertificate -- See X.509-2000
CertificateSet ::= SET OF CertificateChoices CertificateSet ::= SET OF CertificateChoices
IssuerAndSerialNumber ::= SEQUENCE { IssuerAndSerialNumber ::= SEQUENCE {
issuer Name, issuer Name,
serialNumber CertificateSerialNumber } serialNumber CertificateSerialNumber }
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
OtherKeyAttribute ::= SEQUENCE { OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER, keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL } keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
-- The CMS Attributes -- The CMS Attributes
MessageDigest ::= OCTET STRING MessageDigest ::= OCTET STRING
SigningTime ::= Time SigningTime ::= Time
skipping to change at page 48, line 7 skipping to change at page 48, line 7
version CMSVersion, version CMSVersion,
certificate Certificate, certificate Certificate,
attributes UnauthAttributes } attributes UnauthAttributes }
Signature ::= BIT STRING Signature ::= BIT STRING
END -- of CryptographicMessageSyntax END -- of CryptographicMessageSyntax
Appendix B: Version 1 Attribute Certificate ASN.1 Module Appendix B: Version 1 Attribute Certificate ASN.1 Module
[*** NEW ***]
AttributeCertificateVersion1 AttributeCertificateVersion1
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) } pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
-- Only one type is defined, and it is exported. -- Only one type is defined, and it is exported.
skipping to change at page 49, line 7 skipping to change at page 49, line 7
module(1) authenticationFramework(7) 3 } ; module(1) authenticationFramework(7) 3 } ;
-- Version 1 Attribute Certificate -- Version 1 Attribute Certificate
AttributeCertificateV1 ::= AttributeCertificate AttributeCertificateV1 ::= AttributeCertificate
END -- of AttributeCertificateVersion1 END -- of AttributeCertificateVersion1
References References
3DES American National Standards Institute. ANSI X9.52-1998,
Triple Data Encryption Algorithm Modes of Operation. 1998.
ACPROFILE Farrell, S., and R. Housley. An Internet Attribute ACPROFILE Farrell, S., and R. Housley. An Internet Attribute
Certificate Profile for Authorization. RFC <TBD>. <Date>. Certificate Profile for Authorization. RFC <TBD>. <Date>.
{draft-ietf-pkix-ac509prof-*.txt} {draft-ietf-pkix-ac509prof-*.txt}
CMSALG Housley, R. Cryptographic Message Syntax (CMS) Algorithms. CMSALG Housley, R. Cryptographic Message Syntax (CMS) Algorithms.
RFC <TBD>. <Date>. {draft-ietf-smime-cmsalg-*.txt} RFC <TBD>. <Date>. {draft-ietf-smime-cmsalg-*.txt}
DES American National Standards Institute. ANSI X3.106,
"American National Standard for Information Systems - Data
Link Encryption". 1983.
DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method.
RFC 2631. June 1999.
DSS National Institute of Standards and Technology. DSS National Institute of Standards and Technology.
FIPS Pub 186: Digital Signature Standard. 19 May 1994. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
ESS Hoffman, P. Enhanced Security Services for S/MIME. ESS Hoffman, P. Enhanced Security Services for S/MIME.
RFC 2634. June 1999. RFC 2634. June 1999.
HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication.
RFC 2104. February 1997.
MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321.
April 1992.
MODES National Institute of Standards and Technology.
FIPS Pub 81: DES Modes of Operation. 2 December 1980.
MSG Ramsdell, B. S/MIME Version 3 Message Specification. MSG Ramsdell, B. S/MIME Version 3 Message Specification.
RFC 2633. June 1999. RFC 2633. June 1999.
NEWPKCS#1 Kaliski, B., and J. Staddon. PKCS #1: RSA Encryption,
Version 2.0. RFC 2437. October 1998.
OLDCMS Housley, R., "Cryptographic Message Syntax", RFC 2630, OLDCMS Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999. June 1999.
OLDMSG Dusse, S., P. Hoffman, B. Ramsdell, L. Lundblade, and
L. Repka. S/MIME Version 2 Message Specification.
RFC 2311. March 1998.
PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet
X.509 Public Key Infrastructure: Certificate and CRL X.509 Public Key Infrastructure: Certificate and CRL
Profile. RFC <TBD>. <Date>. Profile. RFC <TBD>. <Date>.
[draft-ietf-pkix-new-part1-*.txt] [draft-ietf-pkix-new-part1-*.txt]
PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5.
RFC 2313. March 1998.
PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax
Standard, Version 1.5. November 1993. Standard, Version 1.5. November 1993.
PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax,
Version 1.5. RFC 2315. March 1998. Version 1.5. RFC 2315. March 1998.
PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types,
Version 1.1. November 1993. Version 1.1. November 1993.
PWRI Gutmann, P. Password-based Encryption for S/MIME. PWRI Gutmann, P. Password-based Encryption for S/MIME.
RFC <TBD>. <DATE>. [draft-ietf-smime-password-*.txt] RFC <TBD>. <DATE>. [draft-ietf-smime-password-*.txt]
RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness
Recommendations for Security. RFC 1750. December 1994. Recommendations for Security. RFC 1750. December 1994.
RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm.
RFC 2268. March 1998.
SHA1 National Institute of Standards and Technology.
FIPS Pub 180-1: Secure Hash Standard. 17 April 1995.
STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate
Requirement Levels. RFC2119. March 1997. Requirement Levels. RFC2119. March 1997.
X.208-88 CCITT. Recommendation X.208: Specification of Abstract X.208-88 CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1). 1988. Rules for Abstract Syntax Notation One (ASN.1). 1988.
X.501-88 CCITT. Recommendation X.501: The Directory - Models. 1988. X.501-88 CCITT. Recommendation X.501: The Directory - Models. 1988.
skipping to change at page 51, line 27 skipping to change at page 51, line 27
the disclosure of all messages protected with that key. Similarly, the disclosure of all messages protected with that key. Similarly,
compromise of the content-encryption key may result in disclosure of compromise of the content-encryption key may result in disclosure of
the associated encrypted content. the associated encrypted content.
Implementations must protect the key management private key and the Implementations must protect the key management private key and the
message-authentication key. Compromise of the key management private message-authentication key. Compromise of the key management private
key permits masquerade of authenticated data. Similarly, compromise key permits masquerade of authenticated data. Similarly, compromise
of the message-authentication key may result in undetectable of the message-authentication key may result in undetectable
modification of the authenticated content. modification of the authenticated content.
[*** NEW ***] The key management technique employed to distribute The key management technique employed to distribute message-
message-authentication keys must itself provide data origin authentication keys must itself provide data origin authentication,
authentication, otherwise the message content is delivered with otherwise the message content is delivered with integrity from an
integrity from an unknown source. Neither RSA [PKCS#1, NEWPKCS#1] unknown source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static
nor Ephemeral-Static Diffie-Hellman [DH-X9.42] provide the necessary Diffie-Hellman [DH-X9.42] provide the necessary data origin
data origin authentication. Static-Static Diffie-Hellman [DH-X9.42] authentication. Static-Static Diffie-Hellman [DH-X9.42] does provide
does provide the necessary data origin authentication when both the the necessary data origin authentication when both the originator and
originator and recipient public keys are bound to appropriate recipient public keys are bound to appropriate identities in X.509
identities in X.509 certificates. certificates.
[*** NEW ***] When more than two parties share the same message- When more than two parties share the same message-authentication key,
authentication key, data origin authentication is not provided. Any data origin authentication is not provided. Any party that knows the
party that knows the message-authentication key can compute a valid message-authentication key can compute a valid MAC, therefore the
MAC, therefore the message could originate from any one of the message could originate from any one of the parties.
parties.
Implementations must randomly generate content-encryption keys, Implementations must randomly generate content-encryption keys,
message-authentication keys, initialization vectors (IVs), and message-authentication keys, initialization vectors (IVs), and
padding. Also, the generation of public/private key pairs relies on padding. Also, the generation of public/private key pairs relies on
a random numbers. The use of inadequate pseudo-random number a random numbers. The use of inadequate pseudo-random number
generators (PRNGs) to generate cryptographic keys can result in generators (PRNGs) to generate cryptographic keys can result in
little or no security. An attacker may find it much easier to little or no security. An attacker may find it much easier to
reproduce the PRNG environment that produced the keys, searching the reproduce the PRNG environment that produced the keys, searching the
resulting small set of possibilities, rather than brute force resulting small set of possibilities, rather than brute force
searching the whole key space. The generation of quality random searching the whole key space. The generation of quality random
skipping to change at page 52, line 39 skipping to change at page 52, line 38
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 the CMS, particularly those employing the CMS to support
interactive applications, should be aware that PKCS #1 Version 1.5 as
specified in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen
ciphertext attacks when applied for encryption purposes.
Exploitation of this identified vulnerability, revealing the result
of a particular RSA decryption, requires access to an oracle which
will respond to a large number of ciphertexts (based on currently
available results, hundreds of thousands or more), which are
constructed adaptively in response to previously-received replies
providing information on the successes or failures of attempted
decryption operations. As a result, the attack appears significantly
less feasible to perpetrate for store-and-forward S/MIME environments
than for directly interactive protocols. Where the CMS constructs
are applied as an intermediate encryption layer within an interactive
request-response communications environment, exploitation could be
more feasible.
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
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
alternative. To resolve the adaptive chosen ciphertext
vulnerability, the PKCS #1 Version 2.0 specifies and recommends use
of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption
is used to provide confidentiality. Designers of protocols and
systems employing the CMS for interactive environments should either
consider usage of OAEP, or should ensure that information which could
reveal the success or failure of attempted PKCS #1 Version 1.5
decryption operations is not provided. Support for OAEP will likely
be added to a future version of 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.
 End of changes. 

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