| Network Working Group | +B. Hoeneisen | +
| Internet-Draft | +pEp Foundation | +
| Intended status: Informational | +A. Melnikov | +
| Expires: January 5, 2021 | +Isode Ltd | +
| + | July 04, 2020 | +
Header Protection for S/MIME
+ draft-ietf-lamps-header-protection-00
Privacy and security issues with email header protection in S/MIME have been identified for some time. However, the desire to fix these issues has only recently been expressed in the IETF LAMPS Working Group. The existing S/MIME specification is to be updated regarding header protection.
+This document describes the problem statement, generic use cases, and the S/MIME specification for header protection.
+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 5, 2021.
+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.
+ + + +A range of protocols for the protection of electronic mail (email) exist, which allow to assess the authenticity and integrity of the 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 of attacks on email, do not offer (full) end-to-end protection to the header section and are not capable of providing privacy for the information contained therein.
+The need for means of Data Minimization, which includes data spareness and hiding all technically concealable information whenever possible, has grown in importance over the past several years.
+A standard for end-to-end protection of the email header section exists for S/MIME version 3.1 and later. (cf. [RFC8551]):
+ + +No mechanism for header protection (HP) has been standardized for PGP/MIME (Pretty Good Privacy) [RFC3156] yet.
+Several varying 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 the opinion that whatever mechanism will be chosen, it should not be limited to S/MIME, but also applicable to PGP/MIME.
+This document describes the problem statement (Section 2), generic use cases (Section 3) and the specification for Header Protection (Section 4).
+[I-D.ietf-lamps-header-protection-requirements] defines the requirements that this specification is based on.
+This document is in early draft state and contains a proposal to base the upcoming discussions on. In any case, the final solution is to be determined by the IETF LAMPS WG.
+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].
+The following terms are defined for the scope of this document:
+ + +The LAMPS charter contains the following Work Item:
+ + +In the following a set of challenges to be addressed:
+[[ TODO: enhance this section, add more items to the following ]]
+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 independently of whether S/MIME, PGP/MIME or any other technology is used to achieve HP.
+Both peers (sending and receiving side) fully support Header Protection as specified in this document or the receiving side is at least compliant with the MIME specification [RFC2045], ff.; cf. Section 4.1.
+The sending side fully supports Header protection as specified in this document, while the receiving side does not support the MIME specification [RFC2045], ff. correctly; see Section 4.2.
+Note: The compatibility of legacy HP systems with this new solutions, and how to handle issues surrounding future maintenance for these legacy systems, will be decided by the LAMPS WG.
+The following protection levels need to be considered:
+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 not contain a cryptographic +signature. ++
This section contains the specification for Header Protection in S/MIME to update and clarifies Section 3.1 of [RFC8551] (S/MIME 4.0).
+Furthermore, it is likely that PGP/MIME [RFC3156] will also incorprorate 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 “signature and encryption”, which is the default to use on the sending side.
+Certain implementations MAY decide to send “signature only” messages, depending on the circumstances and customer requirements. Sending side MAY and receiving sides MUST implement “signature only”.
+It generally is NOT RECOMMENDED to send a message with protection level “encryption only”. On the other hand, messages with protection level “encryption only” might arrive at the receiving side. While not targeted to protection level “encryption only”, this specification is assumed to also function for “encryption only”. Receiving sides SHOULD implement “encryption only”.
+Note: It is for further study whether or not more guidance for handling messages with protection level “encryption only” at the receiving side is needed.
+This section applies to the Interaction (cf. Section 3.1), where all involved parties (sending and receiving side) implement this specification or the receiving side is at least compliant with the MIME specification [RFC2045], ff. (For backward compatibility cases cf. Section 4.2).
+Currently there are two options in discussion:
+ + +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 forwarded and wrapped message, a 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 attachment otherwise.
+The MIME structure of an Email 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 header section and payload of a protected body part might look like. For example, this will be the first body part of a multipart/signed message or the signed and/or encrypted payload of the application/pkcs7-mime body part. Lines prepended by “O: “ are the Outer Message Header Section. Lines prepended by “I: “ are the Inner Message Header Section. Lines prepended by “W: “ are the 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@matt.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=.cbe16d2a-e1a3-4220-b821-38348fc97237 + + This is a multipart message in MIME format. + --.cbe16d2a-e1a3-4220-b821-38348fc97237 + 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@matt.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. + + --.cbe16d2a-e1a3-4220-b821-38348fc97237 + Content-Transfer-Encoding: base64 + Content-Type: application/pkcs7-signature + + [[base-64 encoded signature]] + + --.cbe16d2a-e1a3-4220-b821-38348fc97237-- + ++
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” containing a Content-Type header field parameter “forwarded=no” followed by an empty line.
+The Inner Message Header Section is the same as (or a subset of) the Original Message Header Section (cf. Section 4.1.2).
+The Inner Message Body is the same as the Original Message Body.
+The Original Message itself may contain any MIME structure.
+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 Section 4.1.1.1, this option does not use a “message/RFC822” wrapper to unambigously delimit the Inner Message.
+Note: it is for further study, whether or not this option is (fully) compliant with the MIME standard, in particuar also [RFC2046], Section 5.1. (Multipart Media Type).
+The MIME structure of an Email message looks as follows:
++ <Outer Message Header Section (unprotected)> + + <Outer Message Body (protected)> + + <Inner Message Header Section> + + <Inner Message Body> + ++
The following example demonstrates how header section and payload of a protect body part might look like. For example, this will be the first body part of a multipart/signed message or the signed and/or encrypted payload of the application/pkcs7-mime body part. Lines prepended by “O: “ are the outer header section. Lines prepended by “I: “ are the inner header section.
++ O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time) + O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.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=.cbe16d2a-e1a3-4220-b821-38348fc97237 + + This is a multipart message in MIME format. + --.cbe16d2a-e1a3-4220-b821-38348fc97237 + 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@matt.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. + + --.cbe16d2a-e1a3-4220-b821-38348fc97237 + Content-Transfer-Encoding: base64 + Content-Type: application/pkcs7-signature + + [[base-64 encoded signature]] + + --.cbe16d2a-e1a3-4220-b821-38348fc97237-- + ++
The Outer Message Header Section is unprotected, while the remainder (Outer Message Body) is protected. The Outer Message Body consists of the Inner Message (Header Section and Body).
+The Inner Message Header Section is the same as (or a subset of) the Original Message Header Section (cf. Section 4.1.2).
+The Inner Message Body is the same as the Original Message Body.
+The Original Message itself may contain any MIME structure.
+It is RECOMMEND that the Inner Messages contains all the Header Fields of the Original Message with the exception of the following Header Field, which MUST NOT be included to the Inner Message nor to any other protected part of the message:
+ + +[[ TODO: Bcc handling needs to be further specified (see also Appendix A.1). Certain MUAs cannot properly decrypt messages with Bcc recipients. ]]
+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 of the wrapper MUST be “message/RFC822” and SHOULD contain the Content-Type header field parameter “forwarded=no” as defined in [I-D.melnikov-iana-reg-forwarded]. The wrapper delimits unambigously the Inner Message from the rest of the message.
+To maximize Privacy, it is strongly RECOMMENDED to follow the principle of Data Minimization (cf. Section 2.1).
+However, the Outer Message Header Section SHOULD contain the Essential Header Fields and, in addition, MUST contain the Header Fields of the MIME Header Section part to describe the encryption or signature as per [RFC8551].
+The following Header Fields are defined as the Essential Header Fields:
+ + +Some of these Header Fields are needed by the Transport (e.g. to determine the destination). Furthermore, not including certain Header Fields may trigger spam detection to flag the message as spam 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 SHOULD be prefered 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:
+ + +The following example shows the MIME Header Section part of an S/MIME signed 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.:
+ + +If the values of the following Outer Message Header Fields are obfuscated, those SHOULD assume 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 of the same week. ]]
+In certain implementations also the From, To, and/or Cc Header Field MAY be obfucated. Those may be replaced by e.g.
+ + +Such implementations need to ensure that the Transport has access to these Header Fields in clear text and is capable of processing those.
+A use case for obfuscation of all Outer Message Header Fields is mixnet netwerks, i.e. “onion routing” for email (e.g.[pEp.mixnet]).
+Note: It is for further study to what extent Header Field obfuscation (adversely) impacts spam filtering.
+The Receiving User Facing Message is constructed as follows:
+ + +[[ TODO: Do we need to take special care for HFs, which may appear multiple times, e.g. Received HF? ]]
+The Following figure depicts the different message representations (OrigM, InnerM, OuterM, RUFM) and which parts those are constructed from:
++OrigM InnerM Outer(S) OuterM(R) RUFM + + <Trace-HF> > <Trace-HF> + From (OrigM) = From + To (OrigM) = To + Cc (OrigM) = Cc + Bcc (OrigM) = Bcc* > 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:
+ + +For a protected message the following steps are applied before a message is handed over to the Transport:
+The entity applying protection to a message must decide:
+ + +Depending on the decision in Section 4.1.7.1, compose the Outer Message Header Section. (Note that this also includes the necessary MIME Header Section part for the following protection layer.)
+Outer Header Fields that are not obfuscated should contain the same values as in the Original Message (except for MIME Header Section part, which depends on the protection level selected in Section 4.1.7.1).
+Depending on the Protection Level selected 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 Transport.
+[[ TODO: Example ]]
+When a protected message is received the following steps are applied:
+Depending on the protection level the received message is decrypted and/or its signature is checked as per [RFC8551].
+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 to the user.
+Note: It is for further study whether and, if yes, how the Outer Message Header Section (as received from the Transport) is preserved for the user.
+[I-D.autocrypt-lamps-protected-headers] describes a possibility to achieve backward compatibility with existing S/MIME (and PGP/MIME) implementations unaware of this specification (Legacy Display). It mainly focuses on email clients that do not render emails using header protection (nicely) and 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] applies 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 reveal, the Legacy Display format described in [I-D.autocrypt-lamps-protected-headers] may serve as a basis to mitigate those (backward compatibility use case).
+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).
+[[ TODO ]]
+[[ TODO ]]
+This document requests no action from IANA.
+[[ RFC Editor: This section may be removed before publication. ]]
+The authors would like to thank the following people who have provided helpful comments and suggestions for this document: Claudio Luck, David Wilson, Hernani Marques, Krista Bennett, Kelly Bristol, Robert Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang.
+| [I-D.ietf-lamps-header-protection-requirements] | ++Melnikov, A. and B. Hoeneisen, "Problem Statement and Requirements for Header Protection", Internet-Draft draft-ietf-lamps-header-protection-requirements-01, 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. | +
| [RFC2046] | ++Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, 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. | +
| [RFC5322] | ++Resnick, P., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008. | +
| [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. | +
| [I-D.autocrypt-lamps-protected-headers] | ++Einarsson, B., juga, j. and D. Gillmor, "Protected Headers for Cryptographic E-mail", Internet-Draft draft-autocrypt-lamps-protected-headers-02, December 2019. | +
| [I-D.melnikov-iana-reg-forwarded] | ++Melnikov, A. and B. Hoeneisen, "IANA Registration of Content-Type Header Field Parameter 'forwarded'", Internet-Draft draft-melnikov-iana-reg-forwarded-00, November 2019. | +
| [I-D.pep-email] | ++Marques, H., "pretty Easy privacy (pEp): Email Formats and Protocols", Internet-Draft draft-marques-pep-email-02, October 2018. | +
| [pEp.mixnet] | ++pEp Foundation, "Mixnet", June 2020. | +
| [RFC3156] | ++Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, August 2001. | +
| [RFC4949] | ++Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007. | +
| [RFC6376] | ++Crocker, D., Hansen, T. and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011. | +
| [RFC7208] | ++Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014. | +
| [RFC7489] | ++Kucherawy, M. and E. Zwicky, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015. | +
Messages containing at least one recipient address in the Bcc header field may appear in up to three different variants:
+ + +The most privacy preserving 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.
+[[ RFC Editor: This section is to be removed before publication ]]
+ + +[[ RFC Editor: This section should be empty and is to be removed before publication. ]]
+ + +The pretty Easy privacy (pEp) propositions for email are based upon already existing email and encryption formats (as PGP/MIME) and designed to allow for easy implementable and interoperable opportunistic encryption: this ranges from key distribution, secret key synchronization between own devices to mechanims of metadata and content protection. This is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly in scope of this document.
+The pretty Easy privacy (pEp) propositions for email are based upon already existing email and encryption formats (as PGP/MIME) and designed to allow for easy implementable and interoperable opportunistic encryption: this ranges from key distribution, secret key synchronization between own devices to mechanisms of metadata and content protection. This is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly in scope of this document.
The goal of pEp for email is to automate operations in order to make email encryption usable by a wider range of Internet users, to achieve wide application of confidentiality and privacy practices in the real world.
The proposed operations and formats are targeted to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp).
A reference implementation of pEp for email is available for all major platforms and it has been ported to many programming languages (cf. Section 11 for an overview).
All relevant pEp mechanisms and state information about other peers MUST be held locally, on a peer’s end-device. There MUST NOT be any reliance on a email server or even a centralized network component to hold relevant information for peers to be able to communicatate or to authenticate themselves. Email servers (like, SMTP or IMAP) are only used as transport infrastructure for messages, but MUST not be relevant to hold actual state between peers.
+All relevant pEp mechanisms and state information about other peers MUST be held locally, on a peer’s end-device. There MUST NOT be any reliance on a email server or even a centralized network component to hold relevant information for peers to be able to communicate or to authenticate themselves. Email servers (like, SMTP or IMAP) are only used as transport infrastructure for messages, but MUST not be relevant to hold actual state between peers.
In pEp for email, a user is a person or group which can have one or more identities, each represented by email addresses. Every identity has an own key attached to it. An email address can also be an alias for an already existing identity, in which case the same key is attached to it.
-All information about communication partners, like identities, keys and aliases MUST be held on a user’s end-device as state information. This SHOULD be done using a structured format, to faciliate the synchronization of state information across various devices, taking into account multi-device scenarios, which are common today.
+All information about communication partners, like identities, keys and aliases MUST be held on a user’s end-device as state information. This SHOULD be done using a structured format, to facilitate the synchronization of state information across various devices, taking into account multi-device scenarios, which are common today.
In pEp’s reference implementation (cf. Section 11), keys are hold using the key store of the cryptographic library used, while peer-specific state information, including trust information is held in a simple relational database.
[[ TODO: Check optimal order the following sections. ]]
An earlier variant of PEF-1.0 started with a “multipart/mixed” MIME node, which in case of a simple text-only email without attachments and other MIME entities has
(1) a “text/plain” MIME entity with the PGP-encrypted content, and
-(2) the sender’s tranferable public key at the very end.
+(2) the sender’s transferable public key at the very end.
This variant MUST NOT be produced anymore.
An example of this deprecated variant of PEF-1.0 looks as follows:
@@ -977,7 +977,7 @@ Content-Disposition: inline; filename="msg.asc"
Decrypting “msg.asc” results in a multipart/mixed node, with three elements:
(1) a text part indicating this is the encapsulated message
-(2) the origninal message encapsulated by a “message/rfc822” MIME entity, and
+(2) the original message encapsulated by a “message/rfc822” MIME entity, and
(3) the transferable sender’s public key in ASCII-armored format.
An unwrapped example looks like this:
@@ -1034,9 +1034,9 @@ Content-Disposition: attachment; filename="pEpkey.asc"2.9.4. pEp Email Format 2.1
-pEp Email Format 2.1 (PEF-2.1) introduces further pEp-specific header fields to the inner message, which help to determine the behaviour between pEp users.
+pEp Email Format 2.1 (PEF-2.1) introduces further pEp-specific header fields to the inner message, which help to determine the behavior between pEp users.
In normal interpersonal messaging those additional header fields are:
-(1) “X-pEp-Wrapped-Message-Info: INNER” header field stating that the message carrying this is to be considered the most inner message containing the original email (this is particulary relevant for mixnet or other scenarios of nested messaging; cf. [pEp.mixnet])
+(1) “X-pEp-Wrapped-Message-Info: INNER” header field stating that the message carrying this is to be considered the most inner message containing the original email (this is particularly relevant for mixnet or other scenarios of nested messaging; cf. [pEp.mixnet])
(2) “X-pEp-Sender-FPR” header field with the value set to sender’s full 160-bit public key fingerprint (e.g., “1234567890ABCDEF1234567890ABCDEF12345678”), and
(3) the “X-pEp-Version” header field set to version “2.1”.
As with PEF-2.0 Section 2.9.3, in PEF-2.1 the actual email (inner message) is encapsulated by a MIME entity (“Content-Type: message/rfc822”), which is the second part of a “multipart/mixed” MIME node. The first part of this MIME node contains a “text/plain” MIME entity, which SHOULD be used to inform about the nature of this format (in case a non-pEp client encounters in the mailbox). It MAY be used to carry the intended subject of the inner message (which is not done in current reference implementations). Like with the PEF-1.0 (cf. Section 2.9.2) and PEF 2.0 (cf. Section 2.9.3), the third (and last) part of this “multipart/mixed” MIME node MUST contain the sender’s public key.
@@ -1140,7 +1140,7 @@ Content-Disposition: attachment; filename="pEpkey.asc"Messages sent or received in unencrypted form, SHOULD NOT be saved in encrypted form on the email server: this reflects the Privacy Status the user encountered when sending or receiving the email and thus meets the user’s expectations.
Instead, message drafts MUST always be saved with the identity’s public key.
Other messages sent and received MUST be saved encrypted by default: for most end-user scenarios, the servers users work with, are considered untrusted.
-For trusted environments (e.g., in organizations) and to conform to legally binding archivign regulations, pEp implementations MUST provide a “Trusted Server” option. With the user’s explicit consent (opt-in), unencrypted copies of the Messages MUST be held on the mail servers controlled by the organization.
+For trusted environments (e.g., in organizations) and to conform to legally binding archiving regulations, pEp implementations MUST provide a “Trusted Server” option. With the user’s explicit consent (opt-in), unencrypted copies of the Messages MUST be held on the mail servers controlled by the organization.
3. Key Management
@@ -1148,7 +1148,7 @@ Content-Disposition: attachment; filename="pEpkey.asc" 3.1. Key GenerationA pEp-enabled Mail User Agent MUST consider every email account as an new identity: for each identity, a different key pair MUST be created automatically if no key material with sufficient length is available. By default, RSA-4096 key pairs for OpenPGP encryption [RFC4880] SHOULD be generated automatically for each email account. However, the key length MUST be at least 2048 bits. Elliptic curve keys with at least 256 bits MUST be supported, but SHOULD NOT yet be generated and announced by default for interoperability reasons.
-If for an identity there’s an RSA keypair with less than 2048 bits, new keys MUST be generated.
+If for an identity there’s an RSA key pair with less than 2048 bits, new keys MUST be generated.
3.2. Private Keys
@@ -1490,7 +1490,7 @@ Content-Disposition: attachment; filename="pEpkey.asc"
| Network Working Group | +H. Marques | +
| Internet-Draft | +pEp Foundation | +
| Intended status: Standards Track | +July 04, 2020 | +
| Expires: January 5, 2021 | ++ |
pretty Easy privacy (pEp): Email Formats and Protocols
+ draft-pep-email-00
The pretty Easy privacy (pEp) propositions for email are based upon already existing email and encryption formats (as PGP/MIME) and designed to allow for easy implementable and interoperable opportunistic encryption: this ranges from key distribution, secret key synchronization between own devices to mechanisms of metadata and content protection. This is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly in scope of this document.
+The goal of pEp for email is to automate operations in order to make email encryption usable by a wider range of Internet users, to achieve wide application of confidentiality and privacy practices in the real world.
+The proposed operations and formats are targeted to Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp).
+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 5, 2021.
+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.
+ + + +This document contains propositions for implementers of Mail User Agents (MUAs) seeking to support pretty Easy privacy (pEp) specifically for email [RFC5322]. All the propositions of [I-D.birk-pep] also apply to pEp for email. In this document, requirements are outlined for MUAs wanting to establish interoperability and/or to implement pEp for email.
+pEp for email builds upon the cryptographic security services offered by PGP/MIME [RFC3156]. The most important goal is
+(1) to maximize privacy in the email context, at least for those Internet actors deploying and using the pretty Easy privacy approach, and
+(2) to provide ways to stay compatible to legacy or other approaches in automatic email encryption to any privacy-preserving extent possible.
+Interoperability with S/MIME [RFC8551] is a also goal, but there is no specification or Running Code so far.
+Current (decade-old) tools and implementations have failed to provide a sufficient level of usability to ordinary Internet users, such that end-to-end email encryption is seldomly used.
+Whereas OpenPGP [RFC4880] using PGP/MIME [RFC3156] offers good encryption, for message contents at least, more work is needed to achieve the following three objectives of pretty Easy privacy (pEp):
+ + +A reference implementation of pEp for email is available for all major platforms and it has been ported to many programming languages (cf. Section 11 for an overview).
+This document describes the pEp for email protocols. While it specifies details particularly related to pEp for email, it basically inherits the structure of [I-D.birk-pep], which describes the general concepts of pEp on a higher level.
+For protocol details, constituent pEp mechanisms also applying for email can be found in documents like [I-D.marques-pep-handshake]) showing how trust between any two pEp users can be established, [I-D.marques-pep-rating] describing privacy indications which can be helpful for regular Internet users or [I-D.pep-keysync] outlining pEp’s peer-to-peer protocol to synchronize secret key material belonging to the same account and user across various (very different) end-devices.
+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].
+The following terms are defined for the scope of this document:
+ + +In addition to the Protocol’s Core Design Principles outlined in [I-D.birk-pep], the following sections on design principles are applicable to pEp for email applications.
+The pEp formats and protocols aim to maximize privacy. Where privacy goals contradict with security goals, the privacy goals MUST have precedence.
+Examples:
+ + +Data Minimization includes data spareness and hiding of all technically concealable information whenever possible.
+Email metadata (i.e., headers) MUST either be omitted or encrypted whenever possible.
+The PGP/MIME specification as described in [RFC3156] provides little facilities for metadata protection: while the email body gets protected, the header section remains unprotected. However, it is possible to protect also the information contained in header field values by encapsulating the whole message into a MIME entity to be signed and encrypted.
+The S/MIME Message Specification [RFC8551], on the other hand, defines a way to protect also the header section in addition to the content of a message:
+ + +Implementers of pEp SHOULD be liberal in accepting non-pEp formats to encrypt email contents and metadata and MUST use the strict and interoperable pEp Email Format 1.0 (cf. Section 2.9.2) for any outgoing communication to non-pEp users. For communication between pEp users, more privacy-preserving formats (cf. Section 2.9) MUST be used. pEp Email Formats 2.0 and newer SHOULD NOT be used towards users which were not recognized as pEp users (cf. Section 2.9.5), because for such non-pEp users those formats are likely to produce unwanted visual artefacts.
+For interpersonal messaging, an email endpoint in pEp is the MUA on a user’s end-device: that is, encryption and decryption of messages MUST be executed on a user’s end-device and MUST NOT depend on any third-party network infrastructure (i.e., any infrastructure outside a user’s direct control).
+[[ TODO: Add enterprise settings with Key Escrow / Extra Keys ]]
+All relevant pEp mechanisms and state information about other peers MUST be held locally, on a peer’s end-device. There MUST NOT be any reliance on a email server or even a centralized network component to hold relevant information for peers to be able to communicate or to authenticate themselves. Email servers (like, SMTP or IMAP) are only used as transport infrastructure for messages, but MUST not be relevant to hold actual state between peers.
+[[ TODO: Make clear there is a way to synchronize trust in a peer-to-peer fashion, by using the Trust Sync mechanism. ]]
+[[ TODO: Add here what is specific to email ]]
+In pEp for email, a user is a person or group which can have one or more identities, each represented by email addresses. Every identity has an own key attached to it. An email address can also be an alias for an already existing identity, in which case the same key is attached to it.
+All information about communication partners, like identities, keys and aliases MUST be held on a user’s end-device as state information. This SHOULD be done using a structured format, to facilitate the synchronization of state information across various devices, taking into account multi-device scenarios, which are common today.
+In pEp’s reference implementation (cf. Section 11), keys are hold using the key store of the cryptographic library used, while peer-specific state information, including trust information is held in a simple relational database.
+[[ TODO: Check optimal order the following sections. ]]
+In pEp for email the SMTP address (e.g., mailto:alice@example.org) constitutes the network address.
+For now, a key in pEp for email is an OpenPGP key. Each identity has a default key attached to it. This is the public key to be used to encrypt communications to it.
+A user in pEp for email is a specific person or group and device owner which can have one or more identities.
+Each user has at last one identity.
+An identity in pEp for email is represented by an email address URI, like mailto:alice@example.org.
+This can be Alice with her real name, using this identity for private purposes. Should Alice create another email address, like anonymous@example.com, this is considered a second identity. By default, pEp-enabled MUAs MUST create a new key pair when a new email account is being configured, such as to not allow correlation by using the same key. If in turn, Alice wants different addresses of her to be collapsed into one single identity with one single key, then the user has to configure them as aliases.
+For other email URIs pointing to the same identity, see the alias (cf. Section 2.8.5) concept.
+Aliases share the same key and identity, e.g., the same key might be used for mailto:alice@example.org as well as for mailto:alice@example.com. That is, both addresses refer to the same identity.
+The pEp Email Formats 1.0, 2.0 and 2.1 are restricted MIME-based email formats, which ensure messages to be signed and encrypted. In accordance with pEp’s privacy (and not security) focus, signed-only messages MUST NOT be produced (cf. Section 2.1). pEp-enabled clients MUST be able to render all pEp Email Formats properly: for outgoing communications, the most privacy-preserving format available is to be used, taking interoperability (cf. Section 2.4) into account.
+Since pEp Email Format 2.0, a compatibility format (i.e., pEp Email Format 1.0, cf. Section 2.9.2) exists, which SHOULD be applied towards non-pEp users, for which trustworthy public keys are available according to the local database.
+In case no trustworthy encryption key is available, an unencrypted, unsigned MIME email is sent out. As in all pEp formats, also this (unprotected) message MUST contain the sender’s public key, unless Passive Mode (cf. Section 7.1) is active.
+All pEp Email Formats include a “pEpkey.asc” file attachment holding the sender’s OpenPGP public key in ASCII-armored format, which is suitable for manual key import by non-pEp users. Thus, a user of any OpenPGP-enabled MUA is able to manually import the public key and engage in end-to-end encryption with the pEp sender. MUA implementers of PGP-capable email clients, even when not fully supporting pEp’s protocols, are encouraged to automatically import the key such that the user can immediately engage in opportunistic encryption.
+In pEp’s reference implementation the subject is set to “pEp” (or alternatively to its UTF-8 representation as “=?utf-8?Q?p=E2=89=A1p?=”). However, the subject’s value of the outer message MUST be ignored. Therefore, the subject can be set to any value (e.g., “…” as used in other implementations).
+This is the format to be used when unencrypted messages are sent out.
+The unencrypted pEp format is a “multipart/mixed” MIME format, which by default ensures the delivery of the sender’s public key as an attachment (“Content-Disposition: attachment”).
+A simple plaintext email looks like the following:
++From: Alice <alice@example.org> +To: Bob <bob@example.org> +Date: Tue, 31 Dec 2019 05:05:05 +0200 +X-pEp-Version: 2.1 +MIME-Version: 1.0 +Subject: Saying Hello +Content-Type: multipart/mixed; boundary="boundary" + +--boundary +Content-Type: text/plain; charset="utf-8" +Content-Transfer-Encoding: quoted-printable + +Hello Bob + +If you reply to this email using a pEp-enabled client, I will +be able to send you that sensitive material I talked you +about. + +Have a good day! + +Alice + +-- +Sent with pEp für Android. + +--boundary +Content-Type: application/pgp-keys; name="pEpkey.asc" +Content-Transfer-Encoding: base64 +Content-Disposition: attachment; filename="pEpkey.asc"; size=2639 + +-----BEGIN PGP PUBLIC KEY BLOCK----- + +[...] + +-----END PGP PUBLIC KEY BLOCK----- + +--boundary-- ++
[[ TODO, feedback roker: the size parameter is redundant, useless and can even be counter-productive: it should not be necessary that the receiver relies on this parameter; OpenPGP has own mechanisms to ensure a key is protected against damages ]]
+pEp Email Format 1.0 (PEF-1.0) is an encrypted and signed MIME format, which by default ensures:
+ + +PEF-1.0 has a “multipart/encrypted” MIME node on the wire format with an OpenPGP encrypted and signed filename “msg.asc” with attribute “Content-Disposition: inline”.
+The subject is the only header field that can be protected with PEF-1.0. To achieve its protection, the real subject value is added to the top of the content section of the very first MIME entity with media type “text/plain”, that is encrypted, e.g.:
+ + +Thus, legacy clients not aware of pEp’s subject encryption, still display the actual subject (in the above example: “Credentials”) to the user. Whenever the first encrypted “text/plain” MIME entity contains such a subject line, pEp-implementing MUAs MUST render it to the user. Note that also lines starting with “subject:” or “SUBJECT:” are to be rendered (as with header fields, this is case-insensitive).
+A pEp-enabled MUA MUST add the “X-pEp-Version” header field with its highest value (preferably with value “2.1” as for pEp Email Format 2.1 Section 2.9.4) when producing this format. Herewith, a pEp-enabled MUA announce its capability to receive and render more privacy-preserving formats. Upgrading both sides to the highest version of the pEp Email Format allows pEp-enabled MUAs for best possible protection of metadata. For non-pEp MUAs it is OPTIONAL to add the “X-pEp-Version: 1.0” header field. However, this format is implicitly assumed (if this header field is not present).
+Please note that for messages between pEp- and non-pEp clients the subject encryption MAY be disabled, sacrificing usability (avoiding artefacts for receiving non-pEp clients) over privacy.
+PEF-1.0 is also considered pEp’s compatibility format towards non-pEp clients.
+A PEF-1.0 example looks as follows:
++From: Alice <alice@example.org> +To: Bob <bob@example.org> +Date: Wed, 1 Jan 2020 23:23:23 +0200 +X-pEp-Version: 1.0 +MIME-Version: 1.0 +Subject: pEp +Content-Type: multipart/encrypted; boundary="boundary1"; + protocol="application/pgp-encrypted" + +--boundary1 +Content-Type: application/pgp-encrypted + +Version: 1 + +--boundary1 +Content-Type: application/octet-stream +Content-Transfer-Encoding: 7bit +Content-Disposition: inline; filename="msg.asc" + +-----BEGIN PGP MESSAGE----- + +[...] + +-----END PGP MESSAGE----- + +--boundary-- ++
Decrypting the enclosed “msg.msc” part yields the following:
++MIME-Version: 1.0 +Content-Type: multipart/mixed; boundary="boundary2" +--boundary2 +Content-Type: text/plain; charset="utf-8" +Content-Transfer-Encoding: quoted-printable +Content-Disposition: inline; filename="msg.txt" + +Subject: Credentials + +Dear Bob + +Please use "bob" with the following password to access the wiki site: + +correcthorsebatterystaple + +Please reach out if there are any issues and have a good day! + +Alice + +--boundary2 +Content-Type: application/pgp-keys +Content-Disposition: attachment; filename="pEpkey.asc" + +-----BEGIN PGP PUBLIC KEY BLOCK----- + +[...] + +-----END PGP PUBLIC KEY BLOCK----- + +--boundary2-- ++
Note that the user-intended subject value is encrypted in the first “text/plain” MIME entity under the “multipart/mixed” MIME node.
+An earlier variant of PEF-1.0 started with a “multipart/mixed” MIME node, which in case of a simple text-only email without attachments and other MIME entities has
+(1) a “text/plain” MIME entity with the PGP-encrypted content, and
+(2) the sender’s transferable public key at the very end.
+This variant MUST NOT be produced anymore.
+An example of this deprecated variant of PEF-1.0 looks as follows:
++From: Alice <alice@example.org> +To: Bob <bob@example.org> +Date: Wed, 1 Jan 2020 23:23:23 +0200 +X-pEp-Version: 1.0 +MIME-Version: 1.0 +Subject: pEp +Content-Type: multipart/mixed; boundary="boundary" + +--boundary +Content-Type: application/pgp-encrypted + +Version: 1 + +--boundary +Content-Type: text/plain; charset="utf8" +Content-Transfer-Encoding: 7bit + +-----BEGIN PGP MESSAGE----- +[...] +-----END PGP MESSAGE----- + +--boundary +Content-Type: application/pgp-keys; name="pEpkey.asc" +Content-Transfer-Encoding: 7bit +Content-Disposition: attachment; filename="pEpkey.asc" + +-----BEGIN PGP PUBLIC KEY BLOCK----- + +[...] + +-----END PGP PUBLIC KEY BLOCK----- + +--boundary-- ++
There, decrypting the PGP encrypted text/plain element yields a text like the following; most obviously, the intended subject line is now visible:
++Subject: Credentials + +Dear Bob + +Please use "bob" with the following password to access the wiki site: + +correcthorsebatterystaple + +Please reach out if there are any issues and have a good day! + +Alice ++
pEp Email Format 2.0 (PEF-2.0) is a strict MIME format, which by default ensures:
+ + +In PEF-2.0, the actual email (inner message) is encapsulated by a MIME entity (“Content-Type: message/rfc822”), which is the second part of a “multipart/mixed” MIME node. The first part of this MIME node contains a “text/plain” MIME entity, including a marker text “pEp-Message-Wrapped-Info: OUTER” (in its MIME content). This is used for proper displaying and mapping of the nested message and its encrypted header fields. Like with the PEF-1.0 (cf. Section 2.9.2), the third (and last) part of the “multipart/mixed” MIME node MUST contain the sender’s public key.
+The “multipart/mixed” MIME node is encrypted inside yet another MIME node (“Content-Type: multipart/encrypted”, cf. [RFC1847] / [RFC3156]), which is the body part of the outer message.
+Thus, the whole header section of the inner message can be fully preserved, not only encrypted, but also signed. In the outer message, however, when communicating with pEp users all header fields not needed MUST be omitted to the fullest extent possible.
+Once encrypted, only the outer message consisting of the (minimal) outer header section and the “multipart/encrypted” MIME entity as body with a application/octet-stream “Content-Type” with name “msg.asc” is visible on the wire.
+If the receiving side is not a known pEp-enabled MUA, but a trustworthy public key is available, PEF-1.0 (cf. Section 2.9.2) MUST be used to send the email.
+In any case, the “X-pEp-Version” header field MUST be set to version 2.0, as the highest version the sender supports.
+The following example shows a PEF-2.0 multipart/encrypted email, signed and encrypted, as an 7bit octet stream with a filename “msg.asc”, with “Content-Disposition: inline”. In within that, the original email message is fully contained in encrypted form (like this, also the subject line gets encrypted). The support of version 2.0 is announced in the “X-pEp-Version” header field (in this example, 2.0 is the newest pEp Email Format the pEp-enabled MUA is able to produce and render):
++From: Alice <alice@example.org> +To: Bob <bob@example.org> +Date: Wed, 1 Jan 2020 23:23:23 +0200 +X-pEp-Version: 2.0 +MIME-Version: 1.0 +Subject: pEp +Content-Type: multipart/encrypted; boundary="boundary1"; + protocol="application/pgp-encrypted" + +--boundary1 +Content-Type: application/pgp-encrypted + +Version: 1 + +--boundary1 +Content-Type: application/octet-stream +Content-Transfer-Encoding: 7bit +Content-Disposition: inline; filename="msg.asc" + +-----BEGIN PGP MESSAGE----- + +[...] + +-----END PGP MESSAGE----- + +--boundary-- ++
Decrypting “msg.asc” results in a multipart/mixed node, with three elements:
+(1) a text part indicating this is the encapsulated message
+(2) the original message encapsulated by a “message/rfc822” MIME entity, and
+(3) the transferable sender’s public key in ASCII-armored format.
+An unwrapped example looks like this:
++MIME-Version: 1.0 +Content-Type: multipart/mixed; boundary="boundary2" + +--boundary2 +Content-Type: text/plain; charset="utf-8" +Content-Disposition: inline; filename="msg.txt" + +pEp-Wrapped-Message-Info: OUTER + +--boundary2 +Content-Type: message/rfc822 + +Message-ID: <pEp.1234> +Date: Wed, 1 Jan 2020 23:23:23 +0200 +Subject: Credentials +X-pEp-Version: 2.0 +MIME-Version: 1.0 +Content-Type: multipart/mixed; boundary="boundary3" + +--boundary3 +Content-Type: text/plain; charset="utf-8" +Content-Transfer-Encoding: quoted-printable + +pEp-Wrapped-Message-Info: INNER + +Dear Bob + +Please use "bob" with the following password to access the wiki site: + +correcthorsebatterystaple + +Please reach out if there are any issues and have a good day! + +Alice + +--boundary3-- + +--boundary2 + +Content-Type: application/pgp-keys +Content-Disposition: attachment; filename="pEpkey.asc" + +-----BEGIN PGP PUBLIC KEY BLOCK----- + +[...] + +-----END PGP PUBLIC KEY BLOCK----- + +--boundary2-- ++
pEp Email Format 2.1 (PEF-2.1) introduces further pEp-specific header fields to the inner message, which help to determine the behavior between pEp users.
+In normal interpersonal messaging those additional header fields are:
+(1) “X-pEp-Wrapped-Message-Info: INNER” header field stating that the message carrying this is to be considered the most inner message containing the original email (this is particularly relevant for mixnet or other scenarios of nested messaging; cf. [pEp.mixnet])
+(2) “X-pEp-Sender-FPR” header field with the value set to sender’s full 160-bit public key fingerprint (e.g., “1234567890ABCDEF1234567890ABCDEF12345678”), and
+(3) the “X-pEp-Version” header field set to version “2.1”.
+As with PEF-2.0 Section 2.9.3, in PEF-2.1 the actual email (inner message) is encapsulated by a MIME entity (“Content-Type: message/rfc822”), which is the second part of a “multipart/mixed” MIME node. The first part of this MIME node contains a “text/plain” MIME entity, which SHOULD be used to inform about the nature of this format (in case a non-pEp client encounters in the mailbox). It MAY be used to carry the intended subject of the inner message (which is not done in current reference implementations). Like with the PEF-1.0 (cf. Section 2.9.2) and PEF 2.0 (cf. Section 2.9.3), the third (and last) part of this “multipart/mixed” MIME node MUST contain the sender’s public key.
+This “multipart/mixed” MIME node is encrypted inside yet another MIME node (“Content-Type: multipart/encrypted”, cf. [RFC1847] / [RFC3156]), which is the body part of the outer message.
+An caveat of PEF-2.1 is that message rendering varies considerably across different MUAs. This is relevant as it might happen that a non-pEp MUA encounters a PEF-2.1 message (e.g., if a pEp-enabled client was used in the past). No standard is currently available which enables MUAs to reliably determine whenever a nested “message/rfc822” MIME entity is meant to render the contained email message, or if it was effectively intended to be forwarded as an attachment, where a user needs to click on in order to see its content. To help unaware MUAs, a Content-Type header field parameter with name “forwarded” as per [I-D.melnikov-iana-reg-forwarded] is added to the Content-Type header field. MUAs can use this to distinguish between a forwarded message and a nested message (i.e., using “forwarded=no”).
+When the receiving peer was registered as being only PEF-2.0-capable, the message must be sent in PEF-2.0 (cf. Section 2.9.3). The reason for this is that pEp-enabled MUAs which are only PEF-2.0-capable rely on the plaintext “pEp-Message-Wrapped-Info: OUTER” and “pEp-Message-Wrapped-Info: INNER” markers to properly display and map the nested message and its encrypted header fields.
+As with PEF-1.0, if the receiving side is not a known pEp-enabled MUA, but a trustworthy public key is available, PEF-1.0 (cf. Section 2.9.2) MUST be used to send the email.
+In any case, the “X-pEp-Version” header field MUST be set to version 2.1, as the highest version the sender supports.
+This is an example of what the format looks like between two PEF-2.1-capable clients:
++From: Alice <alice@example.org> +To: Bob <bob@example.org> +Date: Wed, 1 Jan 2020 23:23:23 +0200 +X-pEp-Version: 2.1 +MIME-Version: 1.0 +Subject: pEp +Content-Type: multipart/encrypted; boundary="boundary1"; + protocol="application/pgp-encrypted" + +--boundary1 +Content-Type: application/pgp-encrypted + +Version: 1 + +--boundary1 +Content-Type: application/octet-stream +Content-Transfer-Encoding: 7bit +Content-Disposition: inline; filename="msg.asc" + +-----BEGIN PGP MESSAGE----- + +[...] + +-----END PGP MESSAGE----- + +--boundary1-- ++
Unwrapping the “multipart/encrypted” MIME node, yields this:
++MIME-Version: 1.0 +Content-Type: multipart/mixed; boundary="boundary2" + +--boundary2 +Content-Type: text/plain; charset="utf-8" +Content-Disposition: inline; filename="msg.txt" + +This message was encrypted with pEp (https://pep.software). If you +are seeing this message, your client does not support raising message +attachments. Please click on the message attachment to view it, +or better yet, consider using pEp! + +--boundary2 +Content-Type: message/rfc822; forwarded="no" + +Message-ID: <pEp.1234> +Date: Wed, 1 Jan 2020 23:23:23 +0200 +Subject: Credentials +X-pEp-Version: 2.1 +X-pEp-Wrapped-Message-Info: INNER +X-pEp-Sender-FPR: 1234567890ABCDEF1234567890ABCDEF12345678 +MIME-Version: 1.0 +Content-Type: multipart/mixed; boundary="boundary3" + +--boundary3 +Content-Type: text/plain; charset="utf-8" +Content-Transfer-Encoding: quoted-printable + +Dear Bob + +Please use "bob" with the following password to access the wiki site: + +correcthorsebatterystaple + +Please reach out if there are any issues and have a good day! + +Alice + +--boundary3-- + +--boundary2 + +Content-Type: application/pgp-keys +Content-Disposition: attachment; filename="pEpkey.asc" + +-----BEGIN PGP PUBLIC KEY BLOCK----- + +[...] + +-----END PGP PUBLIC KEY BLOCK----- + +--boundary2-- ++
To be able to decide which email format to generate, the pEp-enabled MUA REQUIRES to record state on a per-identity basis. Once a “X-pEp-Version” header field is discovered, the user MUST be recorded as a pEp user and the corresponding pEp Version it supports (according to the highest value of the “X-pEp-Version” header field encountered).
+In accordance to the Privacy by Default principle, messages sent or received in encrypted form MUST be saved with the identity’s respective public key.
+Messages sent or received in unencrypted form, SHOULD NOT be saved in encrypted form on the email server: this reflects the Privacy Status the user encountered when sending or receiving the email and thus meets the user’s expectations.
+Instead, message drafts MUST always be saved with the identity’s public key.
+Other messages sent and received MUST be saved encrypted by default: for most end-user scenarios, the servers users work with, are considered untrusted.
+For trusted environments (e.g., in organizations) and to conform to legally binding archiving regulations, pEp implementations MUST provide a “Trusted Server” option. With the user’s explicit consent (opt-in), unencrypted copies of the Messages MUST be held on the mail servers controlled by the organization.
+[[ TODO, feedback roker: Discuss the importance of full-disk encryption, also for the option to save messages locally in unencrypted form; that is even more important to protect secret keys (mentioned in pEp’s general draft). ]]
+A pEp-enabled Mail User Agent MUST consider every email account as an new identity: for each identity, a different key pair MUST be created automatically if no key material with sufficient length is available. By default, RSA-4096 key pairs for OpenPGP encryption [RFC4880] SHOULD be generated automatically for each email account. However, the key length MUST be at least 2048 bits. Elliptic curve keys with at least 256 bits MUST be supported, but SHOULD NOT yet be generated and announced by default for interoperability reasons.
+If for an identity there’s an RSA key pair with less than 2048 bits, new keys MUST be generated.
+[[ TODO: Add here what is specific to email ]]
+[[ TODO: Add here what is specific to email ]]
+[[ TODO: Add here what is specific to email ]]
+By default, public keys MUST always be attached to any outgoing message as described in Section 2.9. If this is undesired, e.g., to reduce display artefacts or (temporary) spam alerts on the receiving side, Passive Mode (cf. Section 7.1) can be activated.
+[[ TODO: Add here what is specific to email ]]
+The following example roughly describes a pEp email scenario with a typical initial message flow to demonstrate key exchange and basic trust management:
+ + +As color code changes for an identity, this is also reflected to future messages to/from this identity. Past messages, however, MUST NOT be altered.
++ ----- ----- + | A | | B | + ----- ----- + | | ++------------------------+ +------------------------+ +| auto-generate key pair | | auto-generate key pair | +| (if no key yet) | | (if no key yet) | ++------------------------+ +------------------------+ + | | ++-----------------------+ +-----------------------+ +| Privacy Status for B: | | Privacy Status for A: | +| *Unencrypted* | | *Unencrypted* | ++-----------------------+ +-----------------------+ + | | + | A sends message to B (Public Key | + | attached) / optionally signed, but | + | NOT ENCRYPTED | + +------------------------------------------>| + | | + | +-----------------------+ + | | Privacy Status for A: | + | | *Encrypted* | + | +-----------------------+ + | | + | B sends message to A (Public Key | + | attached) / signed and ENCRYPTED | + |<------------------------------------------+ + | | ++-----------------------+ | +| Privacy Status for B: | | +| *Encrypted* | | ++-----------------------+ | + | | + | A and B successfully compare their | + | Trustwords over an alternative channel | + | (e.g., phone line) | + |<-- -- -- -- -- -- -- -- -- -- -- -- -- -->| + | | ++-----------------------+ +-----------------------+ +| Privacy Status for B: | | Privacy Status for A: | +| *Trusted* | | *Trusted* | ++-----------------------+ +-----------------------+ + | | + + ++
[[ TODO: Add more of what is specific to email ]]
+[[ TODO: Add here what is specific to email ]]
+[[ TODO: Add here what is specific to email ]]
+[[ TODO: Add here what is specific to email ]]
+As per [I-D.pep-keysync]:
+[[ TODO: Add here what is specific to email ]]
+[[ TODO: Add here what is specific to email ]]
+[[ TODO: Add here what is specific to email ]]
+[[ TODO: Add here what is specific to email ]]
+In email, Passive Mode primarily exists as an option to avoid potential usability artefacts in certain environments where Internet users might get confused by the exposure of public keys in email attachments. In principle, however, this “problem” can be mitigated either by training or by MUA implementers displaying public key material in a more symbolic way or even importing it automatically and then hiding this attachment altogether (as pEp implementers are supposed to do, such that regular Internet user don’t have to bother about keys).
+Passive Mode has a negative impact on privacy: additional unencrypted message exchanges are needed until pEp’s by-default encryption can take place.
+Passive Mode MUST only affect unencrypted communications and be inactive by default. By opting in to Passive Mode, the sender’s public key MUST NOT be attached when sending out unsecure emails. On the other hand, Passive Mode is without any effect when pEp is able to send out an encrypted message, because the necessary encryption key(s) are available.
+In this situation, opportunistic by-default encryption MUST take place: there, the sender’s public key is attached in encrypted form as constituent part of one of pEp’s PGP/MIME-based message format described in Section 2.9.
+Additionally, Passive Mode MUST be without effect, if a receiver learns a MUA is actually pEp-capable, even if the sender involved is in Passive Mode, too: this MUST be recognized by the “X-pEp-Version” header field, as the only clear indicator to detect pEp users. That means that a pEp-enabled MUA is REQUIRED to attach its corresponding public key to another pEp user in any case, such that they can engage in opportunistic encryption.
+[[ TODO: Add message examples and a flow chart, if needed ]]
+This is an opt-in mechanism to enforce that messages go out unprotected. Even if encryption keys for recipient(s) are available, this option MUST enforce that messages are sent in the Section 2.9.1 format.
+[[ TODO: Add here what is specific to email ]]
+[[ TODO: Add here what is specific to email ]]
+[[ TODO: Add here what is specific to email ]]
+[[ TODO ]]
+[[ TODO ]]
+This document has no actions for IANA.
+This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.
+According to [RFC7942], “[…] this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit.”
+The following software implementing the pEp protocols (to varying degrees) already exists:
+ + +pEp for Android, iOS, Outlook and Thunderbird are provided by pEp Security, a commercial entity specializing in end-user software implementing pEp while Enigmail/pEp is pursued as community project, supported by the pEp Foundation.
+All software is available as Free Software and published also in source form.
+Special thanks go to Krista Bennett and Volker Birk for the reference implementation on pEp and the ideas leading to this draft.
+The author would like to thank the following people who provided substantial contributions, helpful comments or suggestions for this document: Claudio Luck, Bernie Hoeneisen and Lars Rohwedder.
+This work was initially created by pEp Foundation, and was initially reviewed and extended with funding by the Internet Society’s Beyond the Net Programme on standardizing pEp. [ISOC.bnet]
+| [I-D.birk-pep] | ++Birk, V., Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): Privacy by Default", Internet-Draft draft-birk-pep-05, November 2019. | +
| [I-D.marques-pep-handshake] | ++Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): Contact and Channel Authentication through Handshake", Internet-Draft draft-marques-pep-handshake-04, January 2020. | +
| [I-D.marques-pep-rating] | ++Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): Mapping of Privacy Rating", Internet-Draft draft-marques-pep-rating-03, January 2020. | +
| [I-D.melnikov-iana-reg-forwarded] | ++Melnikov, A. and B. Hoeneisen, "IANA Registration of Content-Type Header Field Parameter 'forwarded'", Internet-Draft draft-melnikov-iana-reg-forwarded-00, November 2019. | +
| [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. | +
| [RFC2119] | ++Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. | +
| [RFC3156] | ++Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, August 2001. | +
| [RFC4880] | ++Callas, J., Donnerhacke, L., Finney, H., Shaw, D. and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007. | +
| [RFC4949] | ++Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007. | +
| [RFC5322] | ++Resnick, P., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008. | +
| [RFC7435] | ++Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014. | +
[[ RFC Editor: This section is to be removed before publication ]]
+ + +[[ RFC Editor: This section should be empty and is to be removed before publication ]]
+ + +