draft-ietf-smime-cms-08.txt   draft-ietf-smime-cms-09.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet Draft SPYRUS Internet Draft SPYRUS
expires in six months November 1998 expires in six months November 1998
Cryptographic Message Syntax Cryptographic Message Syntax
<draft-ietf-smime-cms-08.txt> <draft-ietf-smime-cms-09.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 4, line 22 skipping to change at page 4, line 22
The typical application of the signed-data content type represents The typical application of the signed-data content type represents
one signer's digital signature on content of the data content type. one signer's digital signature on content of the data content type.
Another typical application disseminates certificates and certificate Another typical application disseminates certificates and certificate
revocation lists (CRLs). revocation lists (CRLs).
The process by which signed-data is constructed involves the The process by which signed-data is constructed involves the
following steps: following steps:
1. For each signer, a message digest, or hash value, is computed 1. For each signer, a message digest, or hash value, is computed
on the content with a signer-specific message-digest algorithm. on the content with a signer-specific message-digest algorithm.
If two signers employ the same message digest algorithm, then the If the signer is signing any information other than the content,
message digest need be computed for only one of them. If the the message digest of the content and the other information are
signer is signing any information other than the content, the
message digest of the content and the other information are
digested with the signer's message digest algorithm (see Section digested with the signer's message digest algorithm (see Section
5.4), and the result becomes the "message digest." 5.4), and the result becomes the "message digest."
2. For each signer, the message digest is digitally signed using 2. For each signer, the message digest is digitally signed using
the signer's private key. the signer's private key.
3. For each signer, the signature value and other signer-specific 3. For each signer, the signature value and other signer-specific
information are collected into a SignerInfo value, as defined in information are collected into a SignerInfo value, as defined in
Section 5.3. Certificates and CRLs for each signer, and those not Section 5.3. Certificates and CRLs for each signer, and those not
corresponding to any signer, are collected in this step. corresponding to any signer, are collected in this step.
skipping to change at page 8, line 15 skipping to change at page 8, line 12
signedAttributes is a collection of attributes that are signed. signedAttributes is a collection of attributes that are signed.
The field is optional, but it must be present if the content type The field is optional, but it must be present if the content type
of the EncapsulatedContentInfo value being signed is not id-data. of the EncapsulatedContentInfo value being signed is not id-data.
Each SignedAttribute in the SET must be DER encoded. Useful Each SignedAttribute in the SET must be DER encoded. Useful
attribute types, such as signing time, are defined in Section 11. attribute types, such as signing time, are defined in Section 11.
If the field is present, it must contain, at a minimum, the If the field is present, it must contain, at a minimum, the
following two attributes: following two attributes:
A content-type attribute having as its value the content type A content-type attribute having as its value the content type
of the EncapsulatedContentInfo value being signed. Section of the EncapsulatedContentInfo value being signed. Section
11.1 defines the content-type attribute. The content-type is 11.1 defines the content-type attribute. The content-type
not required when used as part of a countersignature unsigned attribute is not required when used as part of a
attribute as defined in section 11.4. countersignature unsigned attribute as defined in section 11.4.
A message-digest attribute, having as its value the message A message-digest attribute, having as its value the message
digest of the content. Section 11.2 defines the message-digest digest of the content. Section 11.2 defines the message-digest
attribute. attribute.
signatureAlgorithm identifies the signature algorithm, and any signatureAlgorithm identifies the signature algorithm, and any
associated parameters, used by the signer to generate the digital associated parameters, used by the signer to generate the digital
signature. signature.
signature is the result of digital signature generation, using the signature is the result of digital signature generation, using the
skipping to change at page 11, line 43 skipping to change at page 11, line 36
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
The enveloped-data content type shall have ASN.1 type EnvelopedData: The enveloped-data content type shall have ASN.1 type EnvelopedData:
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,
plaintextAttrs [1] IMPLICIT PlaintextAttributes 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 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
PlaintextAttributes ::= SET SIZE (1..MAX) OF Attribute
The fields of type EnvelopedData have the following meanings: The fields of type EnvelopedData have the following meanings:
version is the syntax version number. If originatorInfo is version is the syntax version number. If originatorInfo is
present, then version shall be 2. If any of the RecipientInfo present, then version shall be 2. If any of the RecipientInfo
structures included have a version other than 0, then the version structures included have a version other than 0, then the version
shall be 2. If originatorInfo is absent and all of the shall be 2. If plaintextAttrs is present, then version shall be
RecipientInfo structures are version 0, then version shall be 0. 2. If originatorInfo is absent, all of the RecipientInfo
structures are version 0, and plaintextAttrs is absent, then
version shall be 0.
originatorInfo optionally provides information about the originatorInfo optionally provides information about the
originator. It is present only if required by the key management originator. It is present only if required by the key management
algorithm. It may contain certificates 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 make chains contained in certs are intended to be sufficient to make chains
skipping to change at page 12, line 48 skipping to change at page 12, line 43
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.
plaintextAttrs is a collection of attributes that are not
encrypted. The field is optional. Useful attribute types are
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 is used for all recipients. key is used for all recipients.
skipping to change at page 15, line 4 skipping to change at page 14, line 49
recipientEncryptedKeys RecipientEncryptedKeys } recipientEncryptedKeys RecipientEncryptedKeys }
OriginatorIdentifierOrKey ::= CHOICE { OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier, subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey } originatorKey [1] OriginatorPublicKey }
OriginatorPublicKey ::= SEQUENCE { OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier, algorithm AlgorithmIdentifier,
publicKey BIT STRING } publicKey BIT STRING }
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
RecipientEncryptedKey ::= SEQUENCE { RecipientEncryptedKey ::= SEQUENCE {
rid KeyAgreeRecipientIdentifier, rid KeyAgreeRecipientIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
KeyAgreeRecipientIdentifier ::= CHOICE { KeyAgreeRecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
rKeyId [0] IMPLICIT RecipientKeyIdentifier } rKeyId [0] IMPLICIT RecipientKeyIdentifier }
RecipientKeyIdentifier ::= SEQUENCE { RecipientKeyIdentifier ::= SEQUENCE {
subjectKeyIdentifier SubjectKeyIdentifier, subjectKeyIdentifier SubjectKeyIdentifier,
skipping to change at page 20, line 4 skipping to change at page 19, line 50
The typical application of the encrypted-data content type will be to The typical application of the encrypted-data content type will be to
encrypt the content of the data content type for local storage, encrypt the content of the data content type for local storage,
perhaps where the encryption key is a password. perhaps where the encryption key is a password.
The following object identifier identifies the encrypted-data content The following object identifier identifies the encrypted-data content
type: type:
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
The encrypted-data content type shall have ASN.1 type EncryptedData: The encrypted-data content type shall have ASN.1 type EncryptedData:
EncryptedData ::= SEQUENCE { EncryptedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
encryptedContentInfo EncryptedContentInfo } encryptedContentInfo EncryptedContentInfo,
plaintextAttrs [1] IMPLICIT PlaintextAttributes OPTIONAL }
The fields of type EncryptedData have the following meanings: The fields of type EncryptedData have the following meanings:
version is the syntax version number. It shall be 0. version is the syntax version number. If plaintextAttrs is
present, then version shall be 2. If plaintextAttrs is absent,
then version shall be 0.
encryptedContentInfo is the encrypted content information, as encryptedContentInfo is the encrypted content information, as
defined in Section 6.1. defined in Section 6.1.
plaintextAttrs is a collection of attributes that are not
encrypted. The field is optional. Useful attribute types are
defined in Section 11.
9 Authenticated-data Content Type 9 Authenticated-data Content Type
The authenticated-data content type consists of content of any type, The authenticated-data content type consists of content of any type,
a message authentication code (MAC), and encrypted authentication a message authentication code (MAC), and encrypted authentication
keys for one or more recipients. The combination of the MAC and one keys for one or more recipients. The combination of the MAC and one
encrypted authentication key for a recipient is necessary for that encrypted authentication key for a recipient is necessary for that
recipient to validate the integrity of the content. Any type of recipient to validate the integrity of the content. Any type of
content can be integrity protected for an arbitrary number of content can be integrity protected for an arbitrary number of
recipients. recipients.
skipping to change at page 20, line 43 skipping to change at page 20, line 49
2. The message-authentication key is encrypted for each 2. The message-authentication key is encrypted for each
recipient. The details of this encryption depend on the key recipient. The details of this encryption depend on the key
management algorithm used. management algorithm used.
3. For each recipient, the encrypted message-authentication key 3. For each recipient, the encrypted message-authentication key
and other recipient-specific information are collected into a and other recipient-specific information are collected into a
RecipientInfo value, defined in Section 6.2. RecipientInfo value, defined in Section 6.2.
4. Using the message-authentication key, the originator computes 4. Using the message-authentication key, the originator computes
a MAC value on the content. If the originator is authenticating a MAC value on the content. If the originator is authenticating
any information in addition to the content (see Section 9.2), the any information in addition to the content (see Section 9.2), a
MAC value of the content and the other information are generated message digest is calculated on the content, the message digest of
using the same message authentication code algorithm and key, and the content and the other information are authenticated using the
the result becomes the "MAC value." message-authentication key, and the result becomes the "MAC
value."
9.1 AuthenticatedData Type 9.1 AuthenticatedData Type
The following object identifier identifies the authenticated-data The following object identifier identifies the authenticated-data
content type: content type:
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-ct-authData OBJECT IDENTIFIER ::= { 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)
ct(1) 2 } ct(1) 2 }
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,
authAttributesInfo [1] IMPLICIT AuthAttributesInfo OPTIONAL,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
authenticatedAttributes [1] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode, mac MessageAuthenticationCode,
unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL }
AuthAttributesInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
authenticatedAttributes AuthAttributes }
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 shall be 0. version is the syntax version number. It shall be 0.
originatorInfo optionally provides information about the originatorInfo optionally provides information about the
originator. It is present only if required by the key management originator. It is present only if required by the key management
algorithm. It may contain certificates, 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.
recipientInfos is a collection of per-recipient information, as recipientInfos is a collection of per-recipient information, as
defined in Section 6.1. There must be at least one element in the defined in Section 6.1. There must be at least one element in the
collection. collection.
macAlgorithm is a message authentication code algorithm macAlgorithm is a message authentication code (MAC) algorithm
identifier. It identifies the message authentication code identifier. It identifies the MAC algorithm, along with any
algorithm, along with any associated parameters, used by the associated parameters, used by the originator. Placement of the
originator. Placement of the macAlgorithm field facilitates one- macAlgorithm field facilitates one-pass processing by the
pass processing by the recipient. recipient.
encapContentInfo is the content that is authenticated, as defined
in section 5.2.
authenticatedAttributes is a collection of attributes that are authAttributesInfo is a message digest algorithm identifier
authenticated. The field is optional, but it must be present if followed by a collection of authenticated attributes. The
the content type of the EncapsulatedContentInfo value being authAttributesInfo structure is optional, but it must be present
authenticated is not id-data. Each AuthenticatedAttribute in the if the content type of the EncapsulatedContentInfo value being
SET must be DER encoded. Useful attribute types are defined in authenticated is not id-data. Placement of the authAttributesInfo
Section 11. If the field is present, it must contain, at a digestAlgorithm field facilitates one-pass processing by the
recipient. Each AuthenticatedAttribute in the SET must be DER
encoded. Useful attribute types are defined in Section 11. If
the authAttributesInfo structure is present, it must contain, at a
minimum, the following two attributes: minimum, the following two attributes:
A content-type attribute having as its value the content type A content-type attribute having as its value the content type
of the EncapsulatedContentInfo value being signed. Section of the EncapsulatedContentInfo value being authenticated.
11.1 defines the content-type attribute. Section 11.1 defines the content-type attribute.
A mac-value attribute, having as its value the message A message-digest attribute, having as its value the message
authentication code of the content. Section 11.5 defines the digest of the content. Section 11.2 defines the message-digest
mac-value attribute. attribute.
encapContentInfo is the content that is authenticated, as defined
in section 5.2.
mac is the message authentication code. mac is the message authentication code.
unauthenticatedAttributes is a collection of attributes that are unauthenticatedAttributes is a collection of attributes that are
not authenticated. The field is optional. To date, no attributes not 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 the message being (MAC) on either the message being authenticated or a message digest
authenticated together with the originator's authenticated of message being authenticated together with the originator's
attributes. authenticated attributes.
If authenticatedAttributes field is absent, the input to the MAC If authAttributesInfo structure is absent, the input to the MAC
calculation process is the value of the encapContentInfo eContent calculation process is the value of the encapContentInfo eContent
OCTET STRING. Only the octets comprising the value of the eContent OCTET STRING. Only the octets comprising the value of the eContent
OCTET STRING are input to the MAC algorithm; the tag and the length OCTET STRING are input to the MAC algorithm; the tag and the length
octets are omitted. This has the advantage that the length of the octets are omitted. This has the advantage that the length of the
content being authenticated need not be known in advance of the MAC content being authenticated need not be known in advance of the MAC
generation process. Although the encapContentInfo eContent OCTET generation process.
STRING tag and length octets are not included in the MAC calculation,
they are still protected by other means. The length octets are
protected by the nature of the MAC algorithm since it is
computationally infeasible to find any two distinct messages of any
length that have the same MAC.
If authenticatedAttributes field is present, the content-type If authAttributesInfo structure is present, the content-type
attribute (as described in Section 11.1) and the mac-value attribute attribute (as described in Section 11.1) and the message-digest
(as described in section 11.5) must be included, and the input to the attribute (as described in section 11.2) must be included, and the
MAC calculation process is the DER encoding of input to the MAC calculation process is the DER encoding of
authenticatedAttributes. A separate encoding of the authAttributesInfo authenticatedAttributes. Encoding of the
authenticatedAttributes field is performed for MAC calculation. The authAttributesInfo authenticatedAttributes field uses an EXPLICIT SET
IMPLICIT [0] tag in the authenticatedAttributes field is not used for OF tag. The DER encoding of the SET OF tag is included in the MAC
the DER encoding, rather an EXPLICIT SET OF tag is used. The DER calculation along with the length and content octets of the
encoding of the SET OF tag, rather than of the IMPLICIT [0] tag, is authAttributesInfo authenticatedAttributes value.
to be included in the MAC calculation along with the length and
content octets of the authenticatedAttributes value. The message digest calculation process computes a message digest on
the content being authenticated. The initial input to the message
digest calculation process is the "value" of the encapsulated content
being authenticated. Specifically, the input is the encapContentInfo
eContent OCTET STRING to which the authentication process is applied.
Only the octets comprising the value of the encapContentInfo eContent
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
content being authenticated need not be known in advance. Although
the encapContentInfo eContent OCTET STRING tag and length octets are
not included in the message digest calculation, they are still
protected by other means. The length octets are protected by the
nature of the message digest algorithm since it is computationally
infeasible to find any two distinct messages of any length that have
the same message digest.
The input to the MAC calculation process includes the MAC input data, The input to the MAC calculation process includes the MAC input data,
defined above, and an authentication key conveyed in a recipientInfo defined above, and an authentication key conveyed in a recipientInfo
structure. The details of MAC calculation depend on the MAC structure. The details of MAC calculation depend on the MAC
algorithm employed (e.g., DES-MAC and HMAC). The object identifier, algorithm employed (e.g., HMAC). The object identifier, along with
along with any parameters, that specifies the MAC algorithm employed any parameters, that specifies the MAC algorithm employed by the
by the originator is carried in the macAlgorithm field. The MAC originator is carried in the macAlgorithm field. The MAC value
value generated by the originator is encoded as an OCTET STRING and generated by the originator is encoded as an OCTET STRING and carried
carried in the mac field. in the mac field.
9.3 MAC Validation 9.3 MAC Validation
The input to the MAC validation process includes the input data The input to the MAC validation process includes the input data
(determined based on the presence or absence of authenticated (determined based on the presence or absence of the
attributes, as defined in 9.2), and the authentication key conveyed authAttributesInfo structure, as defined in 9.2), and the
in recipientInfo. The details of the MAC validation process depend authentication key conveyed in recipientInfo. The details of the MAC
on the MAC algorithm employed. validation process depend on the MAC algorithm employed.
The recipient may not rely on any MAC values computed by the The recipient may not rely on any MAC values or message digest values
originator. If the originator includes authenticated attributes, computed by the originator. The content is authenticated as
then the content of the authenticatedAttributes must be authenticated described in section 9.2. If the originator includes authenticated
as described in section 9.2. For the MAC to be valid, the message attributes, then the content of the authAttributesInfo
MAC value calculated by the recipient must be the same as the value authenticatedAttributes is authenticated as described in section 9.2.
of the macValue attribute included in the authenticatedAttributes.
Likewise, the attribute MAC value calculated by the recipient must be For authentication to succeed, the message MAC value calculated by
the same as the value of the mac field included in the the recipient must be the same as the value of the mac field.
authenticatedData. Similarly, for authentication to succeed when the authAttributesInfo
structure is present, the content message digest value calculated by
the recipient must be the same as the message digest value included
in the authAttributesInfo authenticatedAttributes message-digest
attribute.
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:
skipping to change at page 25, line 48 skipping to change at page 26, line 23
Internet in RFC TBD. Internet in RFC TBD.
The definition of CertificateList is imported from X.509. The definition of CertificateList is imported from X.509.
CertificateRevocationLists ::= SET OF CertificateList CertificateRevocationLists ::= SET OF CertificateList
10.2.2 CertificateChoices 10.2.2 CertificateChoices
The CertificateChoices type gives either a PKCS #6 extended The CertificateChoices type gives either a PKCS #6 extended
certificate [PKCS #6], an X.509 certificate, or an X.509 attribute certificate [PKCS #6], an X.509 certificate, or an X.509 attribute
certificate. The PKCS #6 extended certificate is obsolete. PKCS #5 certificate. The PKCS #6 extended certificate is obsolete. PKCS #6
certificates are included for backward compatibility, and their use certificates are included for backward compatibility, and their use
should be avoided. The Internet profile of X.509 certificates is should be avoided. The Internet profile of X.509 certificates is
specified in RFC TBD. specified in RFC TBD.
The definitions of Certificate and AttributeCertificate are imported The definitions of Certificate and AttributeCertificate are imported
from X.509. from X.509.
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509 certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
skipping to change at page 28, line 26 skipping to change at page 28, line 48
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
encapContentInfo eContent OCTET STRING being signed in signed-data encapContentInfo eContent OCTET STRING being signed in signed-data
(see section 5.4), where the message digest is computed using the (see section 5.4) or authenticated in authenticated-data (see section
signer's message digest algorithm. 9.2). For signed-data, the message digest is computed using the
signer's message digest algorithm. For authenticated-data, the
message digest is computed using the message digest algorithm
identified by the authAttributesInfo digestAlgorithm.
Within signed-data, the message-digest signed attribute type is Within signed-data, the message-digest signed attribute type is
required if there are any attributes present. required if there are any attributes present. Within authenticated-
data, the message-digest authenticated attribute type is required if
there are any attributes present.
The message-digest attribute must be a signed attribute; it cannot be The message-digest attribute must be a signed attribute or an
an unsigned attribute, an authenticated attribute, or unauthenticated authenticated attribute; it cannot be an unsigned attribute or
attribute. unauthenticated 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
skipping to change at page 31, line 13 skipping to change at page 31, line 41
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.
11.5 Message Authentication Code (MAC) Value
The MAC-value attribute type specifies the MAC of the
encapContentInfo eContent OCTET STRING being authenticated in
authenticated-data (see section 9), where the MAC value is computed
using the originator's MAC algorithm and the data-authentication key.
Within authenticated-data, the MAC-value attribute type is required
if there are any authenticated attributes present.
The MAC-value attribute must be a authenticated attribute; it cannot
be an signed attribute, an unsigned attribute, or unauthenticated
attribute.
The following object identifier identifies the MAC-value attribute:
id-macValue OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 8 }
MAC-value attribute values have ASN.1 type MACValue:
MACValue ::= OCTET STRING
A MAC-value attribute must have a single attribute value, even though
the syntax is defined as a SET OF AttributeValue. There must not be
zero or multiple instances of AttributeValue present.
The AuthAttributes syntax is defined as a SET OF Attributes. The
AuthAttributes in an AuthenticatedData must not include multiple
instances of the MAC-value attribute.
12 Supported Algorithms 12 Supported Algorithms
This section lists the algorithms that must be implemented. This section lists the algorithms that must be implemented.
Additional algorithms that should be implemented are also included. Additional algorithms that should be implemented are also included.
12.1 Digest Algorithms 12.1 Digest Algorithms
CMS implementations must include SHA-1. CMS implementations may CMS implementations must include SHA-1. CMS implementations should
include MD5. include MD5.
Digest algorithm identifiers are located in the SignedData Digest algorithm identifiers are located in the SignedData
digestAlgorithms field, the SignerInfo digestAlgorithm field, and the digestAlgorithms field, the SignerInfo digestAlgorithm field, the
DigestedData digestAlgorithm field. DigestedData digestAlgorithm field, and the AuthenticatedData
authAttributesInfo digestAlgorithm field.
Digest values are located in the DigestedData digest field, and Digest values are located in the DigestedData digest field, and
digest values are located in the Message Digest authenticated digest values are located in the Message Digest authenticated
attribute. In addition, digest values are input to signature attribute. In addition, digest values are input to signature
algorithms. algorithms.
12.1.1 SHA-1 12.1.1 SHA-1
The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The
algorithm identifier for SHA-1 is: algorithm identifier for SHA-1 is:
skipping to change at page 33, line 48 skipping to change at page 33, line 48
oiw(14) secsig(3) algorithm(2) 26 } oiw(14) secsig(3) algorithm(2) 26 }
12.3 Key Management Algorithms 12.3 Key Management Algorithms
CMS accommodates three general key management techniques: key CMS accommodates three general key management techniques: key
agreement, key transport, and previously distributed symmetric key- agreement, key transport, and previously distributed symmetric key-
encryption keys. encryption keys.
12.3.1 Key Agreement Algorithms 12.3.1 Key Agreement Algorithms
CMS implementations must include key agreement using X9.42 CMS implementations must include key agreement using X9.42 Ephemeral-
Ephemeral-Static Diffie-Hellman. CMS implementations must include Static Diffie-Hellman.
key agreement of Triple-DES pairwise key-encryption keys and Triple-
DES wrapping Triple-DES content-encryption keys. CMS implementations Any symmetric encryption algorithm that a CMS implementation includes
should include key agreement of RC2 pairwise key-encryption keys and as a content-encryption algorithm must also be included as a key-
RC2 wrapping RC2 content-encryption keys. The key wrap algorithm is encryption algorithm. CMS implementations must include key agreement
of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of
Triple-DES content-encryption keys. CMS implementations should
include key agreement of RC2 pairwise key-encryption keys and RC2
wrapping of RC2 content-encryption keys. The key wrap algorithm is
described in section 12.6. described in section 12.6.
A CMS implementation may support mixed key-encryption and content-
encryption algorithms. For example, a 128-bit RC2 content-encryption
key may be wrapped with 168-bit Triple-DES key-encryption key.
Similarly, a 40-bit RC2 content-encryption key may be wrapped with
128-bit RC2 key-encryption key.
Key agreement algorithm identifiers are located in the EnvelopedData Key agreement algorithm identifiers are located in the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm field. RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
Key wrap algorithm identifiers are located in the KeyWrapAlgorithm
parameters within the EnvelopedData RecipientInfo
KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
Wrapped content-encryption keys are located in the EnvelopedData Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys
encryptedKey field. encryptedKey field.
12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman with Triple-DES 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman
Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1
[RFC TBD1]. When using Ephemeral-Static Diffie-Hellman with Triple- [RFC TBD1]. When using Ephemeral-Static Diffie-Hellman, the
DES, the EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are used as
used as follows: follows:
version must be 3. version must be 3.
originator must be the originatorKey alternative. The originator must be the originatorKey alternative. The
originatorKey algorithm fields must contain the dh-public-number originatorKey algorithm fields must contain the dh-public-number
object identifier with absent parameters. The originatorKey object identifier with absent parameters. The originatorKey
publicKey field must contain the sender's ephemeral public key. publicKey field must contain the sender's ephemeral public key.
The dh-public-number object identifier is: The dh-public-number object identifier is:
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 } us(840) ansi-x942(10046) number-type(2) 1 }
ukm may be absent. The ukm is used to ensure that a different ukm may be absent. The ukm is used to ensure that a different
key-encryption key is generated when the ephemeral private key key-encryption key is generated when the ephemeral private key
might be used more than once. might be used more than once.
keyEncryptionAlgorithm must be the id-alg-ESDHwith3DES algorithm keyEncryptionAlgorithm must be the id-alg-ESDH algorithm
identifier with absent parameters. The id-alg-ESDHwith3DES identifier. The algorithm identifier parameters field must be
algorithm identifier is: present and contain a KeyWrapAlgorithm value. The
KeyWrapAlgorithm denotes the symmetric encryption algorithm used
id-alg-ESDHwith3DES OBJECT IDENTIFIER ::= { iso(1) member-body(2) to encrypt the content-encryption key with the pairwise key-
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 1 } encryption key generated using the Ephemeral-Static Diffie-Hellman
key agreement algorithm. Triple-DES and RC2 key wrap algorithms
recipientEncryptedKeys contains an identifier and an encrypted key are discussed in section 12.3.3. The id-alg-ESDH algorithm
for each recipient. The RecipientEncryptedKey identifier and parameter syntax is:
KeyAgreeRecipientIdentifier must contain either the
issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static public key.
RecipientEncryptedKey EncryptedKey must contain the content-
encryption Triple-DES key wrapped in the pairwise key agreement
Triple-DES key.
12.3.1.2 X9.42 Ephemeral-Static Diffie-Hellman with RC2
Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1
[RFC TBD1]. When using Ephemeral-Static Diffie-Hellman with RC2, the
EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are used as
follows:
version must be 3.
originator must be the originatorKey alternative. The
originatorKey algorithm fields must contain the dh-public-number
object identifier with absent parameters. The originatorKey
publicKey field must contain the sender's ephemeral public key.
The dh-public-number object identifier is:
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
ukm may be absent. The ukm is used to ensure that a different
key-encryption key is generated if the ephemeral private key might
be used for more than once.
keyEncryptionAlgorithm must be the id-alg-ESDHwithRC2 algorithm id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
identifier with absent parameters. The id-alg-ESDHwithRC2 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
algorithm identifier is:
id-alg-ESDHwithRC2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) KeyWrapAlgorithm ::= AlgorithmIdentifier
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 2 }
recipientEncryptedKeys contains an identifier and an encrypted key recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier must contain either the KeyAgreeRecipientIdentifier must contain either the
issuerAndSerialNumber identifying the recipient's certificate or issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static public key. certificate contains the recipient's static public key.
RecipientEncryptedKey EncryptedKey must contain the content- RecipientEncryptedKey EncryptedKey must contain the content-
encryption RC2 key wrapped in the pairwise key agreement RC2 key. encryption key encrypted with the Ephemeral-Static Diffie-Hellman
generated pairwise key-encryption key using the algorithm
specified by the KeyWrapAlgortihm.
12.3.2 Key Transport Algorithms 12.3.2 Key Transport Algorithms
CMS implementations should include key transport using RSA. RSA CMS implementations should include key transport using RSA. RSA
implementations must include key transport of Triple-DES content- implementations must include key transport of Triple-DES content-
encryption keys. RSA implementations should include key transport of encryption keys. RSA implementations should include key transport of
RC2 content-encryption keys. RC2 content-encryption keys.
Key transport algorithm identifiers are located in the EnvelopedData Key transport algorithm identifiers are located in the EnvelopedData
RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm field. RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm field.
skipping to change at page 36, line 34 skipping to change at page 36, line 17
The use of RSA encryption, as defined in RFC 2313, to provide The use of RSA encryption, as defined in RFC 2313, to provide
confidentiality has a known vulnerability concerns. The vulnerability confidentiality has a known vulnerability concerns. The vulnerability
is primarily relevant to usage in interactive applications rather is primarily relevant to usage in interactive applications rather
than to store-and-forward environments. Further information and than to store-and-forward environments. Further information and
proposed countermeasures are discussed in the Security Considerations proposed countermeasures are discussed in the Security Considerations
section of this document. section of this document.
12.3.3 Symmetric Key-Encryption Key Algorithms 12.3.3 Symmetric Key-Encryption Key Algorithms
CMS implementations may include symmetric key-encryption key CMS implementations may include symmetric key-encryption key
management. Such implementations must include Triple-DES key- management. Such CMS implementations must include Triple-DES key-
encryption keys wrapping Triple-DES content-encryption keys, and such encryption keys wrapping Triple-DES content-encryption keys, and such
implementations should include Triple-DES key-encryption keys CMS implementations should include RC2 key-encryption keys wrapping
wrapping RC2 content-encryption keys. The key wrap algorithm is RC2 content-encryption keys. The key wrap algorithm is specified in
specified in section 12.6. section 12.6.
Symmetric key-encryption key algorithm identifiers are located in the Key wrap algorithm identifiers are located in the EnvelopedData
EnvelopedData RecipientInfo KEKRecipientInfo keyEncryptionAlgorithm RecipientInfo KEKRecipientInfo keyEncryptionAlgorithm field.
field.
Wrapped content-encryption keys are located in the EnvelopedData Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfo KEKRecipientInfo encryptedKey field. RecipientInfo KEKRecipientInfo encryptedKey field.
In conjunction with key agreement algorithms, CMS implementations
must include encryption of content-encryption keys with the pairwise
key-encryption key generated using a key agreement algorithm. To
support key agreement, key wrap algorithm identifiers are located in
the KeyWrapAlgorithm parameter of the EnvelopedData RecipientInfo
KeyAgreeRecipientInfo keyEncryptionAlgorithm field, and wrapped
content-encryption keys are located in the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys
encryptedKey field.
12.3.3.1 Triple-DES Key Wrap 12.3.3.1 Triple-DES Key Wrap
Triple-DES key encryption has the algorithm identifier: Triple-DES key encryption has the algorithm identifier:
id-alg-3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 3 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 3 }
The AlgorithmIdentifier parameter field must be NULL. The AlgorithmIdentifier parameter field must be NULL.
Distribution of the Triple-DES key-encryption key used to encrypt the Out-of-band distribution of the Triple-DES key-encryption key used to
Triple-DES content-encryption key is out of the scope of this encrypt the Triple-DES content-encryption key is out of the scope of
document. this document.
12.3.3.2 RC2 Key Wrap 12.3.3.2 RC2 Key Wrap
RC2 key encryption has the algorithm identifier: RC2 key encryption has the algorithm identifier:
id-alg-RC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-RC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 4 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 4 }
The AlgorithmIdentifier parameter field must be RC2wrapParameter: The AlgorithmIdentifier parameter field must be RC2wrapParameter:
skipping to change at page 37, line 30 skipping to change at page 37, line 25
RC2ParameterVersion ::= INTEGER RC2ParameterVersion ::= INTEGER
The RC2 effective-key-bits (key size) greater than 32 and less than The RC2 effective-key-bits (key size) greater than 32 and less than
256 is encoded in the RC2ParameterVersion. For the effective-key- 256 is encoded in the RC2ParameterVersion. For the effective-key-
bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
and 58 respectively. These values are not simply the RC2 key length. and 58 respectively. These values are not simply the RC2 key length.
Note that the value 160 must be encoded as two octets (00 A0), Note that the value 160 must be encoded as two octets (00 A0),
because the one octet (A0) encoding represents a negative number. because the one octet (A0) encoding represents a negative number.
Distribution of the RC2 key-encryption key used to encrypt the RC2 Out-of-band distribution of the RC2 key-encryption key used to
content-encryption key is out of the scope of this document. encrypt the RC2 content-encryption key is out of the scope of this
document.
12.4 Content Encryption Algorithms 12.4 Content Encryption Algorithms
CMS implementations must include Triple-DES in CBC mode. CMS CMS implementations must include Triple-DES in CBC mode. CMS
implementations should include RC2 in CBC mode. implementations should include RC2 in CBC mode.
Content encryption algorithms identifiers are located in the Content encryption algorithms identifiers are located in the
EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field
and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm
field. field.
skipping to change at page 38, line 20 skipping to change at page 38, line 15
CBCParameter ::= IV CBCParameter ::= IV
IV ::= OCTET STRING -- exactly 8 octets IV ::= OCTET STRING -- exactly 8 octets
12.4.2 RC2 CBC 12.4.2 RC2 CBC
The RC2 algorithm is described in RFC 2268 [RFC 2268]. The algorithm The RC2 algorithm is described in RFC 2268 [RFC 2268]. The algorithm
identifier for RC2 in CBC mode is: identifier for RC2 in CBC mode is:
RC2-CBC OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 } rsadsi(113549) encryptionAlgorithm(3) 2 }
The AlgorithmIdentifier parameters field must be present and contain The AlgorithmIdentifier parameters field must be present and contain
a RC2-CBC: a RC2CBCParameter:
RC2-CBC parameter ::= SEQUENCE { RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER, rc2ParameterVersion INTEGER,
iv OCTET STRING -- exactly 8 octets -- } iv OCTET STRING } -- exactly 8 octets
The RC2 effective-key-bits (key size) greater than 32 and less than The RC2 effective-key-bits (key size) greater than 32 and less than
256 is encoded in the rc2ParameterVersion. For the effective-key- 256 is encoded in the rc2ParameterVersion. For the effective-key-
bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
and 58 respectively. These values are not simply the RC2 key length. and 58 respectively. These values are not simply the RC2 key length.
Note that the value 160 must be encoded as two octets (00 A0), since Note that the value 160 must be encoded as two octets (00 A0), since
the one octet (A0) encoding represents a negative number. the one octet (A0) encoding represents a negative number.
12.5 Message Authentication Code Algorithms 12.5 Message Authentication Code Algorithms
CMS implementations that support authenticatedData must include HMAC CMS implementations that support authenticatedData must include HMAC
with SHA-1. CMS implementations may also include DES MAC. with SHA-1.
MAC algorithm identifiers are located in the AuthenticatedData MAC algorithm identifiers are located in the AuthenticatedData
macAlgorithm field. macAlgorithm field.
MAC values are located in the AuthenticatedData mac field. MAC MAC values are located in the AuthenticatedData mac field. MAC
values are also located in the mac-value authenticated attribute. values are also located in the mac-value authenticated attribute.
12.5.1 HMAC with SHA-1 12.5.1 HMAC with SHA-1
The HMAC with SHA-1 algorithm is described in RFC 2104 [RFC 2104]. The HMAC with SHA-1 algorithm is described in RFC 2104 [RFC 2104].
The algorithm identifier for HMAC with SHA-1 is: The algorithm identifier for HMAC with SHA-1 is:
HMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) HMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
The AlgorithmIdentifier parameters field must be absent. The AlgorithmIdentifier parameters field must be absent.
12.5.2 DES MAC
The DES MAC algorithm is described in FIPS Pub 113 [DES MAC]. CMS
implementations choosing to implement DES MAC must support 32 bit MAC
values. CMS implementations should also support 64 bit MAC values.
The algorithm identifier for DES MAC is:
DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 10 }
The AlgorithmIdentifier parameters field must be present. The
parameters contain an INTEGER identifying the length in bits of the
MAC value, constrained to multiples of eight between 16 and 64:
DESMACLength ::= INTEGER -- may be 16, 24, 32, 40, 48, 56, or 64
12.6 CMS Key Wrap Algorithm 12.6 CMS Key Wrap Algorithm
CMS implementations must implement the key wrap algorithm specified CMS implementations must implement the key wrap algorithm specified
in this section. in this section.
Key Transport algorithms allow for the content-encryption key to be Key Transport algorithms allow for the content-encryption key to be
directly encrypted; however, key agreement and symmetric key- directly encrypted; however, key agreement and symmetric key-
encryption key algorithms encrypt the content-encryption key with a encryption key algorithms encrypt the content-encryption key with a
second symmetric encryption algorithm. This section describes how second symmetric encryption algorithm. This section describes how
the content-encryption key is formatted and encrypted. the content-encryption key is formatted and encrypted.
skipping to change at page 40, line 6 skipping to change at page 39, line 33
distributed out of band. For key agreement of RC2 key-encryption distributed out of band. For key agreement of RC2 key-encryption
keys, 128 bits must be generated as input to the key expansion keys, 128 bits must be generated as input to the key expansion
process used to compute the RC2 effective key [RFC 2268]. process used to compute the RC2 effective key [RFC 2268].
The block size of the key-encryption algorithm must be implicitly The block size of the key-encryption algorithm must be implicitly
determined from the KeyEncryptionAlgorithmIdentifier field. determined from the KeyEncryptionAlgorithmIdentifier field.
Likewise, the size of the content-encryption key must be implicitly Likewise, the size of the content-encryption key must be implicitly
determined from the ContentEncryptionAlgorithmIdentifier field. determined from the ContentEncryptionAlgorithmIdentifier field.
Since the same algorithm identifier is used for both 2-key and 3-key Since the same algorithm identifier is used for both 2-key and 3-key
Triple-DES, three keys are always wrapped for Triple-DES. Thus, 2- Triple-DES, three keys are always wrapped for Triple-DES. Thus,
key Triple-DES provides three keys where the first and third keys are 2-key Triple-DES provides three keys where the first and third keys
the same. are the same.
12.6.1 Sum of Sums Key Checksum 12.6.1 Key Checksum
The Sum of Sums [SUM] key checksum algorithm is: The Fletcher checksum [SUM] algorithm is used to provide an integrity
check value. The algorithm is:
1. Initialize two 16 bit integers, sum1 and sum2, to zero. 1. Initialize two 16 bit integers, sum1 and sum2, to zero.
2. Loop through the octets of the content-encryption key, most 2. Loop through the octets of the content-encryption key, most
significant octet to least significant octet. significant (first) octet to least significant (last) octet.
2a. Create a 16 bit integer, called temp, by concatenating 2a. Create a 16 bit integer, called temp, by concatenating
eight zero bits and the key octet. eight zero bits and the key octet.
2b. sum1 = sum1 + temp. 2b. sum1 = sum1 + temp.
2c. sum2 = sum2 + sum1. 2c. sum2 = sum2 + sum1.
3. Use sum2 as the checksum value. 3. Use sum2 as the checksum value.
12.6.2 Key Wrap 12.6.2 Key Wrap
1. Modify the content-encryption key to meet any restrictions on the key. 1. Modify the content-encryption key to meet any restrictions on the key.
For example, adjust the parity bits for each DES key comprising a For example, adjust the parity bits for each DES key comprising a
skipping to change at page 43, line 33 skipping to change at page 42, line 33
attrValues SET OF AttributeValue } attrValues SET OF AttributeValue }
AttributeValue ::= ANY AttributeValue ::= ANY
SignatureValue ::= OCTET STRING SignatureValue ::= OCTET STRING
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,
plaintextAttrs [1] IMPLICIT PlaintextAttributes 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 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
PlaintextAttributes ::= SET SIZE (1..MAX) OF Attribute
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo } kekri [2] KEKRecipientInfo }
EncryptedKey ::= OCTET STRING EncryptedKey ::= OCTET STRING
KeyTransRecipientInfo ::= SEQUENCE { KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2 version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier, rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE { RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
skipping to change at page 45, line 32 skipping to change at page 44, line 34
EncryptedData ::= SEQUENCE { EncryptedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
encryptedContentInfo EncryptedContentInfo } encryptedContentInfo EncryptedContentInfo }
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,
authAttributesInfo [1] IMPLICIT AuthAttributesInfo OPTIONAL,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
authenticatedAttributes [1] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode, mac MessageAuthenticationCode,
unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL }
AuthAttributesInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
authenticatedAttributes AuthAttributes }
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
CertificateRevocationLists ::= SET OF CertificateList CertificateRevocationLists ::= SET OF CertificateList
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509 certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57
CertificateSet ::= SET OF CertificateChoices CertificateSet ::= SET OF CertificateChoices
IssuerAndSerialNumber ::= SEQUENCE { IssuerAndSerialNumber ::= SEQUENCE {
skipping to change at page 48, line 14 skipping to change at page 47, line 22
References References
3DES Tuchman, W. "Hellman Presents No Shortcut Solutions To DES". 3DES Tuchman, W. "Hellman Presents No Shortcut Solutions To DES".
IEEE Spectrum, v. 16, n. 7, pp40-41. July 1979. IEEE Spectrum, v. 16, n. 7, pp40-41. July 1979.
DES American National Standards Institute. ANSI X3.106, DES American National Standards Institute. ANSI X3.106,
"American National Standard for Information Systems - Data "American National Standard for Information Systems - Data
Link Encryption". 1983. Link Encryption". 1983.
DES MAC National Institute of Standards and Technology. FIPS Pub 113:
Computer Data Authentication. May 1985.
DSS National Institute of Standards and Technology. DSS National Institute of Standards and Technology.
FIPS Pub 186: Digital Signature Standard. 19 May 1994. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax
Standard, Version 1.5. November 1993. Standard, Version 1.5. November 1993.
PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types, PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types,
Version 1.1. November 1993. Version 1.1. November 1993.
RFC 1321 Rivest, R. The MD5 Message-Digest Algorithm. April 1992. RFC 1321 Rivest, R. The MD5 Message-Digest Algorithm. April 1992.
skipping to change at page 49, line 4 skipping to change at page 48, line 11
RFC 2437 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. RFC 2437 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0.
October 1998. October 1998.
RFC TBD Housley, R., W. Ford, W. Polk, D. Solo. Internet RFC TBD Housley, R., W. Ford, W. Polk, D. Solo. Internet
X.509 Public Key Infrastructure: Certificate and CRL X.509 Public Key Infrastructure: Certificate and CRL
Profile. (currently draft-ietf-pkix-ipki-part1-*.txt) Profile. (currently draft-ietf-pkix-ipki-part1-*.txt)
RFC TBD1 Rescorla, E. Ephemeral-Static Diffie-Hellman Key RFC TBD1 Rescorla, E. Ephemeral-Static Diffie-Hellman Key
Agreement Method. (currently draft-ietf-smime-x942-*.txt) Agreement Method. (currently draft-ietf-smime-x942-*.txt)
RFC TBD2 Ramsdell, B. S/MIME Version 3 Message Specification. RFC TBD2 Ramsdell, B. S/MIME Version 3 Message Specification.
(currently draft-ietf-smime-msg-*.txt) (currently draft-ietf-smime-msg-*.txt)
RFC TBD3 Hoffman, P. Enhanced Security Services for S/MIME. RFC TBD3 Hoffman, P. Enhanced Security Services for S/MIME.
(currently draft-ietf-smime-ess-*.txt) (currently draft-ietf-smime-ess-*.txt)
SHA1 National Institute of Standards and Technology. SHA1 National Institute of Standards and Technology.
FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995.
SUM Fletcher, J. An Arithmetic Checksum for Serial SUM Fletcher, J. "An Arithmetic Checksum for Serial
Transmissions. Reprint UCRL-82569, Lawrence Livermore Transmissions", IEEE Transactions on Communication,
Laboraory, University of California. May 1979. Vol. COM-30, No. 1, pp. 247-252, January 1982.
X.208 CCITT. Recommendation X.208: Specification of Abstract X.208 CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
X.209 CCITT. Recommendation X.209: Specification of Basic Encoding X.209 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 CCITT. Recommendation X.501: The Directory - Models. 1988. X.501 CCITT. Recommendation X.501: The Directory - Models. 1988.
X.509 CCITT. Recommendation X.509: The Directory - Authentication X.509 CCITT. Recommendation X.509: The Directory - Authentication
skipping to change at page 49, line 37 skipping to change at page 48, line 45
Security Considerations Security Considerations
The Cryptographic Message Syntax provides a method for digitally The Cryptographic Message Syntax provides a method for digitally
signing data, digesting data, encrypting data, and authenticating signing data, digesting data, encrypting data, and authenticating
data. data.
Implementations must protect the signer's private key. Compromise of Implementations must protect the signer's private key. Compromise of
the signer's private key permits masquerade. the signer's private key permits masquerade.
Implementations must protect the key management private key, the Implementations must protect the key management private key, the key-
key-encryption key, and the content-encryption key. Compromise of encryption key, and the content-encryption key. Compromise of the
the key management private key or the key-encryption key may result key management private key or the key-encryption key may result in
in the disclosure of all messages protected with that key. the disclosure of all messages protected with that key. Similarly,
Similarly, compromise of the content-encryption key may result in compromise of the content-encryption key may result in disclosure of
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.
Implementations must randomly generate content-encryption keys, Implementations must randomly generate content-encryption keys,
message-authentication keys, initialization vectors (IVs), salt message-authentication keys, initialization vectors (IVs), salt
values, and padding. Also, the generation of public/private key values, and padding. Also, the generation of public/private key
pairs relies on a random numbers. The use of inadequate pseudo- pairs relies on a random numbers. The use of inadequate pseudo-
random number generators (PRNGs) to generate cryptographic keys can random number generators (PRNGs) to generate cryptographic keys can
result in little or no security. An attacker may find it much easier result in little or no security. An attacker may find it much easier
to reproduce the PRNG environment that produced the keys, searching to reproduce the PRNG environment that produced the keys, searching
the resulting small set of possibilities, rather than brute force the resulting small set of possibilities, rather than brute force
searching the whole key space. The generation of quality random searching the whole key space. The generation of quality random
numbers is difficult. RFC 1750 offers important guidance in this numbers is difficult. RFC 1750 offers important guidance in this
area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG
technique. technique.
When using key agreement algorithms or previously distributed
symmetric key-encryption keys, a key-encryption key is used to
encrypt the content-encryption key. If the key-encryption and
content-encryption algorithms are different, the effective security
is determined by the weaker of the two algorithms. If, for example,
a message content is encrypted with 168-bit Triple-DES and the
Triple-DES content-encryption key is wrapped with a 40-bit RC2 key,
then at most 40 bits of protection is provided. A trivial search to
determine the value of the 40-bit RC2 key can recover Triple-DES key,
and then the Triple-DES key can be used to decrypt the message
content. Therefore, implementers must ensure that key-encryption
algorithms are as strong or stronger than content-encryption
algorithms.
The countersignature unauthenticated attribute includes a digital The countersignature unauthenticated attribute includes a digital
signature that is computed on the content signature value, thus the signature that is computed on the content signature value, thus the
countersigning process need not know the original signed content. countersigning process need not know the original signed content.
This structure permits implementation efficiency advantages; however, This structure permits implementation efficiency advantages; however,
this structure may also permit the countersigning of an inappropriate this structure may also permit the countersigning of an inappropriate
signature value. Therefore, implementations that perform signature value. Therefore, implementations that perform
countersignatures should either validate the original signature value countersignatures should either validate the original signature value
prior to countersigning it (this validation requires processing of prior to countersigning it (this validation requires processing of
the original content), or implementations should perform the original content), or implementations should perform
countersigning in a context that ensures that only appropriate countersigning in a context that ensures that only appropriate
skipping to change at page 51, line 14 skipping to change at page 50, line 35
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 the CMS 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, Tim Dean, Steve Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve
Dusse, Paul Hoffman, Scott Hollenbeck, Burt Kaliski, John Linn, John Dusse, Stephen Henson, Paul Hoffman, Scott Hollenbeck, Burt Kaliski,
Pawling, Blake Ramsdell, Jim Schaad, and Dave Solo for their efforts John Linn, John Pawling, Blake Ramsdell, Jim Schaad, and Dave Solo
and support. for their efforts and support.
Author Address Author Address
Russell Housley Russell Housley
SPYRUS SPYRUS
381 Elden Street 381 Elden Street
Suite 1120 Suite 1120
Herndon, VA 20170 Herndon, VA 20170
USA USA
 End of changes. 

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