--- 1/draft-ietf-lamps-rfc5751-bis-06.txt 2018-04-13 14:13:14.516020496 -0700 +++ 2/draft-ietf-lamps-rfc5751-bis-07.txt 2018-04-13 14:13:14.624023085 -0700 @@ -1,22 +1,22 @@ LAMPS J. Schaad Internet-Draft August Cellars Obsoletes: 5751 (if approved) B. Ramsdell Intended status: Standards Track Brute Squad Labs, Inc. -Expires: October 16, 2017 S. Turner +Expires: October 15, 2018 S. Turner sn3rd - April 14, 2017 + April 13, 2018 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification - draft-ietf-lamps-rfc5751-bis-06 + draft-ietf-lamps-rfc5751-bis-07 Abstract This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. @@ -29,37 +29,37 @@ be discussed on the LAMPS mailing list. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. + Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 16, 2017. + This Internet-Draft will expire on October 15, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this @@ -75,21 +75,21 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Specification Overview . . . . . . . . . . . . . . . . . 4 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Conventions Used in This Document . . . . . . . . . . . . 6 1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 7 1.5. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 7 1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 8 1.7. Changes for S/MIME v4.0 . . . . . . . . . . . . . . . . . 9 - 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 10 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11 2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 12 2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 12 2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 12 2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 12 2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 12 2.4.5. CompressedData Content Type . . . . . . . . . . . . . 12 2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 13 @@ -105,21 +105,21 @@ 3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 21 3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 22 3.1.3. Transfer Encoding for Signing Using multipart/signed 22 3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 23 3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 24 3.2.1. The name and filename Parameters . . . . . . . . . . 25 3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 26 3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 27 - 3.4. Creating an Authenticated Enveloped-Only Message . . . . 27 + 3.4. Creating an Authenticated Enveloped-Only Message . . . . 28 3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 29 3.5.1. Choosing a Format for Signed-Only Messages . . . . . 29 3.5.2. Signing Using application/pkcs7-mime with SignedData 30 3.5.3. Signing Using the multipart/signed Format . . . . . . 31 3.6. Creating a Compressed-Only Message . . . . . . . . . . . 34 3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 34 3.8. Creating a Certificate Management Message . . . . . . . . 35 3.9. Registration Requests . . . . . . . . . . . . . . . . . . 36 3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 36 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 36 @@ -131,21 +131,21 @@ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 38 5.2. Media Type for application/pkcs7-signature . . . . . . . 39 5.3. Register authEnveloped-data smime-type . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 7.1. Normative References . . . . . . . . . . . . . . . . . . 44 7.2. Informative References . . . . . . . . . . . . . . . . . 48 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 51 Appendix B. Historic Mail Considerations . . . . . . . . . . . . 53 - B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 53 + B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 54 B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 54 B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 56 B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 56 Appendix C. Moving S/MIME v2 Message Specification to Historic Status . . . . . . . . . . . . . . . . . . . . . . . 56 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 1. Introduction @@ -216,22 +216,22 @@ 1.2. Definitions For the purposes of this specification, the following definitions apply. ASN.1: Abstract Syntax Notation One, as defined in ITU-T Recommendations X.680, X.681, X.682 and X.683 [ASN.1]. - BER: Basic Encoding Rules for ASN.1, as defined in ITU- - T Recommendation X.690 [X.690]. + BER: Basic Encoding Rules for ASN.1, as defined in + ITU-T Recommendation X.690 [X.690]. Certificate: A type that binds an entity's name to a public key with a digital signature. DER: Distinguished Encoding Rules for ASN.1, as defined in ITU-T Recommendation X.690 [X.690]. 7-bit data: Text data with lines less than 998 characters long, where none of the characters have the 8th bit set, and there are no NULL characters. @@ -253,31 +253,28 @@ objects, MIME body parts that contain CMS content types, or both. Sending agent: Software that creates S/MIME CMS content types, MIME body parts that contain CMS content types, or both. S/MIME agent: User software that is a receiving agent, a sending agent, or both. - Data Integrity Service: A security service that protects againist + Data Integrity Service: A security service that protects against unauthorized changes to data by ensuring that changes to the data are detectable. [RFC4949] - Data Confidentiality: The property that data is not discolsed to + Data Confidentiality: The property that data is not disclosed to system entities unless they have been authorized to know the data. [RFC4949] - Data Origination: The corroboration that the source of the data - received is as claimed. [RFC4949]. - 1.3. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. We define the additional requirement levels: SHOULD+ This term means the same as SHOULD. However, the authors expect that a requirement marked as SHOULD+ will be @@ -380,21 +377,21 @@ and AES-256 CBC SHOULD+, tripleDES now SHOULD-. Section 2.7.1: Updated pointers from 2.7.2.1 through 2.7.2.4 to 2.7.1.1 to 2.7.1.2. Section 3.1.1: Removed text about MIME character sets. Section 3.2.2 and 3.6: Replaced "encrypted" with "enveloped". Update OID example to use AES-128 CBC oid. - Section 3.4.3.2: Replace micalg parameter for SHA-1 with sha-1. + Section 3.4.3.2: Replace "micalg" parameter for "SHA-1" with "sha-1". Section 4: Updated reference to CERT v3.2. Section 4.1: Updated RSA and DSA key size discussion. Moved last four sentences to security considerations. Updated reference to randomness requirements for security. Section 5: Added IANA registration templates to update media type registry to point to this document as opposed to RFC 2311. @@ -450,54 +447,56 @@ - MUST support SHA-256. - MUST support SHA-512. [RFC5754] provides the details for using these algorithms with S/MIME. 2.2. SignatureAlgorithmIdentifier + There are different sets of requirements placed on receiving and + sending agents. By having the different requirements, the maximum + amount of interoperability is achieved as it allows for specialized + protection of private key material but maximum signature validation. + Receiving agents: - MUST support ECDSA with curve P-256 and SHA-256. - MUST support EdDSA with curve 25519 using PureEdDSA mode. - - MUST- support RSA with SHA-256. + - MUST- support RSA PKCS#1 v1.5 with SHA-256. - SHOULD support RSASSA-PSS with SHA-256. - - MUST NOT support EdDSA using the pre-hash mode. - Sending agents: - MUST support at least one of the following algorithms: ECDSA with curve P-256 and SHA-256, or EdDSA with curve 25519 using PureEdDSA mode. - - MUST- support RSA with SHA-256. + - MUST- support RSA PKCS#1 v1.5 with SHA-256. - SHOULD support RSASSA-PSS with SHA-256. - - MUST NOT support EdDSA using the pre-hash mode. - Both ECDSA and EdDSA are included in the list of required algorithms for political reasons. NIST is unable to provide the seeds that were used to create their standardized curves, this means that there is a - section of the community which believes that there might be a - backdoor to these curves. The EdDSA curves were, in part, created in - response to this feeling. However, there are still significant + section of the community which believes that there might be a back + door to these curves. The EdDSA curves were standardized in the IETF + in a more transparent method. However, there are still significant sections of the industry which need to have NIST approved algorithms. - For this reason, both sets of curves are represented in the recieving + For this reason, both sets of curves are represented in the receiving agent list, but there is only a requirement for curve in the sending - agent list. + agent list. This requirement makes sure that maximum + interoperability between receivers and senders will exist. See Section 4.1 for information on key size and algorithm references. 2.3. KeyEncryptionAlgorithmIdentifier Receiving and sending agents: - MUST support ECDH ephemeral-static mode for P-256, as specified in [RFC5753]. @@ -508,21 +507,21 @@ - MUST- support RSA Encryption, as specified in [RFC3370]. - SHOULD+ support RSAES-OAEP, as specified in [RFC3560]. When ECDH ephemeral-static is used, a key wrap algorithm is also specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The underlying encryption functions for the key wrap and content encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm with AES-128 content encryption algorithm). As both 128 and 256 bit - AES modes are mandatory-to-implment as content encryption algorithms + AES modes are mandatory-to-implement as content encryption algorithms (Section 2.7), both the AES-128 and AES-256 key wrap algorithms MUST be supported when ECDH ephemeral-static is used. Appendix B provides information on algorithms support in older versions of S/MIME. 2.4. General Syntax There are several CMS content types. Of these, only the Data, SignedData, EnvelopedData, AuthEnvelopedData, and CompressedData @@ -628,55 +627,54 @@ Receiving agents MUST be able to process signing-time attributes that are encoded in either UTCTime or GeneralizedTime. 2.5.2. SMIME Capabilities Attribute The SMIMECapabilities attribute includes signature algorithms (such as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128 CBC"), authenticated symmetric algorithms (such as "AES-128 GCM") and key encipherment algorithms (such as "rsaEncryption"). The presence - of an algorthm based SMIME Capability attribute in this sequence + of an algorithm based SMIME Capability attribute in this sequence implies that the sender can deal with the algorithm as well as - undertanding the ASN.1 structures associated with that algorithm. + understanding the ASN.1 structures associated with that algorithm. There are also several identifiers that indicate support for other optional features such as binary encoding and compression. The SMIMECapabilities were designed to be flexible and extensible so that, in the future, a means of identifying other capabilities and preferences such as certificates can be added in a way that will not cause current clients to break. If present, the SMIMECapabilities attribute MUST be a - SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines - SignedAttributes as a SET OF Attribute. The SignedAttributes in a - signerInfo MUST NOT include multiple instances of the - SMIMECapabilities attribute. CMS defines the ASN.1 syntax for + SignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. + The SignedAttributes in a signerInfo MUST include a single instance + of the SMIMECapabilities attribute. CMS defines the ASN.1 syntax for Attribute to include attrValues SET OF AttributeValue. A SMIMECapabilities attribute MUST only include a single instance of - AttributeValue. There MUST NOT be zero or multiple instances of - AttributeValue present in the attrValues SET OF AttributeValue. + AttributeValue. If a signature is detected to violate these + requirements, the signature SHOULD be treated as failing. The semantics of the SMIMECapabilities attribute specify a partial list as to what the client announcing the SMIMECapabilities can support. A client does not have to list every capability it supports, and need not list all its capabilities so that the capabilities list doesn't get too long. In an SMIMECapabilities attribute, the object identifiers (OIDs) are listed in order of their preference, but SHOULD be separated logically along the lines of their categories (signature algorithms, symmetric algorithms, key encipherment algorithms, etc.). The structure of the SMIMECapabilities attribute is to facilitate simple table lookups and binary comparisons in order to determine - matches. For instance, the DER-encoding for the SMIMECapability for - AES-128 CBC MUST be identically encoded regardless of the - implementation. Because of the requirement for identical encoding, + matches. For instance, the encoding for the SMIMECapability for + sha256WithRSAEncryption includes rather than omits the NULL + parameter. Because of the requirement for identical encoding, individuals documenting algorithms to be used in the SMIMECapabilities attribute SHOULD explicitly document the correct byte sequence for the common cases. For any capability, the associated parameters for the OID MUST specify all of the parameters necessary to differentiate between two instances of the same algorithm. The OIDs that correspond to algorithms SHOULD use the same OID as the actual algorithm, except in the case where the algorithm usage is @@ -704,29 +702,27 @@ The encryption key preference attribute allows the signer to unambiguously describe which of the signer's certificates has the signer's preferred encryption key. This attribute is designed to enhance behavior for interoperating with those clients that use separate keys for encryption and signing. This attribute is used to convey to anyone viewing the attribute which of the listed certificates is appropriate for encrypting a session key for future encrypted messages. If present, the SMIMEEncryptionKeyPreference attribute MUST be a - SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines - SignedAttributes as a SET OF Attribute. The SignedAttributes in a - signerInfo MUST NOT include multiple instances of the - SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax - for Attribute to include attrValues SET OF AttributeValue. A + SignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. + The SignedAttributes in a signerInfo MUST include a single instance + of the SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 + syntax for Attribute to include attrValues SET OF AttributeValue. A SMIMEEncryptionKeyPreference attribute MUST only include a single - instance of AttributeValue. There MUST NOT be zero or multiple - instances of AttributeValue present in the attrValues SET OF - AttributeValue. + instance of AttributeValue. If a signature is detected to violate + these requirements, the signature SHOULD be treated as failing. The sending agent SHOULD include the referenced certificate in the set of certificates included in the signed message if this attribute is used. The certificate MAY be omitted if it has been previously made available to the receiving agent. Sending agents SHOULD use this attribute if the commonly used or preferred encryption certificate is not the same as the certificate used to sign the message. Receiving agents SHOULD store the preference data if the signature on @@ -852,22 +848,23 @@ If the following two conditions are met: - the sending agent has no knowledge of the encryption capabilities of the recipient, and - the sending agent has no knowledge of the version of S/MIME of the recipient, then the sending agent SHOULD use AES-256 GCM because it is a stronger algorithm and is required by S/MIME v4.0. If the sending - agent chooses not to use AES-256 GCM in this step, it SHOULD use - AES-128 CBC. + agent chooses not to use AES-256 GCM in this step, given the + presumption is that a client implementing AES-GCM would do both + AES-256 and AES-128, it SHOULD use AES-128 CBC. 2.7.2. Choosing Weak Encryption All algorithms that use 112-bit keys are considered by many to be weak encryption. A sending agent that is controlled by a human SHOULD allow a human sender to determine the risks of sending data using a weak encryption algorithm before sending the data, and possibly allow the human to use a stronger encryption method such as AES GCM or AES CBC. @@ -955,21 +952,23 @@ When an S/MIME message is received, the security services on the message are processed, and the result is the MIME entity. That MIME entity is typically passed to a MIME-capable user agent where it is further decoded and presented to the user or receiving application. In order to protect outer, non-content-related message header fields (for instance, the "Subject", "To", "From", and "Cc" fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to these header fields. It is up to the receiving client to decide how to present - this "inner" header along with the unprotected "outer" header. + this "inner" header along with the unprotected "outer" header. It is + RECOMMENDED that a distinction be made between the location of the + header. When an S/MIME message is received, if the top-level protected MIME entity has a Content-Type of message/rfc822, it can be assumed that the intent was to provide header protection. This entity SHOULD be presented as the top-level message, taking into account header merging issues as previously discussed. 3.1.1. Canonicalization Each MIME entity MUST be converted to a canonical form that is @@ -1002,41 +1001,42 @@ MUST be used. 3.1.2. Transfer Encoding When generating any of the secured MIME entities below, except the signing using the multipart/signed format, no transfer encoding is required at all. S/MIME implementations MUST be able to deal with binary MIME objects. If no Content-Transfer-Encoding header field is present, the transfer encoding is presumed to be 7BIT. - S/MIME implementations SHOULD however use transfer encoding described - in Section 3.1.3 for all MIME entities they secure. The reason for - securing only 7-bit MIME entities, even for enveloped data that are - not exposed to the transport, is that it allows the MIME entity to be - handled in any environment without changing it. For example, a - trusted gateway might remove the envelope, but not the signature, of - a message, and then forward the signed message on to the end - recipient so that they can verify the signatures directly. If the - transport internal to the site is not 8-bit clean, such as on a wide- - area network with a single mail gateway, verifying the signature will - not be possible unless the original MIME entity was only 7-bit data. + As a rule, S/MIME implementations SHOULD use transfer encoding + described in Section 3.1.3 for all MIME entities they secure. The + reason for securing only 7-bit MIME entities, even for enveloped data + that is not exposed to the transport, is that it allows the MIME + entity to be handled in any environment without changing it. For + example, a trusted gateway might remove the envelope, but not the + signature, of a message, and then forward the signed message on to + the end recipient so that they can verify the signatures directly. + If the transport internal to the site is not 8-bit clean, such as on + a wide-area network with a single mail gateway, verifying the + signature will not be possible unless the original MIME entity was + only 7-bit data. - S/MIME implementations that "know" that all intended recipients are - capable of handling inner (all but the outermost) binary MIME objects - SHOULD use binary encoding as opposed to a 7-bit-safe transfer - encoding for the inner entities. The use of a 7-bit-safe encoding - (such as base64) would unnecessarily expand the message size. - Implementations MAY "know" that recipient implementations are capable - of handling inner binary MIME entities either by interpreting the id- - cap-preferBinaryInside SMIMECapabilities attribute, by prior - agreement, or by other means. + In the case where S/MIME implementations can determine that all + intended recipients are capable of handling inner (all but the + outermost) binary MIME objects SHOULD use binary encoding as opposed + to a 7-bit-safe transfer encoding for the inner entities. The use of + a 7-bit-safe encoding (such as base64) unnecessarily expands the + message size. Implementations MAY determine that recipient + implementations are capable of handling inner binary MIME entities + either by interpreting the id-cap-preferBinaryInside + SMIMECapabilities attribute, by prior agreement, or by other means. If one or more intended recipients are unable to handle inner binary MIME objects, or if this capability is unknown for any of the intended recipients, S/MIME implementations SHOULD use transfer encoding described in Section 3.1.3 for all MIME entities they secure. 3.1.3. Transfer Encoding for Signing Using multipart/signed If a multipart/signed entity is ever to be transmitted over the @@ -1060,21 +1060,21 @@ invalidate the signature. - The agent could transmit the data anyway, which would most likely result in the 8th bit being corrupted; this too would invalidate the signature. - The agent could return the message to the sender. [RFC1847] prohibits an agent from changing the transfer encoding of the first part of a multipart/signed message. If a compliant agent - that cannot transmit 8-bit or binary data encounters a + that cannot transmit 8-bit or binary data encountered a multipart/signed message with 8-bit or binary data in the first part, it would have to return the message to the sender as undeliverable. 3.1.4. Sample Canonical MIME Entity This example shows a multipart/mixed message with full transfer encoding. This message contains a text part and an attachment. The sample message text includes characters that are not ASCII and thus need to be transfer encoded. Though not shown here, the end of each line is . The line ending of the MIME headers, the text, and @@ -1148,21 +1148,22 @@ For the application/pkcs7-mime, sending agents SHOULD emit the optional "name" parameter to the Content-Type field for compatibility with older systems. Sending agents SHOULD also emit the optional Content-Disposition field [RFC2138] with the "filename" parameter. If a sending agent emits the above parameters, the value of the parameters SHOULD be a file name with the appropriate extension: Media Type File Extension - application/pkcs7-mime (SignedData, EnvelopedData) .p7m + application/pkcs7-mime (SignedData, EnvelopedData, .p7m + AuthEnvelopedData) application/pkcs7-mime (degenerate SignedData certificate .p7c management message) application/pkcs7-mime (CompressedData) .p7z application/pkcs7-signature (SignedData) .p7s In addition, the file name SHOULD be limited to eight characters followed by a three-letter extension. The eight-character filename base can be any distinct name; the use of the filename base "smime" SHOULD be used to indicate that the MIME entity is associated with S/MIME. @@ -1220,23 +1221,26 @@ "authEnveloped" or "enveloped" without having to tunnel into the CMS payload. A registry for additional smime-type parameter values has been defined in [RFC7114]. 3.3. Creating an Enveloped-Only Message This section describes the format for enveloping a MIME entity without signing it. It is important to note that sending enveloped - but not signed messages does not provide for data integrity. It is - possible to replace ciphertext in such a way that the processed - message will still be valid, but the meaning can be altered. + but not signed messages does not provide for data integrity. The + Enveloped-Only structure does not support authenticated symmetric + algorithms, use the .Authenticated Enveloped structure for these + algorithms. Thus, it is possible to replace ciphertext in such a way + that the processed message will still be valid, but the meaning can + be altered. Step 1. The MIME entity to be enveloped is prepared according to Section 3.1. Step 2. The MIME entity and other required data is processed into a CMS object of type EnvelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content-encryption key SHOULD be encrypted for the originator and included in the EnvelopedData (see [RFC5652], Section 6). @@ -1263,24 +1267,27 @@ bWx8+MDFbbpXadCDgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ip dSJuNnkVY4/M652jKKHRLFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBA gtaMXpRwZRNYAgDsiSf8Z9P43LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU= 3.4. Creating an Authenticated Enveloped-Only Message This section describes the format for enveloping a MIME entity without signing it. Authenticated enveloped messages provide confidentiality and data integrity. It is important to note that sending authenticated enveloped messages does not provide for - authentication when using S/MIME. It is possible to replace - ciphertext in such a way that the processed message will still be - valid, but the meaning can be altered. However this is substantially - more difficult than it is for an enveloped-only message as the + origination when using S/MIME. It is possible for a third party to + replace ciphertext in such a way that the processed message will + still be valid, but the meaning can be altered. However this is + substantially more difficult than it is for an enveloped-only message + as the algorithm does provide a level of authentication. Any + recipient for whom the message is encrypted can replace it without + detection. Step 1. The MIME entity to be enveloped is prepared according to Section 3.1. Step 2. The MIME entity and other required data is processed into a CMS object of type AuthEnvelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content-encryption key SHOULD be encrypted for the originator and included in the AuthEnvelopedData (see [RFC5083]). @@ -1473,21 +1480,21 @@ (Historical note: some early implementations of S/MIME emitted and expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.) Receiving agents SHOULD be able to recover gracefully from a micalg parameter value that they do not recognize. Future names for this parameter will be consistent with the IANA "Hash Function Textual Names" registry. 3.5.3.3. Sample multipart/signed Message Content-Type: multipart/signed; - micalg=SHA1; + micalg=sha-1; boundary="----=_NextBoundry____Fri,_06_Sep_2002_00:25:21"; protocol="application/pkcs7-signature" This is a multi-part message in MIME format. ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21 This is some sample content. ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21 Content-Type: application/pkcs7-signature; name=smime.p7s @@ -1868,27 +1875,29 @@ encrypt messages need to be cautious of cryptographic processing usage when validating signatures and encrypting messages using keys larger than those mandated in this specification. An attacker could send certificates with keys that would result in excessive cryptographic processing, for example, keys larger than those mandated in this specification, which could swamp the processing element. Agents that use such keys without first validating the certificate to a trust anchor are advised to have some sort of cryptographic resource management system to prevent such attacks. - Using weak cryptography in S/MIME offers little actual security over - sending plaintext. However, other features of S/MIME, such as the - specification of AES and the ability to announce stronger - cryptographic capabilities to parties with whom you communicate, - allow senders to create messages that use strong encryption. Using - weak cryptography is never recommended unless the only alternative is - no cryptography. + Some cryptographic algorithms such as RC2 offer little actual + security over sending plaintext. Other algorithms such as TripleDES, + provide security but are no longer considered to be state of the art. + S/MIME requires the use of current state of the art algorithms such + as AES and provides the ability to announce starter cryptographic + capabilities to parties with whom you communicate. This allows the + sender to create messages which can use the strongest common + encryption algorithm. Using algorithms such as RC2 is never + recommended unless the only alternative is no cryptography. RSA and DSA keys of less than 2048 bits are now considered by many experts to be cryptographically insecure (due to advances in computing power), and should no longer be used to protect messages. Such keys were previously considered secure, so processing previously received signed and encrypted mail will often result in the use of weak keys. Implementations that wish to support previous versions of S/MIME or process old messages need to consider the security risks that result from smaller key sizes (e.g., spoofed messages) versus the costs of denial of service. If an implementation supports @@ -1927,25 +1936,25 @@ If messaging environments make use of the fact that a message is signed to change the behavior of message processing (examples would be running rules or UI display hints), without first verifying that the message is actually signed and knowing the state of the signature, this can lead to incorrect handling of the message. Visual indicators on messages may need to have the signature validation code checked periodically if the indicator is supposed to give information on the current status of a message. Many people assume that the use of an authenticated encryption - algorithm is all that is needed to be in a situtation where the - sender of the message will be authenticated. In almost all cases - this is not a correct statement. There are a number of preconditions - that need to hold for an authenticated encryption algorithm to - provide this service: + algorithm is all that is needed to be in a situation where the sender + of the message will be authenticated. In almost all cases this is + not a correct statement. There are a number of preconditions that + need to hold for an authenticated encryption algorithm to provide + this service: - The starting key must be bound to a single entity. The use of a group key only would allow for the statement that a message was sent by one of the entities that held the key but will not identify a specific entity. - The message must have exactly one sender and one recipient. Having more than one recipient would allow for the second recipient to create a message that the first recipient would believe is from the sender by stripping them as a recipient from @@ -1981,173 +1990,181 @@ All of the authenticated encryption algorithms in this document use counter mode for the encryption portion of the algorithm. This means that the length of the plain text will always be known as the cipher text length and the plain text length are always the same. This information can enable passive observers to infer information based solely on the length of the message. Applications for which this is a concern need to provide some type of padding so that the length of the message does not provide this information. + When compression is used with encryption, it has the potential to add + an additional layer of security. However, care needs to be taken + when designing a protocol that relies on this not to create a + compression oracle. Compression oracle attacks require an adaptive + input to the process and attack the unknown content of a message + based on the length of the compressed output, this means that no + attack on the encryption key is necessarily required. + 7. References 7.1. Normative References [ASN.1] "Information Technology - Abstract Syntax Notation (ASN.1)". ASN.1 syntax consists of the following references [X.680], [X.681], [X.682], and [X.683]. [CHARSETS] "Character sets assigned by IANA.", . - [CMS] "Cryptograhic Message Syntax". + [CMS] "Cryptographic Message Syntax". This is the set of documents dealing with the cryptographic message syntax and refers to [RFC5652] and [RFC5083]. [ESS] "Enhanced Security Services for S/MIME". - This is the set of documents dealing with enhanged + This is the set of documents dealing with enhanced security services and refers to [RFC2634] and [RFC5035]. [FIPS186-4] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186-4, July 2013. [I-D.ietf-curdle-cms-ecdh-new-curves] - Housley, R., "Use of the Elliptic Curve Diffie-Hellamn Key + Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)", draft-ietf-curdle- - cms-ecdh-new-curves-02 (work in progress), March 2017. + cms-ecdh-new-curves-10 (work in progress), August 2017. [I-D.ietf-lamps-rfc5750-bis] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/ MIME) Version - 4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-03 - (work in progress), March 2017. + 4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-04 + (work in progress), April 2017. [MIME-SPEC] "MIME Message Specifications". This is the set of documents that define how to use MIME. This set of documents is [RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288], and [RFC4289]. [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, - October 1995, . + October 1995, . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, - . + . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, - . + . [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, November 1996, - . + . [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996, - . + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, - . + . [RFC2138] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, DOI 10.17487/RFC2138, April 1997, - . + . [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, DOI 10.17487/RFC2634, June 1999, - . + . [RFC3274] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, DOI 10.17487/RFC3274, June 2002, - . + . [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, - . + . [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)", RFC 3560, DOI 10.17487/RFC3560, July 2003, - . + . [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, - . + . [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, DOI 10.17487/RFC4056, June 2005, - . + . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, - . + . [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", RFC 4288, DOI 10.17487/RFC4288, - December 2005, . + December 2005, . [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005, - . + . [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, DOI 10.17487/RFC5035, August 2007, - . + . [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, November 2007, - . + . [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, DOI 10.17487/RFC5084, November 2007, - . + . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, - . + . [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January - 2010, . + 2010, . [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January - 2010, . + 2010, . [SMIMEv4.0] "S/MIME version 4.0". This group of documents represents S/MIME version 4.0. This set of documents are [RFC2634], [I-D.ietf-lamps-rfc5750-bis], [[This Document]], [RFC5652], and [RFC5035]. [X.680] "Information Technology - Abstract Syntax Notation One @@ -2157,154 +2174,154 @@ [X.681] "Information Technology - Abstract Syntax Notation One (ASN.1): Information object specification", ITU-T X.681, ISO/IEC 8824-2:2008, November 2008. [X.682] "Information Technology - Abstract Syntax Notation One (ASN.1): Constraint specification", ITU-T X.682, ISO/ IEC 8824-3:2008, November 2008. [X.683] "Information Technology - Abstract Syntax Notation One - (ASN.1): Parameteriztion of ASN.1 specifications", + (ASN.1): Parameterization of ASN.1 specifications", ITU-T X.683, ISO/IEC 8824-4:2008, November 2008. [X.690] "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).", ITU-T X.690, ISO/IEC 8825-1:2002, July 2002. 7.2. Informative References [FIPS186-2] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS) [With Change Notice 1]", Federal Information Processing Standards Publication 186-2, January 2000. [RFC2268] Rivest, R., "A Description of the RC2(r) Encryption Algorithm", RFC 2268, DOI 10.17487/RFC2268, March 1998, - . + . [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, DOI 10.17487/RFC2311, March 1998, - . + . [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, "S/MIME Version 2 Certificate Handling", RFC 2312, DOI 10.17487/RFC2312, March 1998, - . + . [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, DOI 10.17487/RFC2313, March 1998, - . + . [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998, - . + . [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, - . + . [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, DOI 10.17487/RFC2630, June 1999, - . + . [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, DOI 10.17487/RFC2631, June 1999, - . + . [RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate Handling", RFC 2632, DOI 10.17487/RFC2632, June 1999, - . + . [RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999, - . + . [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" - Attacks on the Diffie-Hellman Key Agreement Method for S/ - MIME", RFC 2785, DOI 10.17487/RFC2785, March 2000, - . + Attacks on the Diffie-Hellman Key Agreement Method for + S/MIME", RFC 2785, DOI 10.17487/RFC2785, March 2000, + . [RFC3218] Rescorla, E., "Preventing the Million Message Attack on Cryptographic Message Syntax", RFC 3218, DOI 10.17487/RFC3218, January 2002, - . + . [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, DOI 10.17487/RFC3766, April 2004, - . + . [RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, DOI 10.17487/RFC3850, July 2004, - . + . [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, DOI 10.17487/RFC3851, July 2004, - . + . [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, DOI 10.17487/RFC3852, July 2004, - . + . [RFC4134] Hoffman, P., Ed., "Examples of S/MIME Messages", RFC 4134, DOI 10.17487/RFC4134, July 2005, - . + . [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, DOI 10.17487/RFC4270, November 2005, - . + . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, - . + . [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, - . + . [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January - 2010, . + 2010, . [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, - . + . [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, - . + . [RFC6278] Herzog, J. and R. Khazan, "Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax", RFC 6278, DOI 10.17487/RFC6278, June - 2011, . + 2011, . [RFC7114] Leiba, B., "Creation of a Registry for smime-type Parameter Values", RFC 7114, DOI 10.17487/RFC7114, January - 2014, . + 2014, . [RFC7905] Langley, A., Chang, W., Mavrogiannopoulos, N., Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)", RFC 7905, DOI 10.17487/RFC7905, June 2016, - . + . [SMIMEv2] "S/MIME version v2". This group of documents represents S/MIME version 2. This set of documents are [RFC2311], [RFC2312], [RFC2313], [RFC2314], and [RFC2315]. [SMIMEv3] "S/MIME version 3". This group of documents represents S/MIME version 3. This @@ -2443,33 +2460,33 @@ This appendix contains a number of references to documents that have been obsoleted or replaced, this is intentional as frequently the updated documents do not have the same information in them. B.1. DigestAlgorithmIdentifier The following algorithms have been called our for some level of support by previous S/MIME specifications: - - SHA-1 was dropped in [SMIMEv4.0]. SHA-1 is no longer considerd to - be secure as it is no longer collision-resistant. The IETF + - SHA-1 was dropped in [SMIMEv4.0]. SHA-1 is no longer considered + to be secure as it is no longer collision-resistant. The IETF statement on SHA-1 can be found in [RFC6194] but it is out-of-date - relative to the most recient advances. + relative to the most recent advances. - MD5 was dropped in [SMIMEv4.0]. MD5 is no longer considered to be secure as it is no longer collision-resistant. Details can be found in [RFC6151]. B.2. Signature Algorithms There are a number of problems with validating signatures on - sufficently historic messages. For this reason it is strongly + sufficiently historic messages. For this reason it is strongly suggested that UAs treat these signatures differently from those on current messages. These problems include: - CAs are not required to keep certificates on a CRL beyond one update after a certificate has expired. This means that unless CRLs are cached as part of the message it is not always possible to check if a certificate has been revoked. The same problems exist with OCSP responses as they may be based on a CRL rather than on the certificate database. @@ -2483,60 +2500,62 @@ messages) versus the costs of denial of service. [SMIMEv3.1] set the lower limit on suggested key sizes for creating and validation at 1024 bits. Prior to that the lower bound on key sizes was 512 bits. - Hash functions used to validate signatures on historic messages may longer be considered to be secure. (See below.) While there are not currently any known practical pre-image or second pre- image attacks against MD5 or SHA-1, the fact they are no longer - considered to be collision resistent the security levels of the - signatures are generally considered suspect. + considered to be collision resistant the security levels of the + signatures are generally considered suspect. If a message is + known to be historic, that it it has been in the possession of the + client for some time, then it might still be considered to be + secure. - The previous two issues apply to the certificates used to validate the binding of the public key to the identity that signed the message as well. The following algorithms have been called out for some level of support by previous S/MIME specifications: - RSA with MD5 was dropped in [SMIMEv4.0]. MD5 is no longer considered to be secure as it is no longer collision-resistant. Details can be found in [RFC6151]. - RSA and DSA with SHA-1 were dropped in [SMIMEv4.0]. SHA-1 is no longer considered to be secure as it is no longer collision- - resistant. The IETF statment on SHA-1 can be found in [RFC6194] + resistant. The IETF statement on SHA-1 can be found in [RFC6194] but it is out-of-date relative to the most recent advances. - DSA with SHA-256 was dropped in [SMIMEv4.0]. DSA has been replaced by elliptic curve versions. - As requirements for manditory to implement has changed over time, - some issues have been created that can cause interopatability + As requirements for mandatory to implement has changed over time, + some issues have been created that can cause interoperability problems: - S/MIME v2 clients are only required to verify digital signatures using the rsaEncryption algorithm with SHA-1 or MD5, and might not implement id-dsa-with-sha1 or id-dsa at all. - S/MIME v3 clients might only implement signing or signature verification using id-dsa-with-sha1, and might also use id-dsa as an AlgorithmIdentifier in this field. - Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 and rsaEncryption and might not implement sha256withRSAEncryption. NOTE: Receiving clients SHOULD recognize id-dsa as equivalent to id- - dsa-with-sha1, and sending clients MUST use id-dsa-with-sha1 if using - that algorithm. + dsa-with-sha1. For 512-bit RSA with SHA-1 see [RFC3370] and [FIPS186-2] without Change Notice 1, for 512-bit RSA with SHA-256 see [RFC5754] and [FIPS186-2] without Change Notice 1, and for 1024-bit through 2048-bit RSA with SHA-256 see [RFC5754] and [FIPS186-2] with Change Notice 1. The first reference provides the signature algorithm's object identifier, and the second provides the signature algorithm's definition. For 512-bit DSA with SHA-1 see [RFC3370] and [FIPS186-2] without