--- 1/draft-ietf-lamps-rfc5751-bis-07.txt 2018-05-02 12:14:10.765335769 -0700 +++ 2/draft-ietf-lamps-rfc5751-bis-08.txt 2018-05-02 12:14:10.873338378 -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 15, 2018 S. Turner +Expires: November 3, 2018 S. Turner sn3rd - April 13, 2018 + May 2, 2018 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification - draft-ietf-lamps-rfc5751-bis-07 + draft-ietf-lamps-rfc5751-bis-08 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. @@ -36,21 +36,21 @@ 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 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 15, 2018. + This Internet-Draft will expire on November 3, 2018. Copyright Notice 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -75,45 +75,45 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 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.4.5. CompressedData Content Type . . . . . . . . . . . . . 13 2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 13 - 2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 13 + 2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 14 2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 14 - 2.5.3. Encryption Key Preference Attribute . . . . . . . . . 15 + 2.5.3. Encryption Key Preference Attribute . . . . . . . . . 16 2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 17 2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 17 2.7.1. Deciding Which Encryption Method to Use . . . . . . . 17 2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 19 2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 19 3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 19 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.3. Transfer Encoding for Signing Using multipart/signed 23 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 . . . . 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 @@ -129,56 +129,60 @@ 4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 38 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 38 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 + Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 52 + Appendix B. Historic Mail Considerations . . . . . . . . . . . . 54 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 + Status . . . . . . . . . . . . . . . . . . . . . . . 57 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 1. Introduction S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures), and data confidentiality (using - encryption). As a supplementary service, S/MIME provides for message + encryption). As a supplementary service, S/MIME provides message compression. S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP or SIP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems. Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet. + This document defines the version 4.0 of the S/MIME Message + specification. As such this document obsoletes version 3.2 of the + S/MIME Message specification [RFC5751]. + 1.1. Specification Overview This document describes a protocol for adding cryptographic signature and encryption services to MIME data. The MIME standard [MIME-SPEC] provides a general structure for the content of Internet messages and allows extensions for new content-type-based applications. This specification defines how to create a MIME body part that has been cryptographically enhanced according to the Cryptographic Message Syntax (CMS) [CMS], which is derived from PKCS #7 [RFC2315]. @@ -264,62 +268,64 @@ unauthorized changes to data by ensuring that changes to the data are detectable. [RFC4949] Data Confidentiality: The property that data is not disclosed to system entities unless they have been authorized to know the data. [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]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. 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 promoted at some future time to be a MUST. SHOULD- This term means the same as SHOULD. However, the authors expect that a requirement marked as SHOULD- will be demoted to a MAY in a future version of this document. MUST- This term means the same as MUST. However, the authors expect that this requirement will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST- requirement, it will remain at least a SHOULD or a SHOULD-. The term RSA in this document almost always refers to the PKCS#1 v1.5 - RSA signature or encryption algorithms even when not qualified as - such. There are a couple of places where it refers to the general - RSA cryptographic operation, these can be determined from the context - where it is used. + RSA [RFC2313] signature or encryption algorithms even when not + qualified as such. There are a couple of places where it refers to + the general RSA cryptographic operation, these can be determined from + the context where it is used. 1.4. Compatibility with Prior Practice of S/MIME S/MIME version 4.0 agents ought to attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive and RFC 5035 [SMIMEv3], S/MIME version 3.1 is described in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1], and S/MIME version 3.2 is described in [SMIMEv3.2]. [RFC2311] also has historical information about the development of S/MIME. 1.5. Changes from S/MIME v3 to S/MIME v3.1 - The RSA public key algorithm was changed to a MUST implement key - wrapping algorithm, and the Diffie-Hellman (DH) algorithm changed to - a SHOULD implement. + The RSA public key algorithm was changed to a MUST implement, key + wrap algorithm, and the Diffie-Hellman (DH) algorithm [RFC2631] + changed to a SHOULD implement. The AES symmetric encryption algorithm has been included as a SHOULD implement. The RSA public key algorithm was changed to a MUST implement signature algorithm. Ambiguous language about the use of "empty" SignedData messages to transmit certificates was clarified to reflect that transmission of Certificate Revocation Lists is also allowed. @@ -405,22 +411,22 @@ 1.7. Changes for S/MIME v4.0 - Add the use of AuthEnvelopedData, including defining and registering an smime-type value (Section 2.4.4 and Section 3.4). - Update the content encryption algorithms (Section 2.7 and Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove AES-192 CBC, mark tripleDES as historic. - - Update the set of signature algorithms (Section 2.2): Add EdDSA - and ECDSA, mark DSA as historic + - Update the set of signature algorithms (Section 2.2): Add Edwards- + curve DSA (EdDSA) and ECDSA, mark DSA as historic - Update the set of digest algorithms (Section 2.1): Add SHA-512, mark SHA-1 as historic. - Update the size of keys to be used for RSA encryption and RSA signing (Section 4). - Create Appendix B which deals with considerations for dealing with historic email messages. @@ -456,46 +462,47 @@ 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 EdDSA with curve 25519 using Pure EdDSA mode + [I-D.ietf-curdle-cms-eddsa-signatures]. - MUST- support RSA PKCS#1 v1.5 with SHA-256. - - SHOULD support RSASSA-PSS with SHA-256. + - . SHOULD support RSASSA-PSS with SHA-256. 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 PKCS#1 v1.5 with SHA-256. - SHOULD support RSASSA-PSS with SHA-256. 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 + used to create their standardized curves; this means that there is a 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 receiving - agent list, but there is only a requirement for curve in the sending - agent list. This requirement makes sure that maximum + agent list, but there is only a requirement for one curve in the + sending 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]. @@ -509,21 +516,23 @@ - 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-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. + be supported when ECDH ephemeral-static is used. Recipients MAY + enforce this, but MUST use the weaker of the two as part of any + cryptographic strength computation it might do. 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 content types are currently used for S/MIME. @@ -546,44 +555,50 @@ Sending agents MUST use the SignedData content type to apply a digital signature to a message or, in a degenerate case where there is no signature information, to convey certificates. Applying a signature to a message provides authentication, message integrity, and non-repudiation of origin. 2.4.3. EnvelopedData Content Type This content type is used to apply data confidentiality to a message. - A sender needs to have access to a public key for each intended - message recipient to use this service. + In order to distribute the symmetric key, a sender needs to have + access to a public key for each intended message recipient to use + this service. 2.4.4. AuthEnvelopedData Content Type This content type is used to apply data confidentiality and message integrity to a message. This content type does not provide - authentication or non-repudiation. A sender needs to have access to - a public key for each intended message recipient to use this service. + authentication or non-repudiation. In order to distribute the + symmetric key, a sender needs to have access to a public key for each + intended message recipient to use this service. 2.4.5. CompressedData Content Type This content type is used to apply data compression to a message. This content type does not provide authentication, message integrity, non-repudiation, or data confidentiality, and is only used to reduce the message's size. See Section 3.7 for further guidance on the use of this type in conjunction with other CMS types. 2.5. Attributes and the SignerInfo Type The SignerInfo type allows the inclusion of unsigned and signed - attributes along with a signature. + attributes along with a signature. These attributes can be required + for processing of message (i.e. Message Digest), information the + signer supplied (i.e. SMIME Capabilities) that should be processed, + or attributes which are not relevant in the current situation (i.e. + mlExpansionList [RFC2634] for mail viewers). Receiving agents MUST be able to handle zero or one instance of each of the signed attributes listed here. Sending agents SHOULD generate one instance of each of the following signed attributes in each S/MIME message: - Signing Time (Section 2.5.1 in this document) - SMIME Capabilities (Section 2.5.2 in this document) @@ -607,22 +622,21 @@ values that they do not recognize in a graceful manner. Interactive sending agents that include signed attributes that are not listed here SHOULD display those attributes to the user, so that the user is aware of all of the data being signed. 2.5.1. Signing Time Attribute The signing-time attribute is used to convey the time that a message was signed. The time of signing will most likely be created by a - message originator and therefore is only as trustworthy as the - originator. + signer and therefore is only as trustworthy as that signer. Sending agents MUST encode signing time through the year 2049 as UTCTime; signing times in 2050 or later MUST be encoded as GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST interpret the year field (YY) as follows: If YY is greater than or equal to 50, the year is interpreted as 19YY; if YY is less than 50, the year is interpreted as 20YY. Receiving agents MUST be able to process signing-time attributes that @@ -854,26 +868,29 @@ 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, 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. + Algorithms such as RC2 are considered to be weak encryption + algorithms. Algorithms such as TripleDES are not state of the art + and are considered to be weaker algorithms than AES. A sending agent + that is controlled by a human SHOULD allow a human sender to + determine the risks of sending data using a weaker encryption + algorithm before sending the data, and possibly allow the human to + use a stronger encryption algorithm such as AES GCM or AES CBC even + if there is a possibility that the recipient will not be able to + process that algorithm. 2.7.3. Multiple Recipients If a sending agent is composing an encrypted message to a group of recipients where the encryption capabilities of some of the recipients do not overlap, the sending agent is forced to send more than one message. Please note that if the sending agent chooses to send a message encrypted with a strong algorithm, and then send the same message encrypted with a weak algorithm, someone watching the communications channel could learn the contents of the strongly @@ -1142,21 +1159,21 @@ agent to decode the ASN.1 for the object. The Content-Type header field of all application/pkcs7-mime objects SHOULD include the optional "smime-type" parameter, as described in the following sections. 3.2.1. The name and filename Parameters 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. + Content-Disposition field [RFC2183] 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 AuthEnvelopedData) application/pkcs7-mime (degenerate SignedData certificate .p7c management message) application/pkcs7-mime (CompressedData) .p7z @@ -1266,23 +1283,23 @@ iJi2lsGPcP2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eC 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 - origination when using S/MIME. It is possible for a third party to - replace ciphertext in such a way that the processed message will + sending authenticated enveloped messages does not provide for proof + of 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 @@ -2034,32 +2051,37 @@ 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-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)", draft-ietf-curdle- cms-ecdh-new-curves-10 (work in progress), August 2017. + [I-D.ietf-curdle-cms-eddsa-signatures] + Housley, R., "Use of EdDSA Signatures in the Cryptographic + Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa- + signatures-08 (work in progress), October 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-04 - (work in progress), April 2017. + 4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-05 + (work in progress), April 2018. [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]. + [RFC2049], [RFC6838], 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, . [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, . @@ -2077,24 +2099,25 @@ [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, - . + [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating + Presentation Information in Internet Messages: The + Content-Disposition Header Field", RFC 2183, + DOI 10.17487/RFC2183, August 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, . @@ -2115,24 +2138,20 @@ [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, . - [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, . @@ -2152,25 +2171,35 @@ [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, . [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, . + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + [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 (ASN.1): Specification of basic notation. ITU-T Recommendation X.680 (2002)", ITU-T X.680, ISO/ IEC 8824-1:2008, November 2008. [X.681] "Information Technology - Abstract Syntax Notation One (ASN.1): Information object specification", ITU-T X.681,