--- 1/draft-ietf-lamps-rfc5751-bis-09.txt 2018-06-19 19:13:18.317048294 -0700 +++ 2/draft-ietf-lamps-rfc5751-bis-10.txt 2018-06-19 19:13:18.433051070 -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: November 23, 2018 S. Turner +Expires: December 21, 2018 S. Turner sn3rd - May 22, 2018 + June 19, 2018 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification - draft-ietf-lamps-rfc5751-bis-09 + draft-ietf-lamps-rfc5751-bis-10 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 November 23, 2018. + This Internet-Draft will expire on December 21, 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 @@ -100,21 +100,21 @@ 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 23 - 3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 23 + 3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 24 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 3.6. Creating a Compressed-Only Message . . . . . . . . . . . 34 @@ -915,28 +915,31 @@ for signed-only data, and several formats for signed and enveloped data. Several formats are required to accommodate several environments, in particular for signed messages. The criteria for choosing among these formats are also described. The reader of this section is expected to understand MIME as described in [MIME-SPEC] and [RFC1847]. 3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing - S/MIME is used to secure MIME entities. A MIME entity can be a sub- - part, sub-parts of a message, or the whole message with all its sub- - parts. A MIME entity that is the whole message includes only the - MIME message headers and MIME body, and does not include the RFC-822 - header. Note that S/MIME can also be used to secure MIME entities - used in applications other than Internet mail. If protection of the - RFC-822 header is required, the use of the message/rfc822 media type - is explained later in this section. + S/MIME is used to secure MIME entities. A MIME message is composed + of a MIME header and a MIME body, the body can consist of a single + part or of multiple parts. Any of these parts is designated as a + MIME message part. A MIME entity can be a sub-part, sub-parts of a + MIME message, or the whole MIME message with all of its sub-parts. A + MIME entity that is the whole message includes only the MIME message + headers and MIME body, and does not include the RFC-822 header. Note + that S/MIME can also be used to secure MIME entities used in + applications other than Internet mail. If protection of the RFC-822 + header is required, the use of the message/rfc822 media type is + explained later in this section. The MIME entity that is secured and described in this section can be thought of as the "inside" MIME entity. That is, it is the "innermost" object in what is possibly a larger MIME message. Processing "outside" MIME entities into CMS content types is described in Section 3.2, Section 3.5, and elsewhere. The procedure for preparing a MIME entity is given in [MIME-SPEC]. The same procedure is used here with some additional restrictions when signing. The description of the procedures from [MIME-SPEC] is