| < draft-ietf-smime-rfc3369bis-03.txt | draft-ietf-smime-rfc3369bis-04.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 April 2004 | When Approved, Obsoletes: 3369 May 2004 | |||
| Cryptographic Message Syntax (CMS) | Cryptographic Message Syntax (CMS) | |||
| <draft-ietf-smime-rfc3369bis-03.txt> | <draft-ietf-smime-rfc3369bis-04.txt> | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
| all provisions of Section 10 of RFC2026. Internet-Drafts are working | all provisions of Section 10 of RFC2026. Internet-Drafts are working | |||
| documents of the Internet Engineering Task Force (IETF), its areas, | documents of the Internet Engineering Task Force (IETF), its areas, | |||
| and its working groups. Note that other groups may also distribute | and its working groups. Note that other groups may also distribute | |||
| working documents as Internet-Drafts. | working documents as Internet-Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| skipping to change at page 2, line 8 ¶ | skipping to change at page 2, line 8 ¶ | |||
| 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 Evolution of the CMS ..................................... ?? | |||
| 1.2 Changes Since RFC 3369 ................................... ?? | 1.1.1 Changes Since PKCS #7 Version 1.5 ........................ ?? | |||
| 1.3 Terminology .............................................. ?? | 1.1.2 Changes Since RFC 2630 ................................... ?? | |||
| 1.1.3 Changes Since RFC 3369 ................................... ?? | ||||
| 1.2 Terminology .............................................. ?? | ||||
| 1.3 Version Numbers .......................................... ?? | ||||
| 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 ............................. ?? | |||
| skipping to change at page 4, line 32 ¶ | skipping to change at page 4, line 32 ¶ | |||
| [PROFILE]. | [PROFILE]. | |||
| The CMS values are generated using ASN.1 [X.208-88], using BER- | The CMS values are generated using ASN.1 [X.208-88], using BER- | |||
| encoding [X.209-88]. Values are typically represented as octet | encoding [X.209-88]. Values are typically represented as octet | |||
| strings. While many systems are capable of transmitting arbitrary | strings. While many systems are capable of transmitting arbitrary | |||
| octet strings reliably, it is well known that many electronic mail | octet strings reliably, it is well known that many electronic mail | |||
| systems are not. This document does not address mechanisms for | systems are not. This document does not address mechanisms for | |||
| encoding octet strings for reliable transmission in such | encoding octet strings for reliable transmission in such | |||
| environments. | environments. | |||
| The CMS is derived from PKCS #7 version 1.5 as specified in RFC 2315 | 1.1 Evolution of the CMS | |||
| [PKCS#7]. Wherever possible, backward compatibility is preserved; | ||||
| however, changes were necessary to accommodate version 1 attribute | ||||
| certificate transfer, key agreement and symmetric key-encryption key | ||||
| techniques for key management. | ||||
| 1.1 Changes Since RFC 2630 | The CMS is derived from PKCS #7 version 1.5, which is documented in | |||
| RFC 2315 [PKCS#7]. PKCS #7 version 1.5 was developed outside of the | ||||
| IETF; it was originally published as an RSA Laboratories Technical | ||||
| Note in November 1993. Since that time, the IETF has taken | ||||
| responsibility for the development and maintenance of the CMS. | ||||
| Today, several important IETF standards-track protocols make use of | ||||
| the CMS. | ||||
| This section describes that changes that the IETF has made to the CMS | ||||
| in each of the published versions. | ||||
| 1.1.1 Changes Since PKCS #7 Version 1.5 | ||||
| RFC 2630 [CMS1] was the first version of the CMS on the IETF | ||||
| standards track. Wherever possible, backward compatibility with PKCS | ||||
| #7 version 1.5 is preserved; however, changes were made to | ||||
| accommodate version 1 attribute certificate transfer and to support | ||||
| algorithm independent key management. PKCS #7 version 1.5 included | ||||
| support only for key transport. RFC 2630 adds support for key | ||||
| agreement and previously distributed symmetric key-encryption key | ||||
| techniques. | ||||
| 1.1.2 Changes Since RFC 2630 | ||||
| RFC 3369 [CMS2] obsoletes RFC 2630 [CMS1] and RFC 3211 [PWRI]. | RFC 3369 [CMS2] obsoletes RFC 2630 [CMS1] and RFC 3211 [PWRI]. | |||
| Password-based key management is included in the CMS specification, | Password-based key management is included in the CMS specification, | |||
| and an extension mechanism to support new key management schemes | and an extension mechanism to support new key management schemes | |||
| without further changes to the CMS is specified. Backward | without further changes to the CMS is specified. Backward | |||
| compatibility with RFC 2630 and RFC 3211 is preserved; however, | compatibility with RFC 2630 and RFC 3211 is preserved; however, | |||
| version 2 attribute certificate transfer is added. The use of | version 2 attribute certificate transfer is added, and the use of | |||
| version 1 attribute certificates is deprecated. | version 1 attribute certificates is deprecated. | |||
| S/MIME v2 signatures [OLDMSG], which are based on PKCS#7 version 1.5, | S/MIME v2 signatures [OLDMSG], which are based on PKCS#7 version 1.5, | |||
| are compatible with S/MIME v3 signatures [MSG], which are based on | are compatible with S/MIME v3 signatures [MSG], which are based on | |||
| RFC 2630. However, there are some subtle compatibility issues with | RFC 2630. However, there are some subtle compatibility issues with | |||
| signatures using PKCS#7 version 1.5 and the CMS. These issues are | signatures based on PKCS #7 version 1.5. These issues are discussed | |||
| discussed in section 5.2.1. | in section 5.2.1. These issues remain with the current version of | |||
| the CMS. | ||||
| Specific cryptographic algorithms are not discussed in this document, | Specific cryptographic algorithms are not discussed in this document, | |||
| but they were discussed in RFC 2630. The discussion of specific | but they were discussed in RFC 2630. The discussion of specific | |||
| 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.1.3 Changes Since RFC 3369 | |||
| This document obsoletes RFC 3369 [CMS2]. As discussed in the | This document obsoletes RFC 3369 [CMS2]. As discussed in the | |||
| previous section, RFC 3369 introduced an extension mechanism to | previous section, RFC 3369 introduced an extension mechanism to | |||
| support new key management schemes without further changes to the | support new key management schemes without further changes to the | |||
| CMS. This document introduces a similar extension mechanism to | CMS. This document introduces a similar extension mechanism to | |||
| support additional certificate formats and revocation status | support additional certificate formats and revocation status | |||
| information formats without further changes to the CMS. These | information formats without further changes to the CMS. These | |||
| extensions are primarily documented in section 10.2.1 and section | extensions are primarily documented in section 10.2.1 and section | |||
| 10.2.2. Backward compatibility with both RFC 2630 and RFC 3369 is | 10.2.2. Backward compatibility with earlier versions of the CMS is | |||
| preserved. | preserved. | |||
| The use of version numbers is described in section 1.3. | ||||
| Since the publication of RFC 3369, a few errata have been noted. | Since the publication of RFC 3369, a few errata have been noted. | |||
| These errata are posted on the RFC Editor web site. These errors | These errata are posted on the RFC Editor web site. These errors | |||
| have been corrected in this document. | have been corrected in this document. | |||
| The text in section 11.4 that describes the counter signature | The text in section 11.4 that describes the counter signature | |||
| unsigned attribute is clarified. Hopefully the revised text is | unsigned attribute is clarified. Hopefully the revised text is | |||
| clearer about the portion of the SignerInfo signature that is covered | clearer about the portion of the SignerInfo signature that is covered | |||
| by a countersignature. | by a countersignature. | |||
| 1.3 Terminology | 1.2 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]. | |||
| 1.3 Version Numbers | ||||
| Each of the major data structures includes a version number as the | ||||
| first item in the data structure. The version numbers are intended | ||||
| to avoid ASN.1 decode errors. Some implementations do not check the | ||||
| version number prior to attempting a decode, and if a decode error | ||||
| occurs, then the version number is checked as part of the error | ||||
| handling routine. This is a reasonable approach; it places error | ||||
| processing outside of the fast path. This approach is also forgiving | ||||
| when an incorrect version number is used by the sender. | ||||
| Most of the initial version numbers were assigned in PKCS #7 version | ||||
| 1.5. Others were assigned when the structure was initially created. | ||||
| Whenever a structure is updated, a higher version number is assigned. | ||||
| However, to ensure maximum interoperability the higher version number | ||||
| is only used when the new syntax feature is employed. That is, the | ||||
| lowest version number that supports the generated syntax is used. | ||||
| 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. | |||
| This document defines one protection content, ContentInfo. | This document defines one protection content, ContentInfo. | |||
| ContentInfo encapsulates a single identified content type, and the | ContentInfo encapsulates a single identified content type, and the | |||
| identified type may provide further encapsulation. This document | identified type may provide further encapsulation. This document | |||
| defines six content types: data, signed-data, enveloped-data, | defines six content types: data, signed-data, enveloped-data, | |||
| digested-data, encrypted-data, and authenticated-data. Additional | digested-data, encrypted-data, and authenticated-data. Additional | |||
| content types can be defined outside this document. | content types can be defined outside this document. | |||
| skipping to change at page 9, line 40 ¶ | skipping to change at page 10, line 34 ¶ | |||
| 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 | authority" to all of the signers in the signerInfos field. There | |||
| may be more certificates than necessary, and there may be | ||||
| signers in the signerInfos field. There may be more certificates | certificates sufficient to contain certification paths from two or | |||
| than necessary, and there may be certificates sufficient to | more independent top-level certification authorities. There may | |||
| contain certification paths from two or more independent top-level | also be fewer certificates than necessary, if it is expected that | |||
| certification authorities. There may also be fewer certificates | recipients have an alternate means of obtaining necessary | |||
| than necessary, if it is expected that recipients have an | certificates (e.g., from a previous set of certificates). The | |||
| alternate means of obtaining necessary certificates (e.g., from a | signer's certificate MAY be included. The use of version 1 | |||
| previous set of certificates). The signer's certificate MAY be | attribute certificates is strongly discouraged. | |||
| 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 12, line 18 ¶ | skipping to change at page 13, line 10 ¶ | |||
| 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: | [MSAC], the following information MAY be included: | |||
| eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 } | eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 } | |||
| eContent contains DER encoded AuthentiCode signing information | eContent contains DER encoded Authenticode signing information | |||
| 5.3 SignerInfo Type | 5.3 SignerInfo Type | |||
| Per-signer information is represented in the type SignerInfo: | Per-signer information is represented in the type SignerInfo: | |||
| SignerInfo ::= SEQUENCE { | SignerInfo ::= SEQUENCE { | |||
| version CMSVersion, | version CMSVersion, | |||
| sid SignerIdentifier, | sid SignerIdentifier, | |||
| digestAlgorithm DigestAlgorithmIdentifier, | digestAlgorithm DigestAlgorithmIdentifier, | |||
| signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, | signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, | |||
| skipping to change at page 16, line 25 ¶ | skipping to change at page 17, line 19 ¶ | |||
| content-type attribute value MUST match the SignedData | content-type attribute value MUST match the SignedData | |||
| encapContentInfo eContentType value. | encapContentInfo eContentType value. | |||
| 6. Enveloped-data Content Type | 6. Enveloped-data Content Type | |||
| The enveloped-data content type consists of an encrypted content of | The enveloped-data content type consists of an encrypted content of | |||
| any type and encrypted content-encryption keys for one or more | any type and encrypted content-encryption keys for one or more | |||
| recipients. The combination of the encrypted content and one | recipients. The combination of the encrypted content and one | |||
| encrypted content-encryption key for a recipient is a "digital | encrypted content-encryption key for a recipient is a "digital | |||
| envelope" for that recipient. Any type of content can be enveloped | envelope" for that recipient. Any type of content can be enveloped | |||
| for an arbitrary number of recipients using any of the three key | for an arbitrary number of recipients using any of the supported key | |||
| management techniques for each recipient. | management techniques for each recipient. | |||
| The typical application of the enveloped-data content type will | The typical application of the enveloped-data content type will | |||
| represent one or more recipients' digital envelopes on content of the | represent one or more recipients' digital envelopes on content of the | |||
| data or signed-data content types. | data or signed-data content types. | |||
| Enveloped-data is constructed by the following steps: | Enveloped-data is constructed by the following steps: | |||
| 1. A content-encryption key for a particular content-encryption | 1. A content-encryption key for a particular content-encryption | |||
| algorithm is generated at random. | algorithm is generated at random. | |||
| skipping to change at page 23, line 10 ¶ | skipping to change at page 24, line 5 ¶ | |||
| to the appropriate certificate field. The originatorKey | to the appropriate certificate field. The originatorKey | |||
| alternative includes the algorithm identifier and sender's key | alternative includes the algorithm identifier and sender's key | |||
| agreement public key. This alternative permits originator | agreement public key. This alternative permits originator | |||
| anonymity since the public key is not certified. Implementations | anonymity since the public key is not certified. Implementations | |||
| MUST support all three alternatives for specifying the sender's | MUST support all three alternatives for specifying the sender's | |||
| public key. | public key. | |||
| ukm is optional. With some key agreement algorithms, the sender | ukm is optional. With some key agreement algorithms, the sender | |||
| provides a User Keying Material (UKM) to ensure that a different | provides a User Keying Material (UKM) to ensure that a different | |||
| key is generated each time the same two parties generate a | key is generated each time the same two parties generate a | |||
| pairwise key. Implementations MUST support recipient processing | pairwise key. Implementations MUST accept a KeyAgreeRecipientInfo | |||
| of a KeyAgreeRecipientInfo SEQUENCE that includes a ukm field. | SEQUENCE that includes a ukm field. Implementations that do not | |||
| Implementations that do not support key agreement algorithms that | support key agreement algorithms that make use of UKMs MUST | |||
| make use of UKMs MUST gracefully handle the presence of UKMs. | gracefully handle the presence of UKMs. | |||
| keyEncryptionAlgorithm identifies the key-encryption algorithm, | keyEncryptionAlgorithm identifies the key-encryption algorithm, | |||
| and any associated parameters, used to encrypt the content- | and any associated parameters, used to encrypt the content- | |||
| encryption key with the key-encryption key. The key-encryption | encryption key with the key-encryption key. The key-encryption | |||
| process is described in Section 6.4. | process is described in Section 6.4. | |||
| recipientEncryptedKeys includes a recipient identifier and | recipientEncryptedKeys includes a recipient identifier and | |||
| encrypted key for one or more recipients. The | encrypted key for one or more recipients. The | |||
| KeyAgreeRecipientIdentifier is a CHOICE with two alternatives | KeyAgreeRecipientIdentifier is a CHOICE with two alternatives | |||
| specifying the recipient's certificate, and thereby the | specifying the recipient's certificate, and thereby the | |||
| skipping to change at page 36, line 38 ¶ | skipping to change at page 37, line 35 ¶ | |||
| The definition of Certificate is taken from X.509. | The definition of Certificate is taken from X.509. | |||
| The definitions of AttributeCertificate are taken from X.509-1997 and | The definitions of AttributeCertificate are taken from X.509-1997 and | |||
| X.509-2000. The definition from X.509-1997 is assigned to | X.509-2000. The definition from X.509-1997 is assigned to | |||
| AttributeCertificateV1 (see section 12.2), and the definition from | AttributeCertificateV1 (see section 12.2), and the definition from | |||
| X.509-2000 is assigned to AttributeCertificateV2. | X.509-2000 is assigned to AttributeCertificateV2. | |||
| 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 } | |||
| OtherCertificateFormat ::= SEQUENCE { | OtherCertificateFormat ::= SEQUENCE { | |||
| otherCertFormat OBJECT IDENTIFIER, | otherCertFormat OBJECT IDENTIFIER, | |||
| otherCert ANY DEFINED BY otherCertFormat } | otherCert ANY DEFINED BY otherCertFormat } | |||
| 10.2.3 CertificateSet | 10.2.3 CertificateSet | |||
| The CertificateSet type provides a set of certificates. It is | The CertificateSet type provides a set of certificates. It is | |||
| skipping to change at page 40, line 32 ¶ | skipping to change at page 41, line 26 ¶ | |||
| attribute: | attribute: | |||
| id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) | id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) | |||
| us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } | us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } | |||
| Signing-time attribute values have ASN.1 type SigningTime: | Signing-time attribute values have ASN.1 type SigningTime: | |||
| SigningTime ::= Time | SigningTime ::= Time | |||
| Time ::= CHOICE { | Time ::= CHOICE { | |||
| utcTime UTCTime, | utcTime UTCTime, | |||
| generalizedTime GeneralizedTime } | generalizedTime GeneralizedTime } | |||
| Note: The definition of Time matches the one specified in the 1997 | Note: The definition of Time matches the one specified in the 1997 | |||
| version of X.509 [X.509-97]. | version of X.509 [X.509-97]. | |||
| Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be | Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be | |||
| encoded as UTCTime. Any dates with year values before 1950 or after | encoded as UTCTime. Any dates with year values before 1950 or after | |||
| 2049 MUST be encoded as GeneralizedTime. | 2049 MUST be encoded as GeneralizedTime. | |||
| UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and | UTCTime values MUST be expressed in Coordinated Universal Time | |||
| (formerly known as Greenwich Mean Time (GMT) and Zulu clock time) and | ||||
| MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the | MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the | |||
| number of seconds is zero. Midnight MUST be represented as | ||||
| number of seconds is zero. Midnight (GMT) MUST be represented as | ||||
| "YYMMDD000000Z". Century information is implicit, and the century | "YYMMDD000000Z". Century information is implicit, and the century | |||
| MUST be determined as follows: | MUST be determined as follows: | |||
| Where YY is greater than or equal to 50, the year MUST be | Where YY is greater than or equal to 50, the year MUST be | |||
| interpreted as 19YY; and | interpreted as 19YY; and | |||
| Where YY is less than 50, the year MUST be interpreted as 20YY. | Where YY is less than 50, the year MUST be interpreted as 20YY. | |||
| GeneralizedTime values MUST be expressed in Greenwich Mean Time | GeneralizedTime values MUST be expressed in Coordinated Universal | |||
| (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), | Time and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even | |||
| even where the number of seconds is zero. GeneralizedTime values | where the number of seconds is zero. GeneralizedTime values MUST NOT | |||
| MUST NOT include fractional seconds. | include fractional seconds. | |||
| A signing-time attribute MUST have a single attribute value, even | A signing-time attribute MUST have a single attribute value, even | |||
| though the syntax is defined as a SET OF AttributeValue. There MUST | though the syntax is defined as a SET OF AttributeValue. There MUST | |||
| NOT be zero or multiple instances of AttributeValue present. | NOT be zero or multiple instances of AttributeValue present. | |||
| The SignedAttributes syntax and the AuthAttributes syntax are each | The SignedAttributes syntax and the AuthAttributes syntax are each | |||
| defined as a SET OF Attributes. The SignedAttributes in a signerInfo | defined as a SET OF Attributes. The SignedAttributes in a signerInfo | |||
| MUST NOT include multiple instances of the signing-time attribute. | MUST NOT include multiple instances of the signing-time attribute. | |||
| Similarly, the AuthAttributes in an AuthenticatedData MUST NOT | Similarly, the AuthAttributes in an AuthenticatedData MUST NOT | |||
| include multiple instances of the signing-time attribute. | include multiple instances of the signing-time attribute. | |||
| skipping to change at page 52, line 19 ¶ | skipping to change at page 52, line 35 ¶ | |||
| [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 3370, August 2002. | Algorithms", RFC 3370, August 2002. | |||
| [DSS] National Institute of Standards and Technology. | ||||
| 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. | |||
| [MSAC] Microsoft Development Network (MSDN) Library, | ||||
| "Authenticode", April 2004 Release. | ||||
| [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. | |||
| [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and | [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and | |||
| C. Adams, "X.509 Internet Public Key Infrastructure | C. Adams, "X.509 Internet Public Key Infrastructure | |||
| Online Certificate Status Protocol - OCSP", RFC 2560, | Online Certificate Status Protocol - OCSP", RFC 2560, | |||
| June 1999. | June 1999. | |||
| [OLDMSG] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and | [OLDMSG] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and | |||
| L. Repka, "S/MIME Version 2 Message Specification", | L. Repka, "S/MIME Version 2 Message Specification", | |||
| skipping to change at page 53, line 51 ¶ | skipping to change at page 54, line 19 ¶ | |||
| 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 | numbers is difficult. RFC 1750 [RANDOM] offers important guidance in | |||
| in this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one | this area. | |||
| 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 | |||
| End of changes. 25 change blocks. | ||||
| 53 lines changed or deleted | 92 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/ | ||||