< draft-ietf-smime-rfc3369bis-01.txt   draft-ietf-smime-rfc3369bis-02.txt >
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
When Approved, Obsoletes: 3369 March 2004 When Approved, Obsoletes: 3369 March 2004
Cryptographic Message Syntax (CMS) Cryptographic Message Syntax (CMS)
<draft-ietf-smime-rfc3369bis-01.txt> <draft-ietf-smime-rfc3369bis-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 9, line 41 skipping to change at page 9, line 41
algorithm that is not included in this set. The message digesting algorithm that is not included in this set. The message digesting
process is described in Section 5.4. process is described in Section 5.4.
encapContentInfo is the signed content, consisting of a content encapContentInfo is the signed content, consisting of a content
type identifier and the content itself. Details of the type identifier and the content itself. Details of the
EncapsulatedContentInfo type are discussed in section 5.2. EncapsulatedContentInfo type are discussed in section 5.2.
certificates is a collection of certificates. It is intended that certificates is a collection of certificates. It is intended that
the set of certificates be sufficient to contain certification the set of certificates be sufficient to contain certification
paths from a recognized "root" or "top-level certification paths from a recognized "root" or "top-level certification
authority" to all of the signers in the signerInfos field. There authority" to all of the
may be more certificates than necessary, and there may be
certificates sufficient to contain certification paths from two or signers in the signerInfos field. There may be more certificates
more independent top-level certification authorities. There may than necessary, and there may be certificates sufficient to
also be fewer certificates than necessary, if it is expected that contain certification paths from two or more independent top-level
recipients have an alternate means of obtaining necessary certification authorities. There may also be fewer certificates
certificates (e.g., from a previous set of certificates). The than necessary, if it is expected that recipients have an
signer's certificate MAY be included. The use of version 1 alternate means of obtaining necessary certificates (e.g., from a
attribute certificates is strongly discouraged. previous set of certificates). The signer's certificate MAY be
included. The use of version 1 attribute certificates is strongly
discouraged.
crls is a collection of revocation status information. It is crls is a collection of revocation status information. It is
intended that the collection contain information sufficient to intended that the collection contain information sufficient to
determine whether the certificates in the certificates field are determine whether the certificates in the certificates field are
valid, but such correspondence is not necessary. Certificate valid, but such correspondence is not necessary. Certificate
revocation lists (CRLs) are the primary source of revocation revocation lists (CRLs) are the primary source of revocation
status information. There MAY be more CRLs than necessary, and status information. There MAY be more CRLs than necessary, and
there MAY also be fewer CRLs than necessary. there MAY also be fewer CRLs than necessary.
signerInfos is a collection of per-signer information. There MAY signerInfos is a collection of per-signer information. There MAY
skipping to change at page 11, line 38 skipping to change at page 11, line 38
[OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. S/MIME v2 encapsulates [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 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 SignedData contentInfo content ANY field, and S/MIME v3 carries
the MIME content in the SignedData encapContentInfo eContent OCTET the MIME content in the SignedData encapContentInfo eContent OCTET
STRING. Therefore, in both S/MIME v2 and S/MIME v3, the MIME content 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 is placed in an OCTET STRING and the message digest is computed over
the identical portions of the content. That is, the message digest the identical portions of the content. That is, the message digest
is computed over the octets comprising the value of the OCTET STRING, is computed over the octets comprising the value of the OCTET STRING,
neither the tag nor length octets are included. neither the tag nor length octets are included.
There are incompatibilities between the CMS and PKCS #7 signedData There are incompatibilities between the CMS and PKCS #7 SignedData
types when the encapsulated content is not formatted using the Data types when the encapsulated content is not formatted using the Data
type. For example, when an RFC 2634 [ESS] signed receipt is type. For example, when an RFC 2634 [ESS] signed receipt is
encapsulated in the CMS signedData type, then the Receipt SEQUENCE is encapsulated in the CMS SignedData type, then the Receipt SEQUENCE is
encoded in the signedData encapContentInfo eContent OCTET STRING and encoded in the SignedData encapContentInfo eContent OCTET STRING and
the message digest is computed using the entire Receipt SEQUENCE the message digest is computed using the entire Receipt SEQUENCE
encoding (including tag, length and value octets). However, if an encoding (including tag, length and value octets). However, if an
RFC 2634 signed receipt is encapsulated in the PKCS #7 signedData RFC 2634 signed receipt is encapsulated in the PKCS #7 SignedData
type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the
SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET
STRING). Therefore, the message digest is computed using only the STRING). Therefore, the message digest is computed using only the
value octets of the Receipt SEQUENCE encoding. value octets of the Receipt SEQUENCE encoding.
The following strategy can be used to achieve backward compatibility The following strategy can be used to achieve backward compatibility
with PKCS #7 when processing SignedData content types. If the with PKCS #7 when processing SignedData content types. If the
implementation is unable to ASN.1 decode the signedData type using implementation is unable to ASN.1 decode the SignedData type using
the CMS signedData encapContentInfo eContent OCTET STRING syntax, the CMS SignedData encapContentInfo eContent OCTET STRING syntax,
then the implementation MAY attempt to decode the signedData type then the implementation MAY attempt to decode the SignedData type
using the PKCS #7 SignedData contentInfo content ANY syntax and using the PKCS #7 SignedData contentInfo content ANY syntax and
compute the message digest accordingly. compute the message digest accordingly.
The following strategy can be used to achieve backward compatibility The following strategy can be used to achieve backward compatibility
with PKCS #7 when creating a SignedData content type in which the with PKCS #7 when creating a SignedData content type in which the
encapsulated content is not formatted using the Data type. encapsulated content is not formatted using the Data type.
Implementations MAY examine the value of the eContentType, and then Implementations MAY examine the value of the eContentType, and then
adjust the expected DER encoding of eContent based on the object adjust the expected DER encoding of eContent based on the object
identifier value. For example, to support Microsoft AuthentiCode, identifier value. For example, to support Microsoft AuthentiCode,
the following information MAY be included: the following information MAY be included:
skipping to change at page 13, line 30 skipping to change at page 13, line 30
reference, the key identifier matches the X.509 reference, the key identifier matches the X.509
subjectKeyIdentifier extension value. When other certificate subjectKeyIdentifier extension value. When other certificate
formats are referenced, the documents that specify the certificate formats are referenced, the documents that specify the certificate
format and their use with the CMS must include details on matching format and their use with the CMS must include details on matching
the key identifier to the appropriate certificate field. the key identifier to the appropriate certificate field.
Implementations MUST support the reception of the Implementations MUST support the reception of the
issuerAndSerialNumber and subjectKeyIdentifier forms of issuerAndSerialNumber and subjectKeyIdentifier forms of
SignerIdentifier. When generating a SignerIdentifier, SignerIdentifier. When generating a SignerIdentifier,
implementations MAY support one of the forms (either implementations MAY support one of the forms (either
issuerAndSerialNumber or subjectKeyIdentifier) and always use it, issuerAndSerialNumber or subjectKeyIdentifier) and always use it,
or implementations MAY arbitrarily mix the two forms. or implementations MAY arbitrarily mix the two forms. However,
subjectKeyIdentifier MUST be used to refer to a public key
contained in a non-X.509 certificate.
digestAlgorithm identifies the message digest algorithm, and any digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the signer. The message digest is associated parameters, used by the signer. The message digest is
computed on either the content being signed or the content computed on either the content being signed or the content
together with the signed attributes using the process described in together with the signed attributes using the process described in
section 5.4. The message digest algorithm SHOULD be among those section 5.4. The message digest algorithm SHOULD be among those
listed in the digestAlgorithms field of the associated SignerData. listed in the digestAlgorithms field of the associated SignerData.
Implementations MAY fail to validate signatures that use a digest Implementations MAY fail to validate signatures that use a digest
algorithm that is not included in the SignedData digestAlgorithms algorithm that is not included in the SignedData digestAlgorithms
set. set.
skipping to change at page 15, line 16 skipping to change at page 15, line 19
content-type attribute MUST NOT be included in a countersignature content-type attribute MUST NOT be included in a countersignature
unsigned attribute as defined in section 11.4. A separate encoding unsigned attribute as defined in section 11.4. A separate encoding
of the signedAttrs field is performed for message digest calculation. of the signedAttrs field is performed for message digest calculation.
The IMPLICIT [0] tag in the signedAttrs is not used for the DER The IMPLICIT [0] tag in the signedAttrs is not used for the DER
encoding, rather an EXPLICIT SET OF tag is used. That is, the DER encoding, rather an EXPLICIT SET OF tag is used. That is, the DER
encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0] encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0]
tag, MUST be included in the message digest calculation along with tag, MUST be included in the message digest calculation along with
the length and content octets of the SignedAttributes value. the length and content octets of the SignedAttributes value.
When the signedAttrs field is absent, only the octets comprising the When the signedAttrs field is absent, only the octets comprising the
value of the signedData encapContentInfo eContent OCTET STRING (e.g., value of the SignedData encapContentInfo eContent OCTET STRING (e.g.,
the contents of a file) are input to the message digest calculation. the contents of a file) are input to the message digest calculation.
This has the advantage that the length of the content being signed This has the advantage that the length of the content being signed
need not be known in advance of the signature generation process. need not be known in advance of the signature generation process.
Although the encapContentInfo eContent OCTET STRING tag and length Although the encapContentInfo eContent OCTET STRING tag and length
octets are not included in the message digest calculation, they are octets are not included in the message digest calculation, they are
protected by other means. The length octets are protected by the protected by other means. The length octets are protected by the
nature of the message digest algorithm since it is computationally nature of the message digest algorithm since it is computationally
infeasible to find any two distinct message contents of any length infeasible to find any two distinct message contents of any length
that have the same message digest. that have the same message digest.
skipping to change at page 20, line 15 skipping to change at page 20, line 15
PKCS #1 v1.5, then a graceful failure must be implemented. PKCS #1 v1.5, then a graceful failure must be implemented.
Implementations MUST support key transport, key agreement, and Implementations MUST support key transport, key agreement, and
previously distributed symmetric key-encryption keys, as represented previously distributed symmetric key-encryption keys, as represented
by ktri, kari, and kekri, respectively. Implementations MAY support by ktri, kari, and kekri, respectively. Implementations MAY support
the password-based key management as represented by pwri. the password-based key management as represented by pwri.
Implementations MAY support any other key management technique as Implementations MAY support any other key management technique as
represented by ori. Since each recipient can employ a different key represented by ori. Since each recipient can employ a different key
management technique and future specifications could define management technique and future specifications could define
additional key management techniques, all implementations MUST additional key management techniques, all implementations MUST
gracefully handle unimplemented alternatives within the RecipientInfo gracefully handle
CHOICE, all implementations MUST gracefully handle unimplemented
versions of otherwise supported alternatives within the RecipientInfo unimplemented alternatives within the RecipientInfo CHOICE, all
CHOICE, and all implementations MUST gracefully handle unimplemented implementations MUST gracefully handle unimplemented versions of
or unknown ori alternatives. otherwise supported alternatives within the RecipientInfo CHOICE, and
all implementations MUST gracefully handle unimplemented or unknown
ori alternatives.
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo, kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo, pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo } ori [4] OtherRecipientInfo }
EncryptedKey ::= OCTET STRING EncryptedKey ::= OCTET STRING
skipping to change at page 20, line 50 skipping to change at page 21, line 4
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE { RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier } subjectKeyIdentifier [0] SubjectKeyIdentifier }
The fields of type KeyTransRecipientInfo have the following meanings: The fields of type KeyTransRecipientInfo have the following meanings:
version is the syntax version number. If the RecipientIdentifier version is the syntax version number. If the RecipientIdentifier
is the CHOICE issuerAndSerialNumber, then the version MUST be 0. is the CHOICE issuerAndSerialNumber, then the version MUST be 0.
If the RecipientIdentifier is subjectKeyIdentifier, then the If the RecipientIdentifier is subjectKeyIdentifier, then the
version MUST be 2. version MUST be 2.
rid specifies the recipient's certificate or key that was used by rid specifies the recipient's certificate or key that was used by
the sender to protect the content-encryption key. The content- the sender to protect the content-encryption key. The content-
encryption key is encrypted with the recipient's public key. The encryption key is encrypted with the recipient's public key. The
RecipientIdentifier provides two alternatives for specifying the RecipientIdentifier provides two alternatives for specifying the
recipient's certificate, and thereby the recipient's public key. recipient's certificate, and thereby the recipient's public key.
The recipient's certificate must contain a key transport public The recipient's certificate must contain a key transport public
key. 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 issuerAndSerialNumber alternative identifies the bit. 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
signer's certificate by a key identifier. When an X.509 recipient's certificate by a key identifier. When an X.509
certificate is referenced, the key identifier matches the X.509 certificate is referenced, the key identifier matches the X.509
subjectKeyIdentifier extension value. When other certificate subjectKeyIdentifier extension value. When other certificate
formats are referenced, the documents that specify the certificate formats are referenced, the documents that specify the certificate
format and their use with the CMS must include details on matching format and their use with the CMS must include details on matching
the key identifier to the appropriate certificate field. For the key identifier to the appropriate certificate field. For
recipient processing, implementations MUST support both of these recipient processing, implementations MUST support both of these
alternatives for specifying the recipient's certificate. For alternatives for specifying the recipient's certificate. For
sender processing, implementations MUST support at least one of sender processing, implementations MUST support at least one of
these alternatives. these alternatives.
skipping to change at page 22, line 43 skipping to change at page 22, line 43
version is the syntax version number. It MUST always be 3. version is the syntax version number. It MUST always be 3.
originator is a CHOICE with three alternatives specifying the originator is a CHOICE with three alternatives specifying the
sender's key agreement public key. The sender uses the sender's key agreement public key. The sender uses the
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, a the sender's certificate, and thereby the sender's public key, by
key identifier. When an X.509 certificate is referenced, the key a key identifier. When an X.509 certificate is referenced, the
identifier matches the X.509 subjectKeyIdentifier extension value. key identifier matches the X.509 subjectKeyIdentifier extension
When other certificate formats are referenced, the documents that value. When other certificate formats are referenced, the
specify the certificate format and their use with the CMS must documents that specify the certificate format and their use with
must include details on matching the key identifier to the the CMS must must include details on matching the key identifier
appropriate certificate field. The originatorKey alternative to the appropriate certificate field. The originatorKey
includes the algorithm identifier and sender's key agreement alternative includes the algorithm identifier and sender's key
public key. This alternative permits originator anonymity since agreement public key. This alternative permits originator
the public key is not certified. Implementations MUST support all anonymity since the public key is not certified. Implementations
three alternatives for specifying the sender's public key. MUST support all three alternatives for specifying the sender's
public key.
ukm is optional. With some key agreement algorithms, the sender ukm is optional. With some key agreement algorithms, the sender
provides a User Keying Material (UKM) to ensure that a different provides a User Keying Material (UKM) to ensure that a different
key is generated each time the same two parties generate a key is generated each time the same two parties generate a
pairwise key. Implementations MUST support recipient processing pairwise key. Implementations MUST support recipient processing
of a KeyAgreeRecipientInfo SEQUENCE that includes a ukm field. of a KeyAgreeRecipientInfo SEQUENCE that includes a ukm field.
Implementations that do not support key agreement algorithms that Implementations that do not support key agreement algorithms that
make use of UKMs MUST gracefully handle the presence of UKMs. make use of UKMs MUST gracefully handle the presence of UKMs.
keyEncryptionAlgorithm identifies the key-encryption algorithm, keyEncryptionAlgorithm identifies the key-encryption algorithm,
skipping to change at page 26, line 20 skipping to change at page 26, line 20
oriType identifies the key management technique. oriType identifies the key management technique.
oriValue contains the protocol data elements needed by a recipient oriValue contains the protocol data elements needed by a recipient
using the identified key management technique. using the identified key management technique.
6.3 Content-encryption Process 6.3 Content-encryption Process
The content-encryption key for the desired content-encryption The content-encryption key for the desired content-encryption
algorithm is randomly generated. The data to be protected is padded algorithm is randomly generated. The data to be protected is padded
as described below, then the padded data is encrypted using the as described below,
content-encryption key. The encryption operation maps an arbitrary
string of octets (the data) to another string of octets (the then the padded data is encrypted using the content-encryption key.
ciphertext) under control of a content-encryption key. The encrypted The encryption operation maps an arbitrary string of octets (the
data is included in the envelopedData encryptedContentInfo data) to another string of octets (the ciphertext) under control of a
encryptedContent OCTET STRING. content-encryption key. The encrypted data is included in the
EnvelopedData encryptedContentInfo encryptedContent OCTET STRING.
Some content-encryption algorithms assume the input length is a Some content-encryption algorithms assume the input length is a
multiple of k octets, where k is greater than one. For such multiple of k octets, where k is greater than one. For such
algorithms, the input shall be padded at the trailing end with algorithms, the input shall be padded at the trailing end with
k-(lth mod k) octets all having value k-(lth mod k), where lth is k-(lth mod k) octets all having value k-(lth mod k), where lth is
the length of the input. In other words, the input is padded at the length of the input. In other words, the input is padded at
the trailing end with one of the following strings: the trailing end with one of the following strings:
01 -- if lth mod k = k-1 01 -- if lth mod k = k-1
02 02 -- if lth mod k = k-2 02 02 -- if lth mod k = k-2
skipping to change at page 37, line 11 skipping to change at page 37, line 11
The CertificateSet type provides a set of certificates. It is The CertificateSet type provides a set of certificates. It is
intended that the set be sufficient to contain certification paths intended that the set be sufficient to contain certification paths
from a recognized "root" or "top-level certification authority" to from a recognized "root" or "top-level certification authority" to
all of the sender certificates with which the set is associated. all of the sender certificates with which the set is associated.
However, there may be more certificates than necessary, or there MAY However, there may be more certificates than necessary, or there MAY
be fewer than necessary. be fewer than necessary.
The precise meaning of a "certification path" is outside the scope of The precise meaning of a "certification path" is outside the scope of
this document. However, [PROFILE] provides a definition for X.509 this document. However, [PROFILE] provides a definition for X.509
certificates. Some applications may impose upper limits on the certificates. Some applications may impose upper limits on the
length of a certification path; others may enforce certain length of a
relationships between the subjects and issuers of certificates within
a certification path. certification path; others may enforce certain relationships between
the subjects and issuers of certificates within a certification path.
CertificateSet ::= SET OF CertificateChoices CertificateSet ::= SET OF CertificateChoices
10.2.4 IssuerAndSerialNumber 10.2.4 IssuerAndSerialNumber
The IssuerAndSerialNumber type identifies a certificate, and thereby The IssuerAndSerialNumber type identifies a certificate, and thereby
an entity and a public key, by the distinguished name of the an entity and a public key, by the distinguished name of the
certificate issuer and an issuer-specific certificate serial number. certificate issuer and an issuer-specific certificate serial number.
The definition of Name is taken from X.501 [X.501-88], and the The definition of Name is taken from X.501 [X.501-88], and the
 End of changes. 14 change blocks. 
45 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/