< draft-ietf-smime-rfc3369bis-00.txt   draft-ietf-smime-rfc3369bis-01.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-00.txt> <draft-ietf-smime-rfc3369bis-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 32 skipping to change at page 1, line 32
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes the Cryptographic Message Syntax (CMS). This This document describes the Cryptographic Message Syntax (CMS). This
syntax is used to digitally sign, digest, authenticate, or encrypt syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary message content. arbitrary message content.
Table of Contents Table of Contents
1. Introduction ................................................ ?? 1 Introduction ............................................. ??
1.1 Changes Since RFC 2630 ...................................... ?? 1.1 Changes Since RFC 2630 ................................... ??
1.2 Changes Since RFC 3369 ...................................... ?? 1.2 Changes Since RFC 3369 ................................... ??
1.3 Terminology ................................................. ?? 1.3 Terminology .............................................. ??
2. General Overview ............................................ ?? 2 General Overview ......................................... ??
3. General Syntax .............................................. ?? 3 General Syntax ........................................... ??
4. Data Content Type ........................................... ?? 4 Data Content Type ........................................ ??
5. Signed-data Content Type .................................... ?? 5 Signed-data Content Type ................................. ??
5.1 SignedData Type ............................................. ?? 5.1 SignedData Type .......................................... ??
5.2 EncapsulatedContentInfo Type ................................ ?? 5.2 EncapsulatedContentInfo Type ............................. ??
5.2.1 Compatibility with PKCS #7 ................................ ?? 5.2.1 Compatibility with PKCS #7 ............................... ??
5.3 SignerInfo Type ............................................. ?? 5.3 SignerInfo Type .......................................... ??
5.4 Message Digest Calculation Process .......................... ?? 5.4 Message Digest Calculation Process ....................... ??
5.5 Signature Generation Process ................................ ?? 5.5 Signature Generation Process ............................. ??
5.6 Signature Verification Process .............................. ?? 5.6 Signature Verification Process ........................... ??
6. Enveloped-data Content Type ................................. ?? 6 Enveloped-data Content Type .............................. ??
6.1 EnvelopedData Type .......................................... ?? 6.1 EnvelopedData Type ....................................... ??
6.2 RecipientInfo Type .......................................... ?? 6.2 RecipientInfo Type ....................................... ??
6.2.1 KeyTransRecipientInfo Type ................................ ?? 6.2.1 KeyTransRecipientInfo Type ............................... ??
6.2.2 KeyAgreeRecipientInfo Type ................................ ?? 6.2.2 KeyAgreeRecipientInfo Type ............................... ??
6.2.3 KEKRecipientInfo Type ..................................... ?? 6.2.3 KEKRecipientInfo Type .................................... ??
6.2.4 PasswordRecipientInfo Type ................................ ?? 6.2.4 PasswordRecipientInfo Type ............................... ??
6.2.5 OtherRecipientInfo Type ................................... ?? 6.2.5 OtherRecipientInfo Type .................................. ??
6.3 Content-encryption Process .................................. ?? 6.3 Content-encryption Process ............................... ??
6.4 Key-encryption Process ...................................... ?? 6.4 Key-encryption Process ................................... ??
7. Digested-data Content Type .................................. ?? 7 Digested-data Content Type ............................... ??
8. Encrypted-data Content Type ................................. ?? 8 Encrypted-data Content Type .............................. ??
9. Authenticated-data Content Type ............................. ?? 9 Authenticated-data Content Type .......................... ??
9.1 AuthenticatedData Type ...................................... ?? 9.1 AuthenticatedData Type ................................... ??
9.2 MAC Generation .............................................. ?? 9.2 MAC Generation ........................................... ??
9.3 MAC Verification ............................................ ?? 9.3 MAC Verification ......................................... ??
10. Useful Types ................................................ ?? 10 Useful Types ............................................. ??
10.1 Algorithm Identifier Types ................................. ?? 10.1 Algorithm Identifier Types ............................... ??
10.1.1 DigestAlgorithmIdentifier ................................ ?? 10.1.1 DigestAlgorithmIdentifier ................................ ??
10.1.2 SignatureAlgorithmIdentifier ............................. ?? 10.1.2 SignatureAlgorithmIdentifier ............................. ??
10.1.3 KeyEncryptionAlgorithmIdentifier ......................... ?? 10.1.3 KeyEncryptionAlgorithmIdentifier ......................... ??
10.1.4 ContentEncryptionAlgorithmIdentifier ..................... ?? 10.1.4 ContentEncryptionAlgorithmIdentifier ..................... ??
10.1.5 MessageAuthenticationCodeAlgorithm ....................... ?? 10.1.5 MessageAuthenticationCodeAlgorithm ....................... ??
10.1.6 KeyDerivationAlgorithmIdentifier ......................... ?? 10.1.6 KeyDerivationAlgorithmIdentifier ......................... ??
10.2 Other Useful Types ......................................... ?? 10.2 Other Useful Types ....................................... ??
10.2.1 CertificateRevocationLists ............................... ?? 10.2.1 RevocationInfoChoices .................................... ??
10.2.2 CertificateChoices ....................................... ?? 10.2.2 CertificateChoices ....................................... ??
10.2.3 CertificateSet ........................................... ?? 10.2.3 CertificateSet ........................................... ??
10.2.4 IssuerAndSerialNumber .................................... ?? 10.2.4 IssuerAndSerialNumber .................................... ??
10.2.5 CMSVersion ............................................... ?? 10.2.5 CMSVersion ............................................... ??
10.2.6 UserKeyingMaterial ....................................... ?? 10.2.6 UserKeyingMaterial ....................................... ??
10.2.7 OtherKeyAttribute ........................................ ?? 10.2.7 OtherKeyAttribute ........................................ ??
11. Useful Attributes ........................................... ?? 11 Useful Attributes ........................................ ??
11.1 Content Type ............................................... ?? 11.1 Content Type ............................................. ??
11.2 Message Digest ............................................. ?? 11.2 Message Digest ........................................... ??
11.3 Signing Time ............................................... ?? 11.3 Signing Time ............................................. ??
11.4 Countersignature ........................................... ?? 11.4 Countersignature ......................................... ??
12. ASN.1 Modules ............................................... ?? 12 ASN.1 Modules ............................................ ??
12.1 CMS ASN.1 Module ........................................... ?? 12.1 CMS ASN.1 Module ......................................... ??
12.2 Version 1 Attribute Certificate ASN.1 Module ............... ?? 12.2 Version 1 Attribute Certificate ASN.1 Module ............. ??
13. Normative References ........................................ ?? 13 Normative References ..................................... ??
14. Informative References ...................................... ?? 14 Informative References ................................... ??
15. Security Considerations ..................................... ?? 15 Security Considerations .................................. ??
16. Acknowledgments ............................................. ?? 16 Acknowledgments .......................................... ??
17. Author Address .............................................. ?? 17 Author Address ........................................... ??
17. Full Copyright Statement .................................... ?? 18 Full Copyright Statement ................................. ??
1. Introduction 1. Introduction
This document describes the Cryptographic Message Syntax (CMS). This This document describes the Cryptographic Message Syntax (CMS). This
syntax is used to digitally sign, digest, authenticate, or encrypt syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary message content. arbitrary message content.
The CMS describes an encapsulation syntax for data protection. It The CMS describes an encapsulation syntax for data protection. It
supports digital signatures and encryption. The syntax allows supports digital signatures and encryption. The syntax allows
multiple encapsulations; one encapsulation envelope can be nested multiple encapsulations; one encapsulation envelope can be nested
skipping to change at page 5, line 17 skipping to change at page 5, line 17
cryptographic algorithms has been moved to a separate document cryptographic algorithms has been moved to a separate document
[CMSALG]. Separation of the protocol and algorithm specifications [CMSALG]. Separation of the protocol and algorithm specifications
allows the IETF to update each document independently. This allows the IETF to update each document independently. This
specification does not require the implementation of any particular specification does not require the implementation of any particular
algorithms. Rather, protocols that rely on the CMS are expected to algorithms. Rather, protocols that rely on the CMS are expected to
choose appropriate algorithms for their environment. The algorithms choose appropriate algorithms for their environment. The algorithms
may be selected from [CMSALG] or elsewhere. may be selected from [CMSALG] or elsewhere.
1.2 Changes Since RFC 3369 1.2 Changes Since RFC 3369
This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC This document obsoletes RFC 3369 [CMS2]. As discussed in the
3369 introduced an extension mechanism to support new key management previous section, RFC 3369 introduced an extension mechanism to
schemes without further changes to the CMS. This document introduces support new key management schemes without further changes to the
a similar extension mechanism to support additional certificate CMS. This document introduces a similar extension mechanism to
formats for the verification of digital signatures without further support additional certificate formats and revocation status
changes to the CMS. Backward compatibility with both RFC 2630 and information formats without further changes to the CMS. These
RFC 3369 is preserved. extensions are primarily documented in section 10.2.1 and section
10.2.2. Backward compatibility with both RFC 2630 and RFC 3369 is
preserved.
Since the publication of RFC 3369, a few errata have been noted.
These errata are posted on the RFC Editor web site. These errors
have been corrected in this document.
The text in section 11.4 that describes the counter signature
unsigned attribute is clarified. Hopefully the revised text is
clearer about the portion of the SignerInfo signature that is covered
by a countersignature.
1.3 Terminology 1.3 Terminology
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
described in [STDWORDS]. described in [STDWORDS].
2 General Overview 2 General Overview
The CMS is general enough to support many different content types. The CMS is general enough to support many different content types.
skipping to change at page 8, line 29 skipping to change at page 8, line 39
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
The signed-data content type shall have ASN.1 type SignedData: The signed-data content type shall have ASN.1 type SignedData:
SignedData ::= SEQUENCE { SignedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers, digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL, certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos } signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo SignerInfos ::= SET OF SignerInfo
The fields of type SignedData have the following meanings: The fields of type SignedData have the following meanings:
version is the syntax version number. The appropriate value version is the syntax version number. The appropriate value
depends on certificates, eContentType, and SignerInfo. The depends on certificates, eContentType, and SignerInfo. The
version MUST be assigned as follows: version MUST be assigned as follows:
IF (certificates is present) AND IF ((certificates is present) AND
(any certificates with a type of other are present) (any certificates with a type of other are present)) OR
((crls is present) AND
(any crls with a type of other are present))
THEN version MUST be 5 THEN version MUST be 5
ELSE ELSE
IF (certificates is present) AND IF (certificates is present) AND
(any version 2 attribute certificates are present) (any version 2 attribute certificates are present)
THEN version MUST be 4 THEN version MUST be 4
ELSE ELSE
IF ((certificates is present) AND IF ((certificates is present) AND
(any version 1 attribute certificates are present)) OR (any version 1 attribute certificates are present)) OR
(encapContentInfo eContentType is other than id-data) OR (any SignerInfo structures are version 3) OR
(any SignerInfo structures are version 3) (encapContentInfo eContentType is other than id-data)
THEN version MUST be 3 THEN version MUST be 3
ELSE version MUST be 1 ELSE version MUST be 1
digestAlgorithms is a collection of message digest algorithm digestAlgorithms is a collection of message digest algorithm
identifiers. There MAY be any number of elements in the identifiers. There MAY be any number of elements in the
collection, including zero. Each element identifies the message collection, including zero. Each element identifies the message
digest algorithm, along with any associated parameters, used by digest algorithm, along with any associated parameters, used by
one or more signer. The collection is intended to list the one or more signer. The collection is intended to list the
message digest algorithms employed by all of the signers, in any message digest algorithms employed by all of the signers, in any
order, to facilitate one-pass signature verification. order, to facilitate one-pass signature verification.
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 this set. The message digesting algorithm that is not included in this set. The message digesting
skipping to change at page 9, line 48 skipping to change at page 10, line 5
authority" to all of the signers in the signerInfos field. There authority" to all of the signers in the signerInfos field. There
may be more certificates than necessary, and there may be may be more certificates than necessary, and there may be
certificates sufficient to contain certification paths from two or certificates sufficient to contain certification paths from two or
more independent top-level certification authorities. There may more independent top-level certification authorities. There may
also be fewer certificates than necessary, if it is expected that also be fewer certificates than necessary, if it is expected that
recipients have an alternate means of obtaining necessary recipients have an alternate means of obtaining necessary
certificates (e.g., from a previous set of certificates). The certificates (e.g., from a previous set of certificates). The
signer's certificate MAY be included. The use of version 1 signer's certificate MAY be included. The use of version 1
attribute certificates is strongly discouraged. attribute certificates is strongly discouraged.
crls is a collection of certificate revocation lists (CRLs). It crls is a collection of revocation status information. It is
is intended that the set contain information sufficient to intended that the collection contain information sufficient to
determine whether or not the certificates in the certificates determine whether the certificates in the certificates field are
field are valid, but such correspondence is not necessary. There valid, but such correspondence is not necessary. Certificate
MAY be more CRLs than necessary, and there MAY also be fewer CRLs revocation lists (CRLs) are the primary source of revocation
than necessary. status information. There MAY be more CRLs than necessary, and
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
be any number of elements in the collection, including zero. The be any number of elements in the collection, including zero. The
details of the SignerInfo type are discussed in section 5.3. details of the SignerInfo type are discussed in section 5.3.
Since each signer can employ a digital signature technique and Since each signer can employ a digital signature technique and
future specifications could update the syntax, all implementations future specifications could update the syntax, all implementations
MUST gracefully handle unimplemented versions of SignerInfo. MUST gracefully handle unimplemented versions of SignerInfo.
Further, since all implementations will not support every possible Further, since all implementations will not support every possible
signature algorithm, all implementations MUST gracefully handle signature algorithm, all implementations MUST gracefully handle
unimplemented signature algorithms when they are encountered. unimplemented signature algorithms when they are encountered.
skipping to change at page 13, line 14 skipping to change at page 13, line 19
the SignerIdentifier is subjectKeyIdentifier, then the version the SignerIdentifier is subjectKeyIdentifier, then the version
MUST be 3. MUST be 3.
sid specifies the signer's certificate (and thereby the signer's sid specifies the signer's certificate (and thereby the signer's
public key). The signer's public key is needed by the recipient public key). The signer's public key is needed by the recipient
to verify the signature. SignerIdentifier provides two to verify the signature. SignerIdentifier provides two
alternatives for specifying the signer's public key. The alternatives for specifying the signer's public key. The
issuerAndSerialNumber alternative identifies the signer's issuerAndSerialNumber alternative identifies the signer's
certificate by the issuer's distinguished name and the certificate certificate by the issuer's distinguished name and the certificate
serial number; the subjectKeyIdentifier identifies the signer's serial number; the subjectKeyIdentifier identifies the signer's
certificate by the X.509 subjectKeyIdentifier extension value. certificate by a key identifier. When an X.509 certificate is
reference, the key identifier matches the X.509
subjectKeyIdentifier extension value. When other certificate
formats are referenced, the documents that specify the certificate
format and their use with the CMS must include details on matching
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.
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
skipping to change at page 17, line 37 skipping to change at page 17, line 48
EnvelopedData ::= SEQUENCE { EnvelopedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo, encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
OriginatorInfo ::= SEQUENCE { OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL, certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE { EncryptedContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING EncryptedContent ::= OCTET STRING
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
The fields of type EnvelopedData have the following meanings: The fields of type EnvelopedData have the following meanings:
version is the syntax version number. The appropriate value version is the syntax version number. The appropriate value
depends on originatorInfo, RecipientInfo, and unprotectedAttrs. depends on originatorInfo, RecipientInfo, and unprotectedAttrs.
The version MUST be assigned as follows: The version MUST be assigned as follows:
IF ((originatorInfo is present) AND IF (originatorInfo is present) AND
(any version 2 attribute certificates are present)) OR ((any certificates with a type of other are present) OR
(any RecipientInfo structures include pwri) OR (any crls with a type of other are present))
(any RecipientInfo structures include ori) THEN version is 4
THEN version is 3
ELSE ELSE
IF (originatorInfo is present) OR IF ((originatorInfo is present) AND
(unprotectedAttrs is present) OR (any version 2 attribute certificates are present)) OR
(any RecipientInfo structures are a version other than 0) (any RecipientInfo structures include pwri) OR
THEN version is 2 (any RecipientInfo structures include ori)
ELSE version is 0 THEN version is 3
ELSE
IF (originatorInfo is absent) OR
(unprotectedAttrs is absent) OR
(all RecipientInfo structures are version 0)
THEN version is 0
ELSE version is 2
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 management algorithms. certs may also contain attribute
certificates associated with the originator. The certificates
algorithms. certs may also contain attribute certificates contained in certs are intended to be sufficient for all
associated with the originator. The certificates contained in recipients to build certification paths from a recognized
certs are intended to be sufficient for all recipients to build "root" or "top-level certification authority." However, certs
certification paths from a recognized "root" or "top-level may contain more certificates than necessary, and there may be
certification authority." However, certs may contain more certificates sufficient to make certification paths from two or
certificates than necessary, and there may be certificates more independent top-level certification authorities.
sufficient to make certification paths from two or more
independent top-level certification authorities.
Alternatively, certs may contain fewer certificates than Alternatively, certs may contain fewer certificates than
necessary, if it is expected that recipients have an alternate necessary, if it is expected that recipients have an alternate
means of obtaining necessary certificates (e.g., from a means of obtaining necessary certificates (e.g., from a
previous set of certificates). previous set of certificates).
crls is a collection of CRLs. It is intended that the set crls is a collection of CRLs. It is intended that the set
contain information sufficient to determine whether or not the contain information sufficient to determine whether or not the
certificates in the certs field are valid, but such certificates in the certs field are valid, but such
correspondence is not necessary. There MAY be more CRLs than correspondence is not necessary. There MAY be more CRLs than
necessary, and there MAY also be fewer CRLs than necessary. necessary, and there MAY also be fewer CRLs than necessary.
skipping to change at page 20, line 39 skipping to change at page 21, line 6
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 the sender to protect the content-encryption key. The content-
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 content-encryption key is encrypted with the recipient's bit. The issuerAndSerialNumber alternative identifies the
public key. The issuerAndSerialNumber alternative identifies the
recipient's certificate by the issuer's distinguished name and the recipient's certificate by the issuer's distinguished name and the
certificate serial number; the subjectKeyIdentifier identifies the certificate serial number; the subjectKeyIdentifier identifies the
recipient's certificate by the X.509 subjectKeyIdentifier signer's certificate by a key identifier. When an X.509
extension value. For recipient processing, implementations MUST certificate is referenced, the key identifier matches the X.509
support both of these alternatives for specifying the recipient's subjectKeyIdentifier extension value. When other certificate
certificate; and for sender processing, implementations MUST formats are referenced, the documents that specify the certificate
support at least one of these alternatives. format and their use with the CMS must include details on matching
the key identifier to the appropriate certificate field. For
recipient processing, implementations MUST support both of these
alternatives for specifying the recipient's certificate. For
sender processing, implementations MUST support at least one of
these alternatives.
keyEncryptionAlgorithm identifies the key-encryption algorithm, keyEncryptionAlgorithm identifies the key-encryption algorithm,
and any associated parameters, used to encrypt the content- and any associated parameters, used to encrypt the content-
encryption key for the recipient. The key-encryption process is encryption key for the recipient. The key-encryption process is
described in Section 6.4. described in Section 6.4.
encryptedKey is the result of encrypting the content-encryption encryptedKey is the result of encrypting the content-encryption
key for the recipient. key for the recipient.
6.2.2 KeyAgreeRecipientInfo Type 6.2.2 KeyAgreeRecipientInfo Type
skipping to change at page 22, line 24 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, by the sender's certificate, and thereby the sender's public key, a
the X.509 subjectKeyIdentifier extension value. The originatorKey key identifier. When an X.509 certificate is referenced, the key
alternative includes the algorithm identifier and sender's key identifier matches the X.509 subjectKeyIdentifier extension value.
agreement public key. This alternative permits originator When other certificate formats are referenced, the documents that
anonymity since the public key is not certified. Implementations specify the certificate format and their use with the CMS must
MUST support all three alternatives for specifying the sender's must include details on matching the key identifier to the
public key. appropriate certificate field. The originatorKey alternative
includes the algorithm identifier and sender's key agreement
public key. This alternative permits originator anonymity since
the public key is not certified. Implementations 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 23, line 17 skipping to change at page 23, line 40
certificate by the issuer's distinguished name and the certificate certificate by the issuer's distinguished name and the certificate
serial number; the RecipientKeyIdentifier is described below. The serial number; the RecipientKeyIdentifier is described below. The
encryptedKey is the result of encrypting the content-encryption encryptedKey is the result of encrypting the content-encryption
key in the pairwise key-encryption key generated using the key key in the pairwise key-encryption key generated using the key
agreement algorithm. Implementations MUST support both agreement algorithm. Implementations MUST support both
alternatives for specifying the recipient's certificate. alternatives for specifying the recipient's certificate.
The fields of type RecipientKeyIdentifier have the following The fields of type RecipientKeyIdentifier have the following
meanings: meanings:
subjectKeyIdentifier identifies the recipient's certificate by the subjectKeyIdentifier identifies the recipient's certificate by a
X.509 subjectKeyIdentifier extension value. key identifier. When an X.509 certificate is referenced, the key
identifier matches the X.509 subjectKeyIdentifier extension value.
When other certificate formats are referenced, the documents that
specify the certificate format and their use with the CMS must
include details on matching the key identifier to the appropriate
certificate field.
date is optional. When present, the date specifies which of the date is optional. When present, the date specifies which of the
recipient's previously distributed UKMs was used by the sender. recipient's previously distributed UKMs was used by the sender.
other is optional. When present, this field contains additional other is optional. When present, this field contains additional
information used by the recipient to locate the public keying information used by the recipient to locate the public keying
material used by the sender. material used by the sender.
6.2.3 KEKRecipientInfo Type 6.2.3 KEKRecipientInfo Type
skipping to change at page 29, line 42 skipping to change at page 30, line 30
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. The version MUST be version is the syntax version number. The version MUST be
assigned as follows: assigned as follows:
IF ((originatorInfo is present) AND IF (originatorInfo is present) AND
(any version 2 attribute certificates are present)) ((any certificates with a type of other are present) OR
THEN version is 1 (any crls with a type of other are present))
ELSE version is 0 THEN version is 3
ELSE
IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present))
THEN version is 1
ELSE version is 0
originatorInfo optionally provides information about the originatorInfo optionally provides information about the
originator. It is present only if required by the key management originator. It is present only if required by the key 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.
skipping to change at page 34, line 44 skipping to change at page 35, line 21
Key derivation algorithms convert a password or shared secret value Key derivation algorithms convert a password or shared secret value
into a key-encryption key. into a key-encryption key.
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
10.2 Other Useful Types 10.2 Other Useful Types
This section defines types that are used other places in the This section defines types that are used other places in the
document. The types are not listed in any particular order. document. The types are not listed in any particular order.
10.2.1 CertificateRevocationLists 10.2.1 RevocationInfoChoices
The CertificateRevocationLists type gives a set of certificate The RevocationInfoChoices type gives a set of revocation status
revocation lists (CRLs). It is intended that the set contain information alternatives. It is intended that the set contain
information sufficient to determine whether the certificates and information sufficient to determine whether the certificates and
attribute certificates with which the set is associated are revoked. attribute certificates with which the set is associated are revoked.
However, there may be more CRLs than necessary or there MAY be fewer However, there MAY be more revocation status information than
CRLs than necessary. necessary or there MAY be less revocation status information than
necessary. X.509 Certificate revocation lists (CRLs) [X.509-97] are
the primary source of revocation status information, but any other
revocation information format can be supported. The
OtherRevocationInfoFormat alternative is provided to support any
other revocation information format without further modifications to
the CMS. For example, Online Certificate Status Protocol (OCSP)
Responses [OCSP] can be supported using the
OtherRevocationInfoFormat.
The CertificateList may contain a CRL, an Authority Revocation List The CertificateList may contain a CRL, an Authority Revocation List
(ARL), a Delta CRL, or an Attribute Certificate Revocation List. All (ARL), a Delta CRL, or an Attribute Certificate Revocation List. All
of these lists share a common syntax. of these lists share a common syntax.
The CertificateList type gives a certificate revocation list (CRL).
CRLs are specified in X.509 [X.509-97], and they are profiled for use CRLs are specified in X.509 [X.509-97], and they are profiled for use
in the Internet in RFC 3280 [PROFILE]. in the Internet in RFC 3280 [PROFILE].
The definition of CertificateList is taken from X.509. The definition of CertificateList is taken from X.509.
CertificateRevocationLists ::= SET OF CertificateList RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoice ::= CHOICE {
crl CertificateList,
other [1] IMPLICIT OtherRevocationInfoFormat }
OtherRevocationInfoFormat ::= SEQUENCE {
otherRevInfoFormat OBJECT IDENTIFIER,
otherRevInfo ANY DEFINED BY otherRevInfoFormat }
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, a version 1 X.509 certificate [PKCS#6], an X.509 certificate, a version 1 X.509
attribute certificate (ACv1) [X.509-97], a version 2 X.509 attribute attribute certificate (ACv1) [X.509-97], a version 2 X.509 attribute
certificate (ACv2) [X.509-00], or any other certificate format. The certificate (ACv2) [X.509-00], or any other certificate format. The
PKCS #6 extended certificate is obsolete. The PKCS #6 certificate is PKCS #6 extended certificate is obsolete. The PKCS #6 certificate is
included for backward compatibility, and PKCS #6 certificates SHOULD included for backward compatibility, and PKCS #6 certificates SHOULD
NOT be used. The ACv1 is also obsolete. ACv1 is included for NOT be used. The ACv1 is also obsolete. ACv1 is included for
skipping to change at page 36, line 43 skipping to change at page 37, line 37
issuer Name, issuer Name,
serialNumber CertificateSerialNumber } serialNumber CertificateSerialNumber }
CertificateSerialNumber ::= INTEGER CertificateSerialNumber ::= INTEGER
10.2.5 CMSVersion 10.2.5 CMSVersion
The CMSVersion type gives a syntax version number, for compatibility The CMSVersion type gives a syntax version number, for compatibility
with future revisions of this specification. with future revisions of this specification.
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) } CMSVersion ::= INTEGER
{ v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }
10.2.6 UserKeyingMaterial 10.2.6 UserKeyingMaterial
The UserKeyingMaterial type gives a syntax for user keying material The UserKeyingMaterial type gives a syntax for user keying material
(UKM). Some key agreement algorithms require UKMs to ensure that a (UKM). Some key agreement algorithms require UKMs to ensure that a
different key is generated each time the same two parties generate a different key is generated each time the same two parties generate a
pairwise key. The sender provides a UKM for use with a specific key pairwise key. The sender provides a UKM for use with a specific key
agreement algorithm. agreement algorithm.
UserKeyingMaterial ::= OCTET STRING UserKeyingMaterial ::= OCTET STRING
skipping to change at page 40, line 35 skipping to change at page 41, line 28
include multiple instances of the signing-time attribute. include multiple instances of the signing-time attribute.
No requirement is imposed concerning the correctness of the signing No requirement is imposed concerning the correctness of the signing
time, and acceptance of a purported signing time is a matter of a time, and acceptance of a purported signing time is a matter of a
recipient's discretion. It is expected, however, that some signers, recipient's discretion. It is expected, however, that some signers,
such as time-stamp servers, will be trusted implicitly. such as time-stamp servers, will be trusted implicitly.
11.4 Countersignature 11.4 Countersignature
The countersignature attribute type specifies one or more signatures The countersignature attribute type specifies one or more signatures
on the contents octets of the DER encoding of the signatureValue on the contents octets of the signature OCTET STRING in a SignerInfo
field of a SignerInfo value in signed-data. Thus, the value of the signed-data. That is, the message digest is computed
countersignature attribute type countersigns (signs in serial) over the octets comprising the value of the OCTET STRING, neither the
another signature. tag nor length octets are included. Thus, the countersignature
attribute type countersigns (signs in serial) another signature.
The countersignature attribute MUST be an unsigned attribute; it MUST The countersignature attribute MUST be an unsigned attribute; it MUST
NOT be a signed attribute, an authenticated attribute, an NOT be a signed attribute, an authenticated attribute, an
unauthenticated attribute, or an unprotected attribute. unauthenticated attribute, or an unprotected attribute.
The following object identifier identifies the countersignature The following object identifier identifies the countersignature
attribute: attribute:
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }
skipping to change at page 42, line 41 skipping to change at page 43, line 41
ContentInfo ::= SEQUENCE { ContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType } content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER ContentType ::= OBJECT IDENTIFIER
SignedData ::= SEQUENCE { SignedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers, digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL, certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos } signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo SignerInfos ::= SET OF SignerInfo
EncapsulatedContentInfo ::= SEQUENCE { EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL } eContent [0] EXPLICIT OCTET STRING OPTIONAL }
skipping to change at page 43, line 39 skipping to change at page 44, line 39
EnvelopedData ::= SEQUENCE { EnvelopedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo, encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
OriginatorInfo ::= SEQUENCE { OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL, certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE { EncryptedContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING EncryptedContent ::= OCTET STRING
skipping to change at page 46, line 34 skipping to change at page 47, line 34
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
CertificateRevocationLists ::= SET OF CertificateList RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoice ::= CHOICE {
crl CertificateList,
other [1] IMPLICIT OtherRevocationInfoFormat }
OtherRevocationInfoFormat ::= SEQUENCE {
otherRevInfoFormat OBJECT IDENTIFIER,
otherRevInfo ANY DEFINED BY otherRevInfoFormat }
CertificateChoices ::= CHOICE { CertificateChoices ::= CHOICE {
certificate Certificate, certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2, v2AttrCert [2] IMPLICIT AttributeCertificateV2,
other [3] IMPLICIT OtherCertificateFormat } other [3] IMPLICIT OtherCertificateFormat }
AttributeCertificateV2 ::= AttributeCertificate AttributeCertificateV2 ::= AttributeCertificate
OtherCertificateFormat ::= SEQUENCE { OtherCertificateFormat ::= SEQUENCE {
otherCertFormat OBJECT IDENTIFIER, otherCertFormat OBJECT IDENTIFIER,
otherCert ANY DEFINED BY otherCertFormat } otherCert ANY DEFINED BY otherCertFormat }
CertificateSet ::= SET OF CertificateChoices CertificateSet ::= SET OF CertificateChoices
IssuerAndSerialNumber ::= SEQUENCE { IssuerAndSerialNumber ::= SEQUENCE {
issuer Name, issuer Name,
serialNumber CertificateSerialNumber } serialNumber CertificateSerialNumber }
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) v5(5) } CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }
UserKeyingMaterial ::= OCTET STRING UserKeyingMaterial ::= OCTET STRING
OtherKeyAttribute ::= SEQUENCE { OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER, keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL } keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
-- Content Type Object Identifiers
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }
-- The CMS Attributes -- The CMS Attributes
MessageDigest ::= OCTET STRING MessageDigest ::= OCTET STRING
SigningTime ::= Time SigningTime ::= Time
Time ::= CHOICE { Time ::= CHOICE {
utcTime UTCTime, utcTime UTCTime,
generalTime GeneralizedTime } generalTime GeneralizedTime }
Countersignature ::= SignerInfo Countersignature ::= SignerInfo
-- Attribute Object Identifiers -- Attribute Object Identifiers
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
skipping to change at page 48, line 20 skipping to change at page 50, line 11
Signature ::= BIT STRING Signature ::= BIT STRING
END -- of CryptographicMessageSyntax2004 END -- of CryptographicMessageSyntax2004
12.2 Version 1 Attribute Certificate ASN.1 Module 12.2 Version 1 Attribute Certificate ASN.1 Module
AttributeCertificateVersion1 AttributeCertificateVersion1
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) } pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
IMPORTS IMPORTS
-- Imports from RFC 3280 [PROFILE], Appendix A.1 -- Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier, Attribute, CertificateSerialNumber, AlgorithmIdentifier, Attribute, CertificateSerialNumber,
Extensions, UniqueIdentifier Extensions, UniqueIdentifier
FROM PKIX1Explicit88 FROM PKIX1Explicit88
skipping to change at page 50, line 16 skipping to change at page 52, line 10
Authentication Framework. 1988. Authentication Framework. 1988.
[X.509-97] ITU-T. Recommendation X.509: The Directory - [X.509-97] ITU-T. Recommendation X.509: The Directory -
Authentication Framework. 1997. Authentication Framework. 1997.
[X.509-00] ITU-T. Recommendation X.509: The Directory - [X.509-00] ITU-T. Recommendation X.509: The Directory -
Authentication Framework. 2000. Authentication Framework. 2000.
14. Informative References 14. Informative References
[CMS1] Housley, R., "Cryptographic Message Syntax", [CMS1] Housley, R., "Cryptographic Message Syntax",
RFC 2630, June 1999. RFC 2630, June 1999.
[CMS2] Housley, R., "Cryptographic Message Syntax", [CMS2] Housley, R., "Cryptographic Message Syntax",
RFC 3369, August 2002. RFC 3369, August 2002.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3269, August 2002. Algorithms", RFC 3370, August 2002.
[DSS] National Institute of Standards and Technology. [DSS] National Institute of Standards and Technology.
FIPS Pub 186: Digital Signature Standard. 19 May 1994. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
[MSG] Ramsdell, B., "S/MIME Version 3 Message Specification", [MSG] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999. RFC 2633, June 1999.
[OLDMSG] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
L. Repka, "S/MIME Version 2 Message Specification", C. Adams, "X.509 Internet Public Key Infrastructure
RFC 2311, March 1998. Online Certificate Status Protocol - OCSP", RFC 2560,
June 1999.
[PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax [OLDMSG] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
Standard, Version 1.5. November 1993. L. Repka, "S/MIME Version 2 Message Specification",
RFC 2311, March 1998.
[PKCS#7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax, [PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax
Version 1.5.", RFC 2315, March 1998. Standard, Version 1.5. November 1993.
[PKCS#9] RSA Laboratories. PKCS #9: Selected Attribute Types, [PKCS#7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax,
Version 1.1. November 1993. Version 1.5.", RFC 2315, March 1998.
[PWRI] Gutmann, P., "Password-based Encryption for S/MIME", [PKCS#9] RSA Laboratories. PKCS #9: Selected Attribute Types,
RFC 3211, December 2001. Version 1.1. November 1993.
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [PWRI] Gutmann, P., "Password-based Encryption for S/MIME",
Recommendations for Security", RFC 1750, December 1994. RFC 3211, December 2001.
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
15. Security Considerations 15. 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.
skipping to change at page 51, line 51 skipping to change at page 53, line 51
Implementations must randomly generate content-encryption keys, Implementations must randomly generate content-encryption keys,
message-authentication keys, initialization vectors (IVs), and message-authentication keys, initialization vectors (IVs), and
padding. Also, the generation of public/private key pairs relies on padding. Also, the generation of public/private key pairs relies on
a random numbers. The use of inadequate pseudo-random number a random numbers. The use of inadequate pseudo-random number
generators (PRNGs) to generate cryptographic keys can result in generators (PRNGs) to generate cryptographic keys can result in
little or no security. An attacker may find it much easier to little or no security. An attacker may find it much easier to
reproduce the PRNG environment that produced the keys, searching the reproduce the PRNG environment that produced the keys, searching the
resulting small set of possibilities, rather than brute force resulting small set of possibilities, rather than brute force
searching the whole key space. The generation of quality random searching the whole key space. The generation of quality random
numbers is difficult. RFC 1750 [RANDOM] offers important guidance in numbers is difficult. RFC 1750 [RANDOM] offers important guidance
this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality in this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one
PRNG technique. quality PRNG technique.
When using key agreement algorithms or previously distributed When using key agreement algorithms or previously distributed
symmetric key-encryption keys, a key-encryption key is used to symmetric key-encryption keys, a key-encryption key is used to
encrypt the content-encryption key. If the key-encryption and encrypt the content-encryption key. If the key-encryption and
content-encryption algorithms are different, the effective security content-encryption algorithms are different, the effective security
is determined by the weaker of the two algorithms. If, for example, is determined by the weaker of the two algorithms. If, for example,
content is encrypted with Triple-DES using a 168-bit Triple-DES content is encrypted with Triple-DES using a 168-bit Triple-DES
content-encryption key, and the content-encryption key is wrapped content-encryption key, and the content-encryption key is wrapped
with RC2 using a 40-bit RC2 key-encryption key, then at most 40 bits with RC2 using a 40-bit RC2 key-encryption key, then at most 40 bits
of protection is provided. A trivial search to determine the value of protection is provided. A trivial search to determine the value
skipping to change at page 53, line 20 skipping to change at page 55, line 20
Herndon, VA 20170 Herndon, VA 20170
USA USA
EMail: housley@vigilsec.com EMail: housley@vigilsec.com
18. Full Copyright Statement 18. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published and
and distributed, in whole or in part, without restriction of any distributed, in whole or in part, without restriction of any kind,
kind, provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 54 change blocks. 
173 lines changed or deleted 267 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/