Network
LAMPS Working Group                                         B. Hoeneisen
Internet-Draft                                            pEp Foundation
Intended status: Informational                               A. Melnikov Standards Track                              D. Gillmor
Expires: January 14, May 6, 2021                      American Civil Liberties Union
                                                             A. Melnikov
                                                               Isode Ltd
                                                           July 13,
                                                       November 02, 2020

                      Header Protection for S/MIME
                 draft-ietf-lamps-header-protection-00
                 draft-ietf-lamps-header-protection-01

Abstract

   Privacy and security

   S/MIME version 3.1 has introduced a feasible standardized option to
   accomplish Header Protection.  However, implementations of Header
   Protection can cause rendering issues on the receiving side.  Clearer
   specifications regarding message processing, particularly with email
   respect to header protection sections, are needed in S/MIME
   have been identified for some time.  However, the desire order to fix resolve these
   issues has only recently been expressed in the IETF LAMPS Working
   Group.  The existing S/MIME specification is
   rendering issues.

   In order to be updated regarding
   header protection.

   This document describes the problem statement, generic use cases, help implementers to correctly compose and
   the render email
   messages with Header Protection, this document updates S/MIME specification for header protection. Header
   Protection specifications with additional guidance on MIME format,
   sender and receiver processing.

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 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 January 14, May 6, 2021.

Copyright Notice

   Copyright (c) 2020 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
   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Other Protocols to Protect Email Headers  . . . . . . . .   4
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     1.2.
     1.3.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   4   5
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6   7
     2.1.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .   6   7
     2.2.  Security  . . . . . . . . . . . . . . . . . . . . . . . .   6   8
     2.3.  Usability . . . . . . . . . . . . . . . . . . . . . . . .   6   8
     2.4.  Interoperability  . . . . . . . . . . . . . . . . . . . .   7   8
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   7   8
     3.1.  Interactions  . . . . . . . . . . . . . . . . . . . . . .   7   8
       3.1.1.  Main Use Case . . . . . . . . . . . . . . . . . . . .   7   8
       3.1.2.  Backward Compatibility Use Cases  . . . . . . . . . .   7   8
     3.2.  Protection Levels . . . . . . . . . . . . . . . . . . . .   9
   4.  Specification . . . .  10
       3.2.1.  In-Scope  . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Main Use Case . .  10
       3.2.2.  Out-of-Scope  . . . . . . . . . . . . . . . . . . . .  10
       4.1.1.  MIME Format . . . . . .
   4.  Specification . . . . . . . . . . . . . . .  10
       4.1.2.  Inner Message Header Fields . . . . . . . . .  10
     4.1.  Main Use Case . . . .  15
       4.1.3.  Wrapper . . . . . . . . . . . . . . . . . .  11
       4.1.1.  MIME Format . . . . .  16
       4.1.4.  Outer Message Header Fields . . . . . . . . . . . . .  16
       4.1.5.  Receiving User Facing Message Header Fields . . .  11
       4.1.2.  Sending Side  . .  18
       4.1.6.  Header Field Flow . . . . . . . . . . . . . . . . . .  18
       4.1.7.  Sending  14
       4.1.3.  Receiving Side Message Processing .  . . . . . . . . . .  20
       4.1.8.  Receiving Side Message Processing . . . . . . . . . .  21  18
     4.2.  Backward Compatibility Use Cases  . . . . . . . . . . . .  21  18
       4.2.1.  Receiving Side MIME-Conformant  . . . . . . . . . . .  21  18
       4.2.2.  Receiving Side Not MIME-Conformant  . . . . . . . . .  22  19
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  22  19
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  23  19
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23  19
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  23  19
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23  20
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  23  20
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  24  21
   Appendix A.  Additional information . . . . . . . . . . . . . . .  25  22
     A.1.  Stored Variants of Messages with Bcc  . . . . . . . . . .  25  22
   Appendix B.  Document Changelog  Text Moved from Above  . . . . . . . . . . . . . . .  22
     B.1.  MIME Format . .  26
   Appendix C.  Open Issues . . . . . . . . . . . . . . . . . . . .  26
   Authors' Addresses .  23
       B.1.1.  S/MIME Specification  . . . . . . . . . . . . . . . .  23

   Appendix C.  Document Changelog . . . . . .  27

1.  Introduction

   A range of protocols for the protection of electronic mail (email)
   exists, which allows to assess the authenticity . . . . . . . . . . .  25
   Appendix D.  Open Issues  . . . . . . . . . . . . . . . . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

1.  Introduction

   Privacy and integrity of the security issues regarding email headers section or selected header fields (HF) from the domain-
   level perspective, specifically DomainKeys Identified Mail (DKIM)
   [RFC6376] and Sender Policy Framework (SPF) [RFC7208], and Domain-
   based Message Authentication, Reporting, and Conformance (DMARC)
   [RFC7489].  These protocols, while essential to responding to a range Header Protection in
   S/MIME have been identified for some time.  Most current
   implementations of attacks on email, do not offer (full) end-to-end protection to cryptographically-protected electronic mail
   protect only the
   header section and are not capable body of providing privacy for the
   information contained therein.

   The need message, which leaves significant room
   for means attacks against otherwise-protected messages.  For example, lack
   of Data Minimization, which includes data
   sparseness and hiding all technically concealable information
   whenever possible, has grown in importance over header protection allows an attacker to substitute the past several
   years. message
   subject and/or author.

   A standard for way to provide end-to-end protection of for the Header Section of an
   email header section
   exists message has been standardized for S/MIME version 3.1 and later. later
   (cf.  [RFC8551]):

      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.

   No mechanism for header protection (HP) has been standardized for
   PGP/MIME (Pretty Good Privacy) [RFC3156] yet.

   Several varying

   Unfortunately, implementations of end-to-end protections for email
   header sections exist, though the total number of such
   implementations appears to be rather low.

   Some LAMPS WG participants expressed Header Protection can cause
   rendering issues on the opinion that regardless of receiving side.  In some cases, the mechanism chosen, it user sees
   an attachment suggesting a forwarded email message, which - in fact -
   contains the protected email message that should not be limited rendered
   directly.  For these cases, the user can click on the attachment to S/MIME, but
   view the protected message.  However, there have also been reports of
   email clients displaying garbled text, or sometimes nothing at all.
   In those cases the email clients on the receiving side are (most
   likely) not fully MIME-capable.

   The following shortcomings have been identified to cause these
   issues:

   o  Broken or incomplete implementations

   o  Lack of a simple means to distinguish "forwarded message" and
      "wrapped message" (for the sake of Header Protection)

   o  Not enough guidance with respect to handling of Header Fields on
      both the sending and the receiving side

   Furthermore, the need (technical) Data Minimization, which includes
   data sparseness and hiding all technically concealable information,
   has grown in importance over the past several years.  In addition,
   backwards compatibility must be considered when it is possible to do
   so without compromising privacy and security.

   No mechanism for Header Protection has been standardized for PGP/MIME
   (Pretty Good Privacy) [RFC3156] yet.  PGP/MIME developers have
   implemented ad-hoc header-protection, and would like to see a
   specification that is applicable to both S/MIME and PGP/MIME.

   This document describes the problem statement (Section 2), generic
   use cases (Section 3) and the specification for Header Protection
   (Section 4). 4) with guidance on MIME format, sender and receiver
   processing .

   [I-D.ietf-lamps-header-protection-requirements] defines the
   requirements that this specification is based on.

   This document is in an early draft state and contains a proposal on
   which to base future discussions of this topic.  In any case, the
   final mechanism is to be determined by the IETF LAMPS WG.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are  Other Protocols to be interpreted as described in [RFC2119].

1.2.  Terms

   The following terms are defined Protect Email Headers

   A range of protocols for the scope of this document:

   o  Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A
      form protection of active wiretapping attack in electronic mail (email)
   exists, which allows one to assess the attacker intercepts authenticity and selectively modifies communicated data to masquerade as one or
      more integrity of
   the entities email headers section or selected Header Fields from the domain-
   level perspective, specifically DomainKeys Identified Mail (DKIM)
   [RFC6376], as used by Domain-based Message Authentication, Reporting,
   and Conformance (DMARC) [RFC7489].  These protocols provide a domain-
   based reputation mechanism that can be used to mitigate some forms of
   unsolicited email (spam).  At the same time, these protocols can
   provide a level of cryptographic integrity and authenticity for some
   headers, depending on how they are used.
   However, integrity protection and proof of authenticity are both tied
   to the domain name of the sending e-mail address, not the sending
   address itself, so these protocols do not provide end-to-end
   protection, and are incapable of providing any form of
   confidentiality.

1.2.  Requirements Language

   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].

1.3.  Terms

   The following terms are defined for the scope of this document:

   o  Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A
      form of active wiretapping attack in which the attacker intercepts
      and selectively modifies communicated data to masquerade as one or
      more of the entities involved in a communication association."

      Note: Historically, MITM has stood for '_Man_-in-the-middle'.
      However, to indicate that the entity in the middle is not always a
      human attacker, MITM can also stand for 'Machine-in-the-middle' or
      'Meddler-in-the-middle'.

   o  S/MIME: Secure/Multipurpose Internet Mail Extensions (cf.
      [RFC8551])

   o  PGP/MIME: MIME Security with OpenPGP (cf.  [RFC3156])

   o  Message: An Email Message consisting of Header Fields
      (collectively called "the Header Section of the message")
      followed, optionally, by a Body; cf. [RFC5322].

      Note: To avoid ambiguity, this document does not use the terms
      "Header" or "Headers" in isolation, but instead always uses
      "Header Field" to refer to the individual field and "Header
      Section" to refer to the entire collection; cf. [RFC5322].

   o  Header Field (HF): cf. [RFC5322] Header Fields are lines beginning
      with a field name, followed by a colon (":"), followed by a field
      body (value), and terminated by CRLF; cf. [RFC5322]. CRLF.

   o  Header Section (HS): The Header Section is a sequence of lines of
      characters with special syntax as defined in [RFC5322].  It is the
      (top) section of a Message containing the Header Fields.

   o  Body: The Body is simply a sequence of characters bytes that follows the
      Header Section and is separated from the Header Section by an
      empty line (i.e., a line with nothing preceding the CRLF); cf
      [RFC5322].  It is the (bottom) section of Message containing the
      payload of a Message.  Typically, the Body consists of a (possibly
      multipart) MIME [RFC2045] construct.

   o  MIME Header Fields: Header Fields describing content of a MIME
      entity [RFC2045], in particular the MIME structure.  Each MIME
      Header Field name starts with "Content-" prefix.

   o  MIME Header Section (part): The collection of MIME Header Fields.
      "MIME Header Section" refers to a Header Sections that contains
      only MIME Header Fields, whereas "MIME Header Section part" refers
      to the MIME Header Fields of a Header Section that - in addition
      to MIME Header Fields - also contains non-MIME Header Fields.

   o  Essential Header Fields (EHF): The minimum set of Header Fields an
      Outer Message Header Section SHOULD contain; cf. Section 4.1.4. 4.1.2.4.

   o  Header Protection (HP): cryptographic protection of email Header
      Sections (or parts of it) for signatures and/or encryption

   o  Protection Levels (PL): One The level of protection applied to a
      Message, e.g.  'signature and encryption',
      'signature only' encryption' or 'encryption 'signature only' (cf.
      Section 3.2) 3.2).

   o  Protected: Protected refers to the parts Portions of a Message where
      protection measures of message that have had any Protection Level have been applied to.
      Levels applied.

   o  Protected Message: A Message that protection measures of has had any Protection Levels have been applied to.
      applied.

   o  Unprotected: Unprotected refers to the parts Portions of a Message where that has had no
      protection measures of any Protection
      Levels have been applied to. applied.

   o  Unprotected Message: A Message that has had no protection measures of any Protection Levels have been applied to.
      applied.

   o  Submission Entity: The entity taking care of which executes further processing of
      the Message (incl. transport towards the receiver), after
      protection measures have been applied to. to the Message.

      Note: The Submission Entity varies among implementations, mainly
      depending on the stage, stage where protection measures are applied to:
      It could be e.g. applied: E.g.
      a Message Submission Agent (MSA) [RFC6409] or another
      (proprietary) solution.  The latter is particularly relevant, if
      protection is implemented as a plugin solution.  Some
      implementations may determine the destination recipients by
      reading the To, Cc and Bcc Header Fields of the Outer Message.

   o  Original Message (OrigM): The message Message to be protected before any
      protection related
      protection-related processing has been applied on the sending
      side.  If the source is not a "message/rfc822" Message, OrigM is
      defined as the "virtual" Message that would be constructed for
      sending it as unprotected email.

   o  Inner Message (InnerM): The message Message to be protected, i.e. protected which has had
      wrapping and protection measures are applied to aapplied on the sending side or OR
      the result of resulting Message once decryption and unwrapping on the
      receiving side respectively. has been performed.  Typically, the Inner Message
      is in clear text.  The Inner Message is a subset of (or the same
      as) the Original Message (cf.  Section 4.1.2). 4.1.2.1).  The Inner
      Message must be the same on the sending and the receiving side.

   o  Outer Message (OuterM): The Message as handed over provided to the Submission
      Entity or received from the last hop respectively.  The Outer
      Message normally differs on the sending and the receiving side
      (e.g. new Header Fields are added by intermediary nodes).

   o  Receiving User Facing Message (RUFM): The message Message used for
      rendering at the receiving side.  Typically this is the same as
      the Inner Message.

   o  Data Minimization: Data sparseness and hiding of all technically
      concealable information whenever possible.

   o  Cryptographic Layer, Cryptographic Payload, and Cryptographic
      Envelope are all used as defined in
      [I-D.dkg-lamps-e2e-mail-guidance]

2.  Problem Statement

   The LAMPS charter contains the following Work Item:

      Update the specification for the cryptographic protection of email
      headers - both for signatures and encryption - to improve the
      implementation situation with respect to privacy, security,
      usability and interoperability in cryptographically-protected
      electronic mail.  Most current implementations of
      cryptographically-protected electronic mail protect only the body
      of the message, which leaves significant room for attacks against
      otherwise-protected messages.

   In the following a set of challenges to be addressed:

   [[ TODO: Enhance this section, add more items to the following. ]]

2.1.  Privacy

   o  (Technical) Data Minimization, which includes data sparseness and
      hiding all technically concealable information whenever possible

2.2.  Security

   o  Prevent MITM attacks (cf.  [RFC4949])

2.3.  Usability

   o  Improved User interaction / User experience experience, in particular at the
      receiving side

2.4.  Interoperability

   o  Interoperability with [RFC8551] implementations

3.  Use Cases

   In the following, the reader can find a list of the generic use cases
   that need to be addressed for Messages with Header Protection (HP).
   These use cases apply regardless of technology (S/MIME, PGP/MIME,
   etc.) used to achieve HP.

3.1.  Interactions

   The following use cases assume that at least the sending side
   supports Header Protection as specified in this document.  Receiving
   sides that support this specification are expected to be able to
   distinguish between Messages that use Header Protection - as specified
   in this document - has been applied to document, and (legacy) Mail User Agents (MUAs) which do not implementing
   implement this specification.

   [[ TODO: Verify once solution is stable and update last sentence. ]]

3.1.1.  Main Use Case

   Both the sending and receiving side (fully) support Header Protection
   as specified in this document.

   The main use case is specified in Section 4.1.

3.1.2.  Backward Compatibility Use Cases

   Regarding backward compatibility, the main distinction is based on
   whether or not the receiving side conforms to MIME according to
   [RFC2046], ff., which in particular also includes Section 2 of
   [RFC2049] on "MIME Conformance".  In the  The following an excerpt of
   paragraphs relevant in this context: is
   contextually relevant:

   A mail user agent that is MIME-conformant MUST:

   [...]

            -- Recognize and display at least the RFC822 message
            encapsulation (message/rfc822) in such a way as to
            preserve any recursive structure, that is, displaying
            or offering to display the encapsulated data in
            accordance with its media type.

            -- Treat any unrecognized subtypes as if they were
            "application/octet-stream".

   [...]

     A user agent

   An MUA that meets the above conditions is said to be MIME-
   conformant.  The meaning of this phrase is that it  A MIME-conformant MUA is assumed to be "safe" to send
   virtually any kind of properly-marked data to users of such mail
   systems, because such these systems will are, at least be able to
     treat a minimum, capable of treating
   the data as undifferentiated binary, and will not simply
   splash it onto the screen of unsuspecting users.

   [[ TODO: The compatibility of legacy HP systems with this new
   solution, and how to handle issues surrounding future maintenance for
   these legacy systems, will be decided by the LAMPS WG. ]]

3.1.2.1.  Receiving Side MIME-Conformant

   The sending side (fully) supports Header Protection as specified in
   this document, while the receiving side does not support this
   specification.  However, the receiving side is MIME-conformant
   according to [RFC2045], ff. (cf.  Section 3.1.2), 3.1.2).

   This use case is specified in Section 4.2.1.

   Note: This case should perform as expected if the sending side
   applies this specification as outlined in Section 4.1.

   [[ TODO: Verify once solution is stable and update last sentence. ]]

3.1.2.2.  Receiving Side Not MIME-Conformant

   The sending side (fully) supports Header Protection as specified in
   this document, while the receiving side does not support this
   specification.  Furthermore, the receiving side is *not* MIME-
   conformant according to [RFC2045], ff. (cf.  Section 3.1.2).

   This use case is specified in Section 4.2.2.

3.2.  Protection Levels

3.2.1.  In-Scope

   The following Protection Levels need to be considered: are in scope for this document:

   a) Signature and encryption

   Messages containing a cryptographic signature, which are also
   encrypted.

   b) Signature only

   Messages containing a cryptographic signature, but which are not
   encrypted.

   c) Encryption only

   Messages that are encrypted, but do

3.2.2.  Out-of-Scope

   Legacy implementations, implementations not contain a cryptographic
   signature.

   [[ TODO: There are (fully) compliant with
   this document or corner-cases may lead to further "Protection Levels" Protection Levels
   to describe for appear on the receiving side, e.g. encrypted such as (list not exhaustive):

   o  Triple wrap

   o  Encryption only

   o  Encryption before signature

   o  Signature and signed (only after encryption),
   etc. ]] encryption, but:

      *  Signature fails to validate

      *  Signature validates but the signing certificate revoked

   o  Signature only, but:

      *  with multiple valid signatures, layered atop each other

   These Protection Levels, as well as any further Protection Levels not
   listed in Section 3.2.1 are beyond the scope of this document.

4.  Specification

   This section contains the specification for Header Protection in
   S/MIME to update and clarify Section 3.1 of [RFC8551] (S/MIME 4.0).

   Note: It is likely that PGP/MIME [RFC3156] will also incorporate this
   specification or parts of it.

   This specification applies to the Protection Levels "signature &
   encryption" and "signature only" (cf.  Section 3.2):

   Sending and receiving sides MUST implement the "signature and
   encryption" Protection Level", Level, which SHOULD be used as default on the
   sending side.

   Certain implementations may decide to send "signature only" messages, Messages,
   depending on the circumstances and customer requirements.  Sending
   sides MAY and receiving sides MUST implement "signature only"
   Protection Level.

   It generally is NOT RECOMMENDED to send a message Message with any other
   Protection
   Level "encryption only". Level.  On the other hand, messages with Protection
   Level "encryption only" might arrive at the receiving side.  While
   not targeted side must be
   prepared to receive Messages with other Protection Level "encryption only", this
   specification Levels.

   [[ TODO: Further study is assumed to also function for "encryption only".
   Receiving sides SHOULD implement "encryption only".

   [[ TODO: Further study is necessary necessary to determine whether - and if yes
   to what extent - additional guidance for handling messages with other
   Protection Levels, e.g. "encryption only" protection (as well as other variations) at the receiving side
   should be included in this document. ]]

4.1.  Main Use Case

   This section applies to the main use case, where the sending and
   receiving side (fully) support Header Protection as specified herein
   (cf.  Section 3.1.1).

   Note: The sending side specification of the main use case is also
   applicable to the cases where the sending side (fully) supports
   Header Protection as specified herein, while the receiving side does
   not, but is MIME-conformant according to [RFC2045], ff. (cf.
   Section 3.1.2) 3.1.2 and Section 3.1.2.1) 3.1.2.1).

   Further backward compatibility cases are defined in Section 4.2.

4.1.1.  MIME Format

   Currently there are two options in discussion:

   1.  The option according to the current S/MIME specification (cf.
       [RFC8551])

   2.  An alternative option that is based on the former "memory hole"
       approach (cf.  [I-D.autocrypt-lamps-protected-headers])

4.1.1.1.  S/MIME Specification  Introduction

   As per S/MIME version 3.1 and later (cf.  [RFC8551]), 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.

   To help the receiving side to distinguish between a forwarded and a
   wrapped message, the Content-Type header field parameter "forwarded"
   is added as defined in [I-D.melnikov-iana-reg-forwarded].  Certain
   mailing applications might display the Inner Message as an attachment
   otherwise.

   The simplified (cryptographic overhead not shown) MIME structure of
   such an Email message Message looks as follows:

     <Outer Message Header Section (unprotected)>

     <Outer Message Body (protected)>

       <MIME Header Section (wrapper)>

         <Inner Message Header Section>

         <Inner Message Body>

   The following example demonstrates how an Original Message might be
   protected, i.e., the Original Message is contained as Inner Message
   in the Protected Body of an Outer Message.  It illustrates the first
   Body part (of the Outer Message) as a "multipart/signed"
   (application/pkcs7-signature) media type:

   Lines are prepended as follows:

   o  "O: " Outer Message Header Section

   o  "I: " Message Header Section

   o  "W: " Wrapper (MIME Header Section)
     O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
     O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
     O: Subject: Meeting at my place
     O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
     O: To: somebody@example.net
     O: MIME-Version: 1.0
     O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
     O:  protocol="application/pkcs7-signature";
     O:  boundary=boundary-AM

        This is a multipart message in MIME format.
        --boundary-AM
     W: Content-Type: message/RFC822; forwarded=no
     W:
     I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
     I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
     I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
     I: MIME-Version: 1.0
     I: MMHS-Primary-Precedence: 3
     I: Subject: Meeting at my place
     I: To: somebody@example.net
     I: X-Mailer: Isode Harrier Web Server
     I: Content-Type: text/plain; charset=us-ascii

        This is an important message that I don't want to be modified.

        --boundary-AM
        Content-Transfer-Encoding: base64
        Content-Type: application/pkcs7-signature

        [[base-64 encoded signature]]

        --boundary-AM--

   The Outer Message Header Section is unprotected, while the remainder
   (Outer Message Body) is protected.  The Outer Message Body consists
   of the wrapper (MIME Header Section) and the Inner Message (Header
   Section and Body).

   The wrapper is a simple MIME Header Section with media type "message/
   RFC822"
   rfc822" containing a Content-Type header field parameter
   "forwarded=no" followed by an empty line.

   The

   If the source is an Original (message/rfc822) Message, the Inner
   Message Header Section is typically the same as (or a subset of) the
   Original Message Header Section (cf.  Section 4.1.2).

   The 4.1.2.1), and the Inner
   Message Body is typically the same as the Original Message Body.

   The Original Inner Message itself may contain any MIME structure.

4.1.1.2.  Alternative Option Autocrypt "Protected Headers" (Ex-"Memory
          Hole")

   An alternative option (based on the former autocrypt "Memory Hole"
   approach)

   Note: It is still to be considered, is described in
   [I-D.autocrypt-lamps-protected-headers].

   Unlike decided by the option LAMPS WG whether or not to
   recommend an alternative MIME format as described in Section 4.1.1.1, Appendix B.1.1.1
   (instead of the currently standardized and above defined format).

4.1.2.  Sending Side

   To ease explanation, the following describes the case where an
   Original (message/rfc822) Message to be protected is present.  If
   this option does is not
   use a "message/RFC822" wrapper to unambiguously delimit the case, Original Message means the (virtual) Message
   that would be constructed for sending it as unprotected email.

4.1.2.1.  Inner
   Message.

   Before choosing this option, Message Header Fields

   It is RECOMMENDED that the Inner Message contains all Header Fields
   of the Original Message with the exception of the following two issues must be
   assessed to ensure no interoperability issues result from it:

   1.  How current MIME parser implementations treat non-MIME Header
       Fields,
   Field, which are not part of MUST NOT be included within the outermost MIME entity and not Inner Message nor within
   any other protected part of a message wrapped into a MIME entity of media type
       "message/rfc822", and how such messages are rendered to the user.

       [I-D.autocrypt-lamps-protected-headers] provides some examples
       for testing this.

   2.  MIME-conformance, i.e. whether or not this option is (fully)
       MIME-conformant [RFC2045] ff., in particular Message:

   o  Bcc

   [[ TODO: Bcc handling needs to be further specified (see also
   Appendix A.1).  Certain MUAs cannot properly decrypt Messages with
   Bcc recipients. ]]

4.1.2.2.  Wrapper

   The wrapper is a simple MIME Header Section 5.1. of
       [RFC2046] on "Multipart Media Type).  In the following followed by an excerpt empty line
   preceding the Inner Message (inside the Outer Message Body).  The
   media type of paragraphs that may the wrapper MUST be relevant in this context:

         The only "message/RFC822" and MUST contain
   the Content-Type header fields that have field parameter "forwarded=no" as defined meaning for body parts
         are those in
   [I-D.melnikov-iana-reg-forwarded].  The wrapper unambiguously
   delimits the names Inner Message from the rest of which begin with "Content-".  All other
         header fields may be ignored in body parts.  Although they
         should generally be retained if at all possible, they may be
         discarded by gateways if necessary.  Such other fields are
         permitted the Message.

4.1.2.3.  Cryptographic Layers / Envelope

   [[ TODO: Basically refer to appear in body parts but must not be depended on.
         "X-" fields may be created for experimental or private
         purposes, with S/MIME standards ]]

4.1.2.4.  Outer Message Header Fields

4.1.2.4.1.  Encrypted Messages

   To maximize Privacy, it is strongly RECOMMENDED to follow the recognition that
   principle of Data Minimization (cf.  Section 2.1).

   However, the information they Outer Message Header Section SHOULD contain may be lost at some gateways.

         NOTE:  The distinction between an RFC 822 message and a body
         part is subtle, but important.  A gateway between Internet and
         X.400 mail, for example, must be able to tell the difference
         between a body part that contains an image and a body part
         that contains an encapsulated message,
   Essential Header Fields and, in addition, MUST contain the body Header
   Fields of which is a
         JPEG image.  In order to represent the latter, the body MIME Header Section part
         must have "Content-Type: message/rfc822", and its body (after
         the blank line) must be the encapsulated message, with its own
         "Content-Type: image/jpeg" header field.  The use of similar
         syntax facilitates the conversion of messages to body parts,
         and vice versa, but the distinction between the two must be
         understood by implementors.  (For describe Cryptographic
   Layer of the special case in which
         parts actually are messages, a "digest" subtype is also
         defined.)

   The protected MIME structure of an Email message looks subtree as follows:

     <Outer Message Header Section (unprotected)>

     <Outer Message Body (protected)>

       <Inner Message Header Section>

       <Inner Message Body> per [RFC8551].

   The following example demonstrates how an Original Message might be
   protected, i.e., the Original Message is contained Header Fields are defined as Inner Message
   in the Protected Body of an Outer Message.  It illustrates Essential Header
   Fields:

   o  From

   o  To (if present in the first
   Body part (of Original Message)

   o  Cc (if present in the Outer Original Message) as a "multipart/signed"
   (application/pkcs7-signature) media type:

   Lines are prepended as follows:

   o  "O: " Outer Message Header  Bcc (if present in the Original Message, see also Section 4.1.2.1
      and Appendix A.1)

   o  "I: " Message  Date

   o  Message-ID

   o  Subject

   Further processing by the Submission Entity normally depends on part
   of these Header Section
     O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
     O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
     O: Subject: Meeting at my place
     O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
     O: MIME-Version: 1.0
     O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
     O:  protocol="application/pkcs7-signature";
     O:  boundary=boundary-AM

        This is a multipart message in MIME format.
        --boundary-AM
     I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
     I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
     I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
     I: MIME-Version: 1.0
     I: MMHS-Primary-Precedence: 3
     I: Subject: Meeting at my place
     I: To: somebody@example.net
     I: X-Mailer: Isode Harrier Web Server
     I: Content-Type: text/plain; charset=us-ascii

        This is an important message that I don't want to be modified.

        --boundary-AM
        Content-Transfer-Encoding: base64
        Content-Type: application/pkcs7-signature

        [[base-64 encoded signature]]

        --boundary-AM--

   The Outer Message Fields, e.g.  From and Date HFs are required by
   [RFC5322].  Furthermore, not including certain Header Section is unprotected, while Fields may
   trigger spam detection to flag the remainder
   (Outer Message Body) is protected.  The Outer Message Body consists Message, and/or lead to user
   experience (UX) issues.

   For further Data Minimization, the value of the Inner Message (Header Section and Body).

   The Inner Message Subject Header Section Field
   SHOULD be obfuscated as follows:

   * Subject: [...]

   and it is RECOMMENDED to replace the same as (or Message-ID by a subset of) new randomly
   generated Message-ID.

   In addition, the
   Original value of other Essential Header Fields MAY be
   obfuscated.

   Non-Essential Header Fields SHOULD be omitted from the Outer Message
   Header Section (cf.  Section 4.1.2).

   The Inner where possible.  If Non-essential Header Fields are
   included in the Outer Message Body is Header Section, those MAY be obfuscated
   too.

   Header Fields that are not obfuscated should contain the same values
   as in the Original Message Body.

   The Original Message itself may contain any MIME structure.

4.1.2.  Inner Message Header Fields

   It is RECOMMENDED that Message.

   If an implementation obfuscates the Inner Message contains all From, To, and/or Cc Header Fields
   of the Original Message with
   Fields, it may need to provide access to the exception clear text content of the following
   these Header
   Field, which MUST NOT be included within the Inner Message nor within
   any other protected part of the message:

   o  Bcc

   [[ TODO: Bcc handling needs Fields to be further specified (see also
   Appendix A.1).  Certain MUAs cannot properly decrypt messages with
   Bcc recipients. ]]

4.1.3.  Wrapper

   The wrapper is a simple MIME Header Section followed by an empty line
   preceding the Inner Message (inside the Outer Message Body).  The
   media type Submission Entity for processing purposes.
   This is particularly relevant, if proprietary Submission Entities are
   used.  Obfuscation of the wrapper MUST be "message/RFC822" and MUST contain
   the Content-Type header field parameter "forwarded=no" as defined in
   [I-D.melnikov-iana-reg-forwarded].  The wrapper unambiguously
   delimits the Inner Message from the rest Header Fields may adversely impact spam
   filtering.

   (A use case for obfuscation of the message.

4.1.4. all Outer Message Header Fields

   To maximize Privacy, it is strongly RECOMMENDED to follow
   routing email through the
   principle use of Data Minimization (cf.  Section 2.1).

   However, the Outer Message onion routing or mix networks, e.g.
   [pEp.mixnet].)

   The MIME Header Section SHOULD contain the
   Essential Header Fields and, in addition, MUST contain part is the collection of MIME Header Fields of
   describing the following MIME structure as defined in [RFC2045].  A
   MIME Header Section part to describe typically includes the encryption or
   signature as per [RFC8551].

   The following Header Fields are defined as the Essential Header
   Fields:

   o  From  Content-Type

   o  To (if present in the Original Message)

   o  Cc (if present in the Original Message)

   o  Bcc (if present in the Original Message, see also Section 4.1.2
      and Appendix A.1)

   o  Date

   o  Message-ID

   o  Subject

   Further processing by the Submission Entity normally depends on part
   of these Header Fields, e.g.  From and Date HFs are required by

   [RFC5322].  Furthermore, not including certain Header Fields may
   trigger spam detection to flag the message and/or lead to user
   experience (UX) issues.

   For further Data Minimization, the value of the Subject Header Field
   SHOULD be obfuscated.  In addition, the value of other Essential
   Header Fields MAY be obfuscated.  Further Header Fields MAY be
   obfuscated, though simply not adding those to the Outer Message
   Header Section SHOULD be preferred over obfuscation.  Header Field
   obfuscation is further specified in Section 4.1.4.1.  Header Fields
   not obfuscated should contain the same values as in the Original
   Message.

   The MIME Header Section part is the collection of MIME Header Fields
   describing the following MIME structure as defined in [RFC2045].  A
   MIME Header Section part typically includes the following Header
   Fields:

   o  Content-Type

   o  Content-Transfer-Encoding  Content-Transfer-Encoding

   o  Content-Disposition

   The following example shows the MIME Header Section part of an S/MIME
   signed message Message (using application/pkcs7-mime with SignedData):

      MIME-Version: 1.0
      Content-Type: application/pkcs7-mime; smime-type=signed-data;
         name=smime.p7m
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p7m

   Depending on the scenario, further Header Fields MAY be exposed in
   the Outer Message Header Section, which is NOT RECOMMENDED unless
   justified.  Such Header Fields may include e.g.:

   o  References

   o  Reply-To

   o  In-Reply-To

4.1.4.1.  Obfuscation of

4.1.2.4.2.  Unencrypted Messages

   The Outer Message Header Fields

   If the values Section of unencrypted Messages SHOULD
   contain at least the following Outer Message Essential Header Fields are
   obfuscated, those SHOULD assume and, in addition, MUST
   contain the following values:

   * Subject: ...
   * Message-ID: <new randomly generated Message-ID>
   * Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)

   [[ TODO: Consider alternatives for Date e.g. set to Monday 9am Header Fields of the
   same week.  The Impact of obfuscated Date HF content MIME Header Section part to certificate
   validation is for describe
   Cryptographic Layer of the protected MIME subtree as per [RFC8551].
   It may contain further study, Header Fields, in particular regarding legacy
   clients. ]]

   In certain implementations those also
   present in the From, To, and/or Cc Inner Message Header Field
   MAY be obfuscated.  Those may be replaced by e.g.

   o  To: Obfuscated <anonymous@anonymous.invalid>

   Such implementations may need Section.

4.1.2.5.  Sending Side Message Processing

   For a protected Message the following steps are applied before a
   Message is handed over to ensure that the Submission Entity
   has access Entity:

4.1.2.5.1.  Step 1: Decide on Protection Level and Information
            Disclosure

   The implementation which applies protection to a Message must decide:

   o  Which Protection Level (signature and/or encryption) shall be
      applied to the content Message?  This depends on user request and/or local
      policy as well as availability of these cryptographic keys.

   o  Which Header Fields in clear text and is
   capable of processing those. the Original Message shall be part of the
      Outer Message Header Section?  This is particularly relevant, if
   proprietary Submission Entities typically depends on local
      policy.  By default, the Essential Header Fields are used.

   A use case for obfuscation part of all the
      Outer Message Header Section; cf. Section 4.1.2.4.

   o  Which of these Header Fields is
   routing email using onion routing or mix networks (e.g.
   [pEp.mixnet]).

   Note: It is for further study are to what extent be obfuscated?  This depends
      on local policy and/or specific Privacy requirements of the user.
      By default only the Subject Header Field obfuscation
   adversely impacts spam filtering.

4.1.5.  Receiving User Facing is obfuscated; cf.
      Section 4.1.2.4.

4.1.2.5.2.  Step 2: Compose the Outer Message Header Fields

   The Receiving User Facing Section

   Depending on the decision in Section 4.1.2.5.1, the implementation
   shall compose the Outer Message SHOULD be a verbatim copy of Header Section.  (Note that this also
   includes the
   Inner Message.

4.1.6. necessary MIME Header Field Flow

   The Following figure depicts Section part for the different message representations
   (OrigM, InnerM, OuterM, RUFM) and which parts those following
   protection layer.)

   Outer Header Fields that are constructed
   from:

   OrigM        InnerM       Outer(S)            OuterM(R)    RUFM

                                                 <Trace-HF>
                             From (OrigM)      = From
                             To (OrigM)        = To
                             Cc (OrigM)        = Cc
                             Bcc (OrigM)       = Bcc*
                             Date (OrigM)      = Date
                             Message-ID (OrigM)= Message-ID
                             Subject (new)     = Subject
                             <MIME-HSp> (new)  = <MIME-HSp>

                             PROTECTED:          PROTECTED:
                             <Wrapper> (new)   = <Wrapper>
   From       > From       > From              = From       > From
   To         > To         > To                = To         > To
   Cc*        > Cc         > Cc                = Cc         > Cc
   Bcc*
   Date       > Date       > Date              = Date       > Date
   Message-ID > Message-ID > Message-ID        = Message-ID > Message-ID
   Subject    > Subject    > Subject           = Subject    > Subject
   <More HF>  > <More HF>  > <More HF>         = <More HF>  > <More-HF>
   <MIME-HSp> > <MIME-HSp> > <MIME-HSp>        = <MIME-HSp> > <MIME-HSp>
   <Body>     > <Body>     > <Body>            = <Body>     > <Body>
                             <Signature>* (new)= <Signature>

   Legend:

   o  OuterM(S): Outer Message (OuterM) at sending side (before handing
      it over to the Submission Entity)

   o  OuterM(R): Outer Message at receiving side (as received by not obfuscated should contain the
      last hop, before decryption and/or signature verification is
      applied to)

   o  InnerM: Inner Message (that protection is applied to)

   o  RUFM: Receiving User Facing Message

   o  More-HF: Additional Header Fields (HF) same
   values as in the Original Message
      (OrigM)

   o  Wrapper: (except for MIME Header Section; with media type (message/RFC822) to
      unambiguously delimit
   Section part, which depends on the inner message from Protection Level selected in
   Section 4.1.2.5.1).

4.1.2.5.3.  Step 3: Apply Protection to the rest of Original Message

   Depending on the
      message.

   o  MIME-HSp: MIME Header Protection Level selected in Section part to describe 4.1.2.5.1, the encryption or
   implementation applies signature as and/or encryption to the Original
   Message, including the wrapper (as per [RFC8551]

   o  Trace-HF: Header Fields added in Transit (between sending [RFC8551]), and
      receiving side) sets the
   resulting package as per [RFC5322]

   o  >: taken over / copied from last column

   o  =: propagates unchanged, unless something unusual (e.g. attack)
      happens

   o  *: HF that is often not present (also further HFs, e.g.  To, may
      not be present).  If a HF the Outer Message Body.

   The resulting (Outer) Message is not present, naturally it can neither
      be taken then typically handed over nor propagated.

   o  (new) / (OrigM): HF or MIME-HSp is generated depending on to the
      decision in Section 4.1.7.1, while '(new)' / '(OrigM)' designate
   Submission Entity.

   [[ TODO: Example ]]

4.1.3.  Receiving Side

4.1.3.1.  Receiving User Facing Message Header Fields

   The Receiving User Facing Message SHOULD be a verbatim copy of the default.

4.1.7.  Sending
   Inner Message.

4.1.3.2.  Receiving Side Message Processing

   For

   When a protected message Message is received, the following steps are applied before a
   message is handed over to the Submission Entity:

4.1.7.1.
   applied:

4.1.3.2.1.  Step 1: Decide on Protection Level and Information Disclosure

   The entity applying protection to a message must decide:

   o  Which Protection Level (signature and/or encryption) is applied to
      the message?  This depends on user request and/or local policy as
      well as availability of cryptographic keys.

   o  Which Header Fields of the Original Message shall be part of the
      Outer Decrypt Message Header Section?  This typically depends and/or check signature

   Depending on local
      policy.  By default the Essential Header Fields are part of Protection Level, the
      Outer received Message Header Section; cf. Section 4.1.4.

   o  Which of these Header Fields are to be obfuscated?  This depends
      on local policy is decrypted
   and/or specific Privacy requirements of the user.
      By default only the Subject Header Field its signature is obfuscated; cf.
      Section 4.1.4.1.

4.1.7.2. checked as per [RFC8551].

4.1.3.2.2.  Step 2: Compose Construct the Outer Receiving User Facing Message Header Section

   Depending on the decision in Section 4.1.7.1, compose the Outer

   The Receiving User Facing Message Header Section.  (Note that this also includes the necessary
   MIME Header is constructed according to
   Section part for the following protection layer.)
   Outer Header Fields that are not obfuscated should contain the same
   values as in the Original 4.1.3.1.

   The resulting Message (except is handed over for MIME Header
   Section part, further processing, which depends on
   typically involves rendering it for the Protection Level selected in
   Section 4.1.7.1).

4.1.7.3. user.

4.1.3.3.  Step 3: Apply Protection Prepare Information Cyptographic Verification

   [[ TODO: Signature valid, etc. ]]

4.2.  Backward Compatibility Use Cases

4.2.1.  Receiving Side MIME-Conformant

   This section applies to the Original Message

   Depending on case where the sending side (fully)
   supports Header Protection Level selected as specified in Section 4.1.7.1, apply
   signature and/or encryption to the Original Message, including the
   wrapper (as per [RFC8551]), and set the result to the message as
   Outer Message Body.

   The resulting (Outer) Message is then typically handed over to the
   Submission Entity.

   [[ TODO: Example ]]

4.1.8.  Receiving Side Message Processing

   When a protected message is received, the following steps are
   applied:

4.1.8.1.  Step 1: Decrypt message and/or check signature

   Depending on the Protection Level, the received message is decrypted
   and/or its signature is checked as per [RFC8551].

4.1.8.2.  Step 2: Construct the Receiving User Facing Message

   The Receiving User Facing Message is constructed according to
   Section 4.1.5.

   The resulting message is handed over for further processing, which
   typically involves rendering it for the user.

   Note: Further study is needed to determine whether or not the Outer
   Message Header Section, as received from the last hop, is preserved
   for the user, and if so, how this is to be achieved.

4.2.  Backward Compatibility Use Cases

4.2.1.  Receiving Side MIME-Conformant

   This section applies to the case where the sending side (fully)
   supports Header Protection as specified in this document, while this document, while the
   receiving side does not support this specification, but is MIME-
   conformant according to [RFC2045], ff. (cf.  Section 3.1.2) 3.1.2 and
   Section 3.1.2.1)

   The sending side specification of the main use case (cf.
   Section 4.1) MUST ensure that receiving sides can still recognize and
   display or offer to display the encapsulated data in accordance with
   its media type (cf.  [RFC2049], Section 2).  In particular, receiving
   sides that do not support this specification, but are MIME-conformant
   according to [RFC2045], ff. can still recognize and display the
   Message intended for the user.

   [[ TODO: Verify once solution is stable and update last sentence. ]]

4.2.2.  Receiving Side Not MIME-Conformant

   This section applies to the case cases where the sending side (fully) supports
   Header Protection as specified in this document, while the receiving
   side neither supports this specification *nor* is MIME-
   conformant MIME-conformant
   according to [RFC2045], ff. (cf.  Section 3.1.2 and Section 3.1.2.2).

   [I-D.autocrypt-lamps-protected-headers] describes a possible way to
   achieve backward compatibility with existing S/MIME (and PGP/MIME)
   implementations that predate this specification and are not MIME-
   conformant (Legacy Display) either.  It mainly focuses on email
   clients that do not render emails using which utilize header protection (in in
   a user friendly manner) and manner, which may confuse the user.  While this has
   been observed occasionally in PGP/MIME (cf.  [RFC3156]), the extent
   of this problem with S/MIME implementations is still unclear.  (Note:
   At this time, none of the samples in
   [I-D.autocrypt-lamps-protected-headers] apply header protection as
   specified in Section 3.1 of [RFC8551], which is wrapping as Media
   Type "message/RFC822".)

   Should serious backward compatibility issues with rendering at the
   receiver
   receiving side be discovered, the Legacy Display format described in
   [I-D.autocrypt-lamps-protected-headers] may serve as a basis to
   mitigate those issues (cf.  Section 4.2).

   Another variant of backward compatibility has been implemented by pEp
   [I-D.pep-email], i.e. pEp Email Format 1.0.  At this time pEp has
   implemented this for PGP/MIME, but not yet S/MIME.

5.  Security Considerations

   [[ TODO ]]

6.  Privacy Considerations

   [[ TODO ]]

7.  IANA Considerations

   This document requests no action from IANA.

   [[ RFC Editor: This section may be removed before publication. ]]

8.  Acknowledgments

   The authors would like to thank the following people who have
   provided helpful comments and suggestions for this document: Berna
   Alp, Claudio Luck, Daniel Kahn Gillmor, David Wilson, Hernani Marques, juga, Krista
   Bennett, Kelly Bristol, Lars Rohwedder, Robert Williams, Russ
   Housley, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang.

9.  References

9.1.  Normative References

   [I-D.dkg-lamps-e2e-mail-guidance]
              Gillmor, D., "Guidance on End-to-End E-mail Security",
              draft-dkg-lamps-e2e-mail-guidance-00 (work in progress),
              October 2020.

   [I-D.ietf-lamps-header-protection-requirements]
              Melnikov, A. and B. Hoeneisen, "Problem Statement and
              Requirements for Header Protection", draft-ietf-lamps-
              header-protection-requirements-01 (work in progress),
              October 2019.

   [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,
              <https://www.rfc-editor.org/info/rfc2045>.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,
              <https://www.rfc-editor.org/info/rfc2046>.

   [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,
              <https://www.rfc-editor.org/info/rfc2049>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
              April 2019, <https://www.rfc-editor.org/info/rfc8551>.

9.2.  Informative References

   [I-D.autocrypt-lamps-protected-headers]
              Einarsson, B., juga, j., and D. Gillmor, "Protected
              Headers for Cryptographic E-mail", draft-autocrypt-lamps-
              protected-headers-02 (work in progress), December 2019.

   [I-D.melnikov-iana-reg-forwarded]
              Melnikov, A. and B. Hoeneisen, "IANA Registration of
              Content-Type Header Field Parameter 'forwarded'", draft-
              melnikov-iana-reg-forwarded-00 (work in progress),
              November 2019.

   [I-D.pep-email]
              Marques, H., "pretty Easy privacy (pEp): Email Formats and
              Protocols", draft-pep-email-00 (work in progress), July
              2020.

   [pEp.mixnet]
              pEp Foundation, "Mixnet", June 2020,
              <https://dev.pep.foundation/Mixnet>.

   [RFC3156]  Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
              "MIME Security with OpenPGP", RFC 3156,
              DOI 10.17487/RFC3156, August 2001,
              <https://www.rfc-editor.org/info/rfc3156>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/info/rfc4949>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

   [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
              <https://www.rfc-editor.org/info/rfc6409>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://www.rfc-editor.org/info/rfc7208>.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https://www.rfc-editor.org/info/rfc7489>.

Appendix A.  Additional information

A.1.  Stored Variants of Messages with Bcc

   Messages containing at least one recipient address containing at least one recipient address in the Bcc header
   field may appear in up to three different variants:

   1.  The Message for the recipient addresses listed in To or Cc header
       fields, which must not include the Bcc header field neither for
       signature calculation nor for encryption.

   2.  The Message(s) sent to the recipient addresses in the Bcc header
       field, which depends on the implementation:

       a) One Message for each recipient in the Bcc header field
       separately, with a Bcc header field containing only the address
       of the recipient it is sent to.

       b) The same Message for each recipient in the Bcc header field
       with a Bcc header field containing an indication such as
       "Undisclosed recipients", but no addresses.

       c) The same Message for each recipient in the Bcc header field
       which does not include a Bcc header field (this Message is
       identical to 1. / cf. above).

   3.  The Message stored in the 'Sent'-Folder of the sender, which
       usually contains the Bcc unchanged from the original Message,
       i.e., with all recipient addresses.

   The most privacy preserving method of the alternatives (2a, 2b, and
   2c) is to standardize 2a, as in the other cases (2b and 2c),
   information about hidden recipients is revealed via keys.  In any
   case, the Message has to be cloned and adjusted depending on the
   recipient.

Appendix B.  Text Moved from Above

   Note: Per an explicit request by the chair of the LAMPS WG to only
   present one option for the specification, the following text has been
   stripped from the main body of the draft.  It is preserved in an
   Appendix for the time being and may be moved back to the main body or
   deleted, depending on the decision of the LAMPS WG.

B.1.  MIME Format

   Currently there are two options in discussion:

   1.  The option according to the current S/MIME specification (cf.
       [RFC8551])

   2.  An alternative option that is based on the former "memory hole"
       approach (cf.  [I-D.autocrypt-lamps-protected-headers])

B.1.1.  S/MIME Specification

   Note: This is currently described in the main part of this document.

B.1.1.1.  Alternative Option Autocrypt "Protected Headers" (Ex-"Memory
          Hole")

   An alternative option (based on the former autocrypt "Memory Hole"
   approach) to be considered, is described in
   [I-D.autocrypt-lamps-protected-headers].

   Unlike the option described in Appendix B.1.1, this option does not
   use a "message/RFC822" wrapper to unambiguously delimit the Inner
   Message.

   Before choosing this option, the following two issues must be
   assessed to ensure no interoperability issues result from it:

   1.  How current MIME parser implementations treat non-MIME Header
       Fields, which are not part of the outermost MIME entity and not
       part of a Message wrapped into a MIME entity of media type
       "message/rfc822", and how such Messages are rendered to the user.

       [I-D.autocrypt-lamps-protected-headers] provides some examples
       for testing this.

   2.  MIME-conformance, i.e. whether or not this option is (fully)
       MIME-conformant [RFC2045] ff., in particular also Section 5.1. of
       [RFC2046] on "Multipart Media Type).  In the Bcc header
   field following an excerpt
       of paragraphs that may appear be relevant in up to three different variants:

   1. this context:

         The message only header fields that have defined meaning for body parts
         are those the recipient addresses listed in To or Cc header
       fields, names of which begin with "Content-".  All other
         header fields may be ignored in body parts.  Although they
         should generally be retained if at all possible, they may be
         discarded by gateways if necessary.  Such other fields are
         permitted to appear in body parts but must not include the Bcc header field neither for
       signature calculation nor be depended on.
         "X-" fields may be created for encryption.

   2. experimental or private
         purposes, with the recognition that the information they
         contain may be lost at some gateways.

         NOTE:  The message(s) sent distinction between an RFC 822 Message and a body
         part is subtle, but important.  A gateway between Internet and
         X.400 mail, for example, must be able to tell the recipient addresses in difference
         between a body part that contains an image and a body part
         that contains an encapsulated Message, the Bcc header
       field, body of which depends on is a
         JPEG image.  In order to represent the implementation:

       a) One message for each recipient in latter, the body part
         must have "Content-Type: message/rfc822", and its body (after
         the blank line) must be the Bcc header field
       separately, encapsulated Message, with a Bcc its own
         "Content-Type: image/jpeg" header field containing only field.  The use of similar
         syntax facilitates the address conversion of Messages to body parts,
         and vice versa, but the recipient it is sent to.

       b) The same message for each recipient in distinction between the Bcc header field
       with two must be
         understood by implementors.  (For the special case in which
         parts actually are Messages, a Bcc header field containing "digest" subtype is also
         defined.)

   The MIME structure of an indication such Email Message looks as
       "Undisclosed recipients", but no addresses.

       c) follows:

     <Outer Message Header Section (unprotected)>

     <Outer Message Body (protected)>

       <Inner Message Header Section>

       <Inner Message Body>

   The same message for each recipient following example demonstrates how an Original Message might be
   protected, i.e., the Original Message is contained as Inner Message
   in the Bcc header field
       which does not include Protected Body of an Outer Message.  It illustrates the first
   Body part (of the Outer Message) as a Bcc header field (this "multipart/signed"
   (application/pkcs7-signature) media type:

   Lines are prepended as follows:

   o  "O: " Outer Message Header Section

   o  "I: " Message Header Section
     O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
     O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
     O: Subject: Meeting at my place
     O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
     O: MIME-Version: 1.0
     O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
     O:  protocol="application/pkcs7-signature";
     O:  boundary=boundary-AM

        This is a multipart message in MIME format.
        --boundary-AM
     I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
     I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
     I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@m.example.net>
     I: MIME-Version: 1.0
     I: MMHS-Primary-Precedence: 3
     I: Subject: Meeting at my place
     I: To: somebody@example.net
     I: X-Mailer: Isode Harrier Web Server
     I: Content-Type: text/plain; charset=us-ascii

        This is
       identical an important message that I don't want to 1. / cf. above).

   3. be modified.

        --boundary-AM
        Content-Transfer-Encoding: base64
        Content-Type: application/pkcs7-signature

        [[base-64 encoded signature]]

        --boundary-AM--

   The message stored in the 'Sent'-Folder of the sender, which
       usually contains the Bcc unchanged from Outer Message Header Section is unprotected, while the original message,
       i.e., with all recipient addresses. remainder
   (Outer Message Body) is protected.  The most privacy preserving method Outer Message Body consists
   of the alternatives (2a, 2b, Inner Message (Header Section and
   2c) Body).

   The Inner Message Header Section is to standardize 2a, the same as in (or a subset of) the other cases (2b and 2c),
   information about hidden recipients
   Original Message Header Section (cf.  Section 4.1.2.1).

   The Inner Message Body is revealed via keys.  In any
   case, the message has to be cloned and adjusted depending on same as the
   recipient. Original Message Body.

   The Original Message itself may contain any MIME structure.

Appendix B. C.  Document Changelog

   [[ RFC Editor: This section is to be removed before publication ]]

   o  draft-ietf-lamps-header-protection-01
      *  Add DKG as co-author

      *  Partial Rewrite of Abstract and Introduction [HB/AM/DKG]

      *  Adding definiations for Cryptographic Layer, Cryptographic
         Payload, and Cryptographic Envelope (reference to
         [I-D.dkg-lamps-e2e-mail-guidance]) [DKG]

      *  Enhanced MITM Definition to include Machine- / Meddler-in-the-
         middle [HB]

      *  Relaxed definition of Original message, which may not be of
         type "message/rfc822" [HB]

      *  Move "memory hole" option to the Appendix (on request by Chair
         to only maintain one option in the specification) [HB]

      *  Updated Scope of Protection Levels according to WG discussion
         during IETF-108 [HB]

      *  Obfuscation recommendation only for Subject and Message-Id and
         distinguish between Encrypted and Unencrypted Messages [HB]

      *  Removed (commented out) Header Field Flow Figure (it appeared
         to be confusing as is was) [HB]

   o  draft-ietf-lamps-header-protection-00

      *  Initial version (text partially taken over from
         [I-D.ietf-lamps-header-protection-requirements]

Appendix C. D.  Open Issues

   [[ RFC Editor: This section should be empty and is to be removed
   before publication. ]]

   o  Ensure "protected header" (Ex-Memory-Hole) option is (fully)
      compliant with the MIME standard, in particular also [RFC2046],
      Section 5.1.  (Multipart Media Type) Section 4.1.1.2.

   o  Decide on format of obfuscated HFs, in particular Date HF
      (Section 4.1.4.1)

   o  Impact on spam filtering, if HFs are obfuscated (Section 4.1.4.1) Appendix B.1.1.1.

   o  More examples (e.g. in Section 4.1.7) 4.1.2.5)

   o  Should Outer Message Header Section (as received) be preserved for
      the user?  (Section 4.1.8.2) 4.1.3.2.2)

   o  Decide on whether or not merge requirements from
      [I-D.ietf-lamps-header-protection-requirements] into this
      document.

   o  Decide what parts of [I-D.autocrypt-lamps-protected-headers] to
      merge into this document.

   o  Enhance Introduction Section 1 and Problem Statement (Section 2).

   o  Decide on whether or not specification for more legacy HP
      requirements should be added to this document (Section 3.1.2).

   o  Verify simple backward compatibility case (Receiving Side MIME-
      Conformant) is working; once solution is stable and update
      paragraphs in Section 4.1, Section 3.1.2.1 and Section 4.2.1
      accordingly.

   o  Verify ability to distinguish between Messages with Header
      Protection as specified in this document and legacy clients and
      update Section 3.1 accordingly.

   o  Improve definitions of Protection Levels and enhance list of
      Protection Levels (Section 3.2, Section 4).

   o  Privacy Considerations Section 6

   o  Security Considerations Section 5

Authors' Addresses

   Bernie Hoeneisen
   pEp Foundation
   Oberer Graben 4
   CH-8400 Winterthur
   Switzerland

   Email: bernie.hoeneisen@pep.foundation
   URI:   https://pep.foundation/

   Daniel Kahn Gillmor
   American Civil Liberties Union
   125 Broad St.
   New York, NY  10004
   USA

   Email: dkg@fifthhorseman.net
   Alexey Melnikov
   Isode Ltd
   14 Castle Mews
   Hampton, Middlesex  TW12 2NP
   UK

   Email: alexey.melnikov@isode.com