--- 1/draft-ietf-lamps-rfc5751-bis-04.txt 2017-04-07 16:14:02.793797473 -0700 +++ 2/draft-ietf-lamps-rfc5751-bis-05.txt 2017-04-07 16:14:02.901800062 -0700 @@ -1,22 +1,22 @@ LAMPS J. Schaad Internet-Draft August Cellars -Obsoletes: RFC5751 (if approved) B. Ramsdell +Obsoletes: 5751 (if approved) B. Ramsdell Intended status: Standards Track Brute Squad Labs, Inc. -Expires: September 14, 2017 S. Turner +Expires: October 9, 2017 S. Turner sn3rd - March 13, 2017 + April 7, 2017 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification - draft-ietf-lamps-rfc5751-bis-04 + draft-ietf-lamps-rfc5751-bis-05 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 http://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 September 14, 2017. + This Internet-Draft will expire on October 9, 2017. Copyright Notice Copyright (c) 2017 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 publication of this document. Please review these documents @@ -125,24 +125,25 @@ 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 36 4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 37 4.2. Signature Generation . . . . . . . . . . . . . . . . . . 37 4.3. Signature Verification . . . . . . . . . . . . . . . . . 37 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 + 6. IANA Considertions . . . . . . . . . . . . . . . . . . . . . 40 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 44 + 8.2. Informative References . . . . . . . . . . . . . . . . . 48 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 51 Appendix B. Historic Mail Considerations . . . . . . . . . . . . 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 @@ -391,21 +392,21 @@ 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. - Section 6: Updated security considerations. + Section 7: Updated security considerations. Section 7: Moved references from Appendix B to this section. Updated references. Added informational references to SMIMEv2, SMIMEv3, and SMIMEv3.1. Appendix C: Added Appendix C to move S/MIME v2 to Historic status. 1.7. Changes for S/MIME v4.0 - Add the use of AuthEnvelopedData, including defining and @@ -1449,23 +1450,23 @@ The protocol parameter MUST be "application/pkcs7-signature". Note that quotation marks are required around the protocol parameter because MIME requires that the "/" character in the parameter value MUST be quoted. The micalg parameter allows for one-pass processing when the signature is being verified. The value of the micalg parameter is dependent on the message digest algorithm(s) used in the calculation of the Message Integrity Check. If multiple message digest - algorithms are used, they MUST be separated by commas per [MIME- - SECURE]. The values to be placed in the micalg parameter SHOULD be - from the following: + algorithms are used, they MUST be separated by commas per [RFC1847]. + The values to be placed in the micalg parameter SHOULD be from the + following: Algorithm Value Used MD5 md5 SHA-1 sha-1 SHA-224 sha-224 SHA-256 sha-256 SHA-384 sha-384 SHA-512 sha-512 Any other (defined separately in algorithm profile or "unknown" if not defined) @@ -1816,21 +1817,25 @@ 5.3. Register authEnveloped-data smime-type IANA is required to register the following value in the "Parameter Values for the smime-type Parameter" registry. The values to be registered are: smime-type value: authEnveloped-data Reference: [[This Document, Section 3.2.2]] -6. Security Considerations +6. IANA Considertions + + This document has no new IANA considerations. + +7. Security Considerations Cryptographic algorithms will be broken or weakened over time. Implementers and users need to check that the cryptographic algorithms listed in this document continue to provide the expected level of security. The IETF from time to time may issue documents dealing with the current state of the art. For example: - The Million Message Attack described in RFC 3218 [RFC3218]. - The Diffie-Hellman "small-subgroup" attacks described in RFC 2785 @@ -1981,23 +1986,23 @@ 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. -7. References +8. References -7.1. Normative References +8.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.", . @@ -2015,32 +2020,27 @@ [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 Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)", draft-ietf-curdle- - cms-ecdh-new-curves-01 (work in progress), September 2016. - - [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-03 (work in progress), January 2017. + cms-ecdh-new-curves-02 (work in progress), March 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-02 - (work in progress), February 2017. + 4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-03 + (work in progress), March 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 @@ -2170,21 +2170,21 @@ [X.683] "Information Technology - Abstract Syntax Notation One (ASN.1): Parameteriztion 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 +8.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, . @@ -2408,22 +2407,22 @@ id-cap OBJECT IDENTIFIER ::= { id-smime 11 } -- The preferBinaryInside OID indicates an ability to receive -- messages with binary encoding inside the CMS wrapper. -- The preferBinaryInside attribute's value field is ABSENT. id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 } -- The following list OIDs to be used with S/MIME V3 - -- Signature Algorithms Not Found in [CMSALG], [CMS-SHA2], [RSAPSS], - -- and [RSAOAEP] + -- Signature Algorithms Not Found in [RFC3370], [RFC5754], [RFC4056], + -- and [RFC3560] -- -- md2WithRSAEncryption OBJECT IDENTIFIER ::= -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) -- 2} -- -- Other Signed Attributes -- -- signingTime OBJECT IDENTIFIER ::=