idnits 2.17.1 draft-pep-email-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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 an 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. -- The document date (November 03, 2020) is 1267 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-birk-pep-05 ** Downref: Normative reference to an Informational draft: draft-marques-pep-rating (ref. 'I-D.marques-pep-rating') ** Downref: Normative reference to an Informational draft: draft-melnikov-iana-reg-forwarded (ref. 'I-D.melnikov-iana-reg-forwarded') ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Downref: Normative reference to an Informational RFC: RFC 7435 == Outdated reference: A later version (-03) exists of draft-pep-keysync-02 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Marques 3 Internet-Draft pEp Foundation 4 Intended status: Standards Track November 03, 2020 5 Expires: May 7, 2021 7 pretty Easy privacy (pEp): Email Formats and Protocols 8 draft-pep-email-01 10 Abstract 12 The proposed pretty Easy privacy (pEp) protocols for email are based 13 upon already existing email and encryption formats (as PGP/MIME) and 14 designed to allow for easily implementable and interoperable 15 opportunistic encryption. The protocols range from key distribution, 16 secret key synchronization between own devices, to mechanisms of 17 metadata and content protection. The metadata and content protection 18 is achieved by moving the whole message (not only the body part) into 19 the PGP/MIME encrypted part. The proposed pEp Email Formats not only 20 achieve simple forms of metadata protection (like subject 21 encryption), but also allow for sending email messages through a 22 mixnet. Such enhanced forms of metadata protection are explicitly 23 discussed within the scope of this document. 25 The purpose of pEp for email is to simplify and automate operations 26 in order to make usage of email encryption a viability for a wider 27 range of Internet users, with the goal of achieving widespread 28 implementation of data confidentiality and privacy practices in the 29 real world. 31 The proposed operations and formats are targeted towards to 32 Opportunistic Security scenarios and are already implemented in 33 several applications of pretty Easy privacy (pEp). 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 7, 2021. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Relationship to other pEp documents . . . . . . . . . . . 4 70 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 71 1.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Opportunistic Security and Privacy for Email . . . . . . . . 5 73 2.1. Privacy by Default . . . . . . . . . . . . . . . . . . . 5 74 2.2. Data Minimization . . . . . . . . . . . . . . . . . . . . 6 75 2.3. Metadata Protection . . . . . . . . . . . . . . . . . . . 6 76 2.4. Interoperability . . . . . . . . . . . . . . . . . . . . 7 77 2.5. End-to-End . . . . . . . . . . . . . . . . . . . . . . . 7 78 2.6. Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . 7 79 2.7. User Experience (UX) . . . . . . . . . . . . . . . . . . 7 80 2.8. Identity System . . . . . . . . . . . . . . . . . . . . . 7 81 2.8.1. Address . . . . . . . . . . . . . . . . . . . . . . . 8 82 2.8.2. Key . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 2.8.3. User . . . . . . . . . . . . . . . . . . . . . . . . 8 84 2.8.4. Identity . . . . . . . . . . . . . . . . . . . . . . 8 85 2.8.5. Alias . . . . . . . . . . . . . . . . . . . . . . . . 9 86 2.9. pEp Email Formats . . . . . . . . . . . . . . . . . . . . 9 87 2.9.1. Unencrypted pEp Format . . . . . . . . . . . . . . . 10 88 2.9.2. pEp Email Format 1.0 . . . . . . . . . . . . . . . . 11 89 2.9.3. pEp Email Format 2.0 . . . . . . . . . . . . . . . . 15 90 2.9.4. pEp Email Format 2.1 . . . . . . . . . . . . . . . . 18 91 2.9.5. Protocol Negotiation for Format Selection . . . . . . 21 92 2.9.6. Saving Messages . . . . . . . . . . . . . . . . . . . 21 93 3. Key Management . . . . . . . . . . . . . . . . . . . . . . . 21 94 3.1. Key Generation . . . . . . . . . . . . . . . . . . . . . 21 95 3.2. Private Keys . . . . . . . . . . . . . . . . . . . . . . 22 96 3.2.1. Storage . . . . . . . . . . . . . . . . . . . . . . . 22 97 3.2.2. Passphrase . . . . . . . . . . . . . . . . . . . . . 22 98 3.2.3. Private Key Export / Import . . . . . . . . . . . . . 22 99 3.3. Public Key Distribution . . . . . . . . . . . . . . . . . 22 100 3.4. Key Reset . . . . . . . . . . . . . . . . . . . . . . . . 22 101 4. Trust Management . . . . . . . . . . . . . . . . . . . . . . 22 102 4.1. Privacy Status . . . . . . . . . . . . . . . . . . . . . 25 103 4.2. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 25 104 4.3. Trust Rating . . . . . . . . . . . . . . . . . . . . . . 25 105 5. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 25 106 5.1. Private Key Synchronization . . . . . . . . . . . . . . . 25 107 5.2. Trust Synchronization . . . . . . . . . . . . . . . . . . 25 108 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 25 109 7. Options in pEp . . . . . . . . . . . . . . . . . . . . . . . 25 110 7.1. Option "Passive Mode" . . . . . . . . . . . . . . . . . . 25 111 7.2. Option "Disable Protection" . . . . . . . . . . . . . . . 26 112 7.3. Option "Extra Keys" . . . . . . . . . . . . . . . . . . . 26 113 7.4. Option "Blacklist Keys" . . . . . . . . . . . . . . . . . 26 114 7.5. Option "Trusted Server" . . . . . . . . . . . . . . . . . 26 115 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 116 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 117 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 118 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 119 11.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 27 120 11.2. Current software implementations of pEp . . . . . . . . 27 121 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 122 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 123 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 124 13.2. Informative References . . . . . . . . . . . . . . . . . 29 125 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 31 126 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 32 127 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 129 1. Introduction 131 This document contains propositions for implementers of Mail User 132 Agents (MUAs) seeking to support pretty Easy privacy (pEp) 133 specifically for email [RFC5322]. All the propositions of 134 [I-D.birk-pep] also apply to pEp for email. In this document, 135 requirements are outlined for MUAs wanting to establish 136 interoperability and/or to implement pEp for email. 138 pEp for email builds upon the cryptographic security services offered 139 by PGP/MIME [RFC3156]. The primary goals of pEp for email are: 141 (1) Maximization of email privacy for Internet actors deploying and 142 using the pretty Easy privacy approach. 144 (2) Compatibility with legacy or other automatic email encryption 145 solutions in order to preserve privacy to the greatest extent 146 possible. 148 Interoperability with S/MIME [RFC8551] is a also goal, but at this 149 time there is no specification or running code that achieves this 150 goal. 152 Current tools and implementations have failed to provide a sufficient 153 level of usability to ordinary Internet users, with the result that 154 end-to-end email encryption is seldom used. 156 While OpenPGP [RFC4880] using PGP/MIME [RFC3156] offers good 157 encryption-for message contents at least-more work is needed to 158 achieve the following three objectives of pretty Easy privacy (pEp): 160 1. make email encryption as automatic as possible, 162 2. protect as much metadata as possible, and 164 3. provide an easy way to authenticate communication partners. 166 A reference implementation of pEp for email is available for all 167 major platforms and it has been ported to many programming languages 168 (cf. Section 11 for an overview). 170 1.1. Relationship to other pEp documents 172 This document describes the pEp for email protocols. While it 173 specifies details particularly related to pEp for email, it basically 174 inherits the structure of [I-D.birk-pep], which describes the general 175 concepts of pEp on a higher level. 177 For protocol details, constituent pEp mechanisms which also apply to 178 email can be found in documents like [I-D.marques-pep-handshake]), 179 which shows how trust between any two pEp users can be established, 180 [I-D.marques-pep-rating], which describes the privacy indications 181 that can be helpful for regular Internet users or [I-D.pep-keysync], 182 which outlines pEp's peer-to-peer protocol to synchronize secret key 183 material which belongs to the same account and user across various 184 end-devices. 186 1.2. Requirements Language 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 1.3. Terms 194 The following terms are defined for the scope of this document: 196 o pEp Handshake: The process of one user contacting another over an 197 independent channel in order to verify Trustwords (or fingerprints 198 as a fallback). This can be done in-person or through established 199 verbal communication channels, like a phone call. 200 [I-D.marques-pep-handshake] 202 o Trustwords: A scalar-to-word representation of 16-bit numbers (0 203 to 65535) to natural language words. When doing a Handshake, 204 peers are shown combined Trustwords of both public keys involved 205 to ease the comparison. [I-D.birk-pep-trustwords] 207 o Trust On First Use (TOFU): cf. [RFC7435], which states: "In a 208 protocol, TOFU calls for accepting and storing a public key or 209 credential associated with an asserted identity, without 210 authenticating that assertion. Subsequent communication that is 211 authenticated using the cached key or credential is secure against 212 an MiTM attack, if such an attack did not succeed during the 213 vulnerable initial communication." 215 o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A 216 form of active wiretapping attack in which the attacker intercepts 217 and selectively modifies communicated data to masquerade as one or 218 more of the entities involved in a communication association." 220 Note: Historically, MITM has stood for '_Man_-in-the-middle'. 221 However, to indicate that the entity in the middle is not always a 222 human attacker, MITM can also stand for 'Machine-in-the-middle' or 223 'Meddler-in-the-middle'. 225 2. Opportunistic Security and Privacy for Email 227 In addition to the Protocol's Core Design Principles outlined in 228 [I-D.birk-pep], the following sections on design principles are 229 applicable to pEp for email applications. 231 2.1. Privacy by Default 233 The pEp formats and protocols aim to maximize privacy. Where privacy 234 goals contradict with security goals, the privacy goals MUST take 235 precedence. 237 Examples: 239 o pEp implementers MUST NOT make queries to public key servers by 240 default. The reason for this is to make it more resource- 241 intensive for centralized network actors to learn a user's social 242 graph. This is also problematic security-wise, as centralized 243 cryptographic key subversion at-scale is made easier. Instead, 244 key distribution MUST be handled in-band while communicating with 245 other peers. 247 o Trust information MUST NOT be attached to the communication 248 partners' public keys. This is metadata which MUST be held 249 locally and separately from the keys. Trust is established 250 between the peers directly (peer-to-peer) and no trust information 251 is held centrally (no support for the Web of Trust): that is, 252 while pEp MUST be able to work with OpenPGP keys which carry trust 253 information, this external trust information MUST NOT be used to 254 signal any trust level to the pEp user. 256 o pEp-enabled MUAs MUST either engage in a signed-and-encrypted 257 communication or in unsigned plaintext communication. While the 258 signatures attached to plaintext messages can be verified, signed- 259 only messages neither increase security nor privacy, so long as 260 the corresponding public key is not authenticated. 262 2.2. Data Minimization 264 Data Minimization includes data sparsity and hiding of all 265 technically concealable information whenever possible. 267 2.3. Metadata Protection 269 Email metadata (i.e., headers) MUST either be omitted or encrypted 270 whenever possible. 272 The PGP/MIME specification as described in [RFC3156] provides few 273 facilities for metadata protection: while the email body receives 274 protection, the header section remains unprotected. 276 However, it is possible to also protect the information contained in 277 the header field values by encapsulating the whole message into a 278 MIME entity to be signed and encrypted. 280 The S/MIME Message Specification [RFC8551] defines a way to also 281 protect the header section in addition to the content of a message: 283 The sending client MAY wrap a full MIME message in a message/ 284 rfc822 wrapper in order to apply S/MIME security services to 285 header fields. 287 2.4. Interoperability 289 Implementers of pEp SHOULD be liberal in accepting non-pEp formats to 290 encrypt email contents and metadata. pEp implementations MUST use the 291 strict and interoperable pEp Email Format 1.0 (cf. Section 2.9.2) 292 for any outgoing communication to non-pEp users. For communication 293 between pEp users, more privacy-preserving formats (cf. Section 2.9) 294 MUST be used. pEp Email Formats 2.0 and newer SHOULD NOT be used 295 between users who are not recognized as pEp users (cf. 296 Section 2.9.5), because for non-pEp users those formats are likely to 297 produce unwanted visual artifacts. 299 2.5. End-to-End 301 For interpersonal messaging, an email endpoint in pEp is the MUA on a 302 user's end-device: that is, encryption and decryption of messages 303 MUST be executed on a user's end-device and MUST NOT depend on any 304 third-party network infrastructure (i.e., any infrastructure outside 305 a user's direct control). 307 [[ *TODO*: Add enterprise settings with Key Escrow / Extra Keys ]] 309 2.6. Peer-to-Peer 311 All relevant pEp mechanisms and state information about other peers 312 MUST be held locally, on a peer's end-device. There MUST NOT be any 313 reliance on an email server or even a centralized network component 314 to hold relevant information for peers to be able to communicate or 315 to authenticate themselves. Email servers (like, SMTP or IMAP) are 316 only used as transport infrastructure for messages, but MUST not be 317 relevant to hold actual state between peers. 319 [[ TODO: Make clear there is a way that synchronizes trust in a peer- 320 to-peer fashion, by using the Trust Sync mechanism. ]] 322 2.7. User Experience (UX) 324 [[ *TODO*: Add here what is specific to email ]] 326 2.8. Identity System 328 In pEp for email, a user is a person or group who can have one or 329 more identities, each represented by email addresses. Every identity 330 has an own key attached to it. An email address can also be an alias 331 for an already existing identity, in which case the same key is 332 attached to it. 334 All information about communication partners, like identities, keys 335 and aliases MUST be held on a user's end-device as state information. 336 This SHOULD be done using a structured format, to facilitate the 337 synchronization of state information across various devices, taking 338 into account multi-device scenarios, which are common today. 340 In pEp's reference implementation (cf. Section 11), keys are held 341 using the key store of the cryptographic library, while peer-specific 342 state information, including trust information, is held in a simple 343 relational database. 345 [[ *TODO*: Check optimal order for the following sections. ]] 347 2.8.1. Address 349 In pEp for email, the SMTP address (e.g., mailto:alice@example.org) 350 constitutes the network address. 352 2.8.2. Key 354 For now, a key in pEp for email is an OpenPGP key. Each identity has 355 a default key attached for that identity. This is the public key to 356 be used to encrypt communications to it. 358 2.8.3. User 360 A user in pEp for email is a specific person or group. A user has at 361 least one identity, but can have more. 363 2.8.4. Identity 365 An identity in pEp for email is represented by an email URI, like 366 mailto:alice@example.org. Identities are represented by email 367 address URIs because a user may have multiple URIs. For example, if 368 Alice uses mailto:alice@example.org for private purposes, but also 369 wishes to have a public address, she may create another email 370 address, such as anonymous@example.com. Because this is a new URI 371 (mailto:anonymous@example.com), it is considered a new identity for 372 Alice. 374 By default, pEp-enabled MUAs MUST generate a new key pair during new 375 account configuration, so that a user's respective identities are not 376 correlated to each other. However, if Alice wants her URIs to be 377 handled as a single identity with one key, she may configure her 378 respective identities as aliases. 380 For other email URIs pointing to the same identity, see the alias 381 (cf. Section 2.8.5) concept. 383 2.8.5. Alias 385 Aliases share the same key and identity, e.g., the same key might be 386 used for mailto:alice@example.org as well as for 387 mailto:alice@example.net. That is, both addresses refer to the same 388 identity. 390 2.9. pEp Email Formats 392 The pEp Email Formats 1.0, 2.0 and 2.1 are restricted MIME-based 393 email formats, which ensure messages to be signed and encrypted. In 394 accordance with pEp's privacy (and not security) focus, signed-only 395 messages MUST NOT be produced (cf. Section 2.1). pEp-enabled clients 396 MUST be able to render all pEp Email Formats properly: for outgoing 397 communications, the most privacy-preserving format available is to be 398 used, taking interoperability (cf. Section 2.4) into account. 400 Since pEp Email Format 2.0, a compatibility format (i.e., pEp Email 401 Format 1.0, cf. Section 2.9.2) exists, which SHOULD be applied to 402 non-pEp users, for which trustworthy public keys are available 403 according to the local database. 405 In case no trustworthy encryption key is available, an unencrypted, 406 unsigned MIME email is sent out. As in all pEp formats, also this 407 (unprotected) message MUST contain the sender's public key, unless 408 Passive Mode (cf. Section 7.1) is active. 410 All pEp Email Formats include a "pEpkey.asc" file attachment holding 411 the sender's OpenPGP public key in ASCII-armored format, which is 412 suitable for manual key import by non-pEp users. Thus, a user of any 413 OpenPGP-enabled MUA is able to manually import the public key and 414 engage in end-to-end encryption with the pEp sender. MUA 415 implementers of PGP-capable email clients, even when not fully 416 supporting pEp's protocols, are encouraged to automatically import 417 the key such that the user can immediately engage in opportunistic 418 encryption. 420 In pEp's reference implementation the subject is set to "pEp" (or 421 alternatively to its UTF-8 representation as "=?utf- 422 8?Q?p=E2=89=A1p?="). However, the subject's value of the outer 423 message MUST be ignored. Therefore, the subject can be set to any 424 value (e.g., "..." as used in other implementations). 426 2.9.1. Unencrypted pEp Format 428 This is the format to be used when unencrypted messages are sent out. 430 The unencrypted pEp format is a "multipart/mixed" MIME format, which 431 by default ensures the delivery of the sender's public key as an 432 attachment ("Content-Disposition: attachment"). 434 A simple plaintext email looks like the following: 436 From: Alice 437 To: Bob 438 Date: Tue, 31 Dec 2019 05:05:05 +0200 439 X-pEp-Version: 2.1 440 MIME-Version: 1.0 441 Subject: Saying Hello 442 Content-Type: multipart/mixed; boundary="boundary" 444 --boundary 445 Content-Type: text/plain; charset="utf-8" 446 Content-Transfer-Encoding: quoted-printable 448 Hello Bob 450 If you reply to this email using a pEp-enabled client, I will 451 be able to send you that sensitive material I talked to you 452 about. 454 Have a good day! 456 Alice 458 -- 459 Sent with pEp for Android. 461 --boundary 462 Content-Type: application/pgp-keys; name="pEpkey.asc" 463 Content-Transfer-Encoding: base64 464 Content-Disposition: attachment; filename="pEpkey.asc"; size=2639 466 -----BEGIN PGP PUBLIC KEY BLOCK----- 468 [...] 470 -----END PGP PUBLIC KEY BLOCK----- 472 --boundary-- 474 2.9.2. pEp Email Format 1.0 476 pEp Email Format 1.0 (PEF-1.0) is an encrypted and signed MIME 477 format, which by default ensures: 479 o a signed and encrypted message, with subject encryption 481 o delivery of the sender's public key 483 PEF-1.0 has a "multipart/encrypted" MIME node on-the-wire format with 484 an OpenPGP encrypted and signed filename "msg.asc", and "Content- 485 Disposition: inline" attribute." 487 The subject is the only header field that can be protected with PEF- 488 1.0. To achieve this protection, the real subject value is added to 489 the top for the content section for the very first MIME entity with 490 media type "text/plain", that is encrypted, e.g.: 492 Subject: Credentials 494 For example, an email with "Subject: Credentials" becomes "Subject: 495 pEp" on-the-wire once encryption has taken place, with the true 496 subject appended to the beginning of the message text once decrypted. 498 Thus, legacy clients not aware of nor able to parse pEp's subject 499 encryption, still display the actual subject (in the above example: 500 "Credentials") to the user. Whenever the first encrypted "text/ 501 plain" MIME entity contains such a subject line, the MUAs 502 implementing pEp MUST render it to the user. Note that also the 503 lines starting with "subject:" or "SUBJECT:" are to be rendered (as 504 with header fields, this is case-insensitive). 506 A pEp-enabled MUA MUST add the "X-pEp-Version" header field with its 507 highest value (preferably with value "2.1" as for pEp Email Format 508 2.1 Section 2.9.4) when producing this format. Here, a pEp-enabled 509 MUA declares its capability to receive and render more privacy- 510 preserving formats. Upgrading both sides to the highest version of 511 the pEp Email Format allows pEp-enabled MUAs for best possible 512 protection of metadata. For non-pEp MUAs it is OPTIONAL to add the 513 "X-pEp-Version: 1.0" header field. However, this format is 514 implicitly assumed even if this header field is not present. 516 Please note that for messages between pEp- and non-pEp clients the 517 subject encryption MAY be disabled, sacrificing usability over 518 privacy by avoiding artefacts for non-pEp recipients. 520 PEF-1.0 is also considered pEp's compatibility format towards non-pEp 521 clients. 523 A PEF-1.0 example looks as follows: 525 From: Alice 526 To: Bob 527 Date: Wed, 1 Jan 2020 23:23:23 +0200 528 X-pEp-Version: 1.0 529 MIME-Version: 1.0 530 Subject: pEp 531 Content-Type: multipart/encrypted; boundary="boundary1"; 532 protocol="application/pgp-encrypted" 534 --boundary1 535 Content-Type: application/pgp-encrypted 537 Version: 1 539 --boundary1 540 Content-Type: application/octet-stream 541 Content-Transfer-Encoding: 7bit 542 Content-Disposition: inline; filename="msg.asc" 544 -----BEGIN PGP MESSAGE----- 546 [...] 548 -----END PGP MESSAGE----- 550 --boundary-- 552 Decrypting the enclosed "msg.msc" part yields the following: 554 MIME-Version: 1.0 555 Content-Type: multipart/mixed; boundary="boundary2" 556 --boundary2 557 Content-Type: text/plain; charset="utf-8" 558 Content-Transfer-Encoding: quoted-printable 559 Content-Disposition: inline; filename="msg.txt" 561 Subject: Credentials 563 Dear Bob 565 Please use "bob" with the following password to access the wiki site: 567 correcthorsebatterystaple 569 Please reach out if there are any issues and have a good day! 571 Alice 573 --boundary2 574 Content-Type: application/pgp-keys 575 Content-Disposition: attachment; filename="pEpkey.asc" 577 -----BEGIN PGP PUBLIC KEY BLOCK----- 579 [...] 581 -----END PGP PUBLIC KEY BLOCK----- 583 --boundary2-- 585 Note that the user-intended subject value is encrypted in the first 586 "text/plain" MIME entity under the "multipart/mixed" MIME node. 588 2.9.2.1. Deprecated variant of PEF-1.0 590 An earlier variant of PEF-1.0 started with a "multipart/mixed" MIME 591 node, which in case of a simple text-only email without attachments 592 and other MIME entities has 594 (1) a "text/plain" MIME entity with the PGP-encrypted content, and 596 (2) the sender's transferable public key at the very end. 598 This variant MUST NOT be produced anymore. 600 An example of this deprecated variant of PEF-1.0 looks as follows: 602 From: Alice 603 To: Bob 604 Date: Wed, 1 Jan 2020 23:23:23 +0200 605 X-pEp-Version: 1.0 606 MIME-Version: 1.0 607 Subject: pEp 608 Content-Type: multipart/mixed; boundary="boundary" 610 --boundary 611 Content-Type: application/pgp-encrypted 613 Version: 1 615 --boundary 616 Content-Type: text/plain; charset="utf8" 617 Content-Transfer-Encoding: 7bit 619 -----BEGIN PGP MESSAGE----- 620 [...] 621 -----END PGP MESSAGE----- 623 --boundary 624 Content-Type: application/pgp-keys; name="pEpkey.asc" 625 Content-Transfer-Encoding: 7bit 626 Content-Disposition: attachment; filename="pEpkey.asc" 628 -----BEGIN PGP PUBLIC KEY BLOCK----- 630 [...] 632 -----END PGP PUBLIC KEY BLOCK----- 634 --boundary-- 636 There, decrypting the PGP encrypted text/plain element yields a text 637 like the following; most obviously, the intended subject line is now 638 visible: 640 Subject: Credentials 642 Dear Bob 644 Please use "bob" with the following password to access the wiki site: 646 correcthorsebatterystaple 648 Please reach out if there are any issues and have a good day! 650 Alice 652 2.9.3. pEp Email Format 2.0 654 pEp Email Format 2.0 (PEF-2.0) is a strict MIME format, which by 655 default ensures: 657 o a signed and encrypted message, with full email encapsulation 659 o delivery of the sender's public key 661 In PEF-2.0, the actual email (inner message) is encapsulated by a 662 MIME entity ("Content-Type: message/rfc822"), which is the second 663 part of a "multipart/mixed" MIME node. The first part of this MIME 664 node contains a "text/plain" MIME entity, including a marker text 665 "pEp-Message-Wrapped-Info: OUTER" (in its MIME content). This is 666 used for proper displaying and mapping of the nested message and its 667 encrypted header fields. Like with the PEF-1.0 (cf. Section 2.9.2), 668 the third (and last) part of the "multipart/mixed" MIME node MUST 669 contain the sender's public key. 671 The "multipart/mixed" MIME node is encrypted inside yet another MIME 672 node ("Content-Type: multipart/encrypted", cf. [RFC1847] / 673 [RFC3156]), which is the body part of the outer message. 675 Thus, the whole header section of the inner message can be fully 676 preserved, not only encrypted, but also signed. In the outer 677 message, however, when communicating with pEp users all header fields 678 that are not needed MUST be omitted to the fullest extent possible. 680 Once encrypted, only the outer message consisting of the (minimal) 681 outer header section and the "multipart/encrypted" MIME entity as 682 body with an application/octet-stream "Content-Type" with name 683 "msg.asc" is visible on the wire. 685 If the receiving side is not a known pEp-enabled MUA, but there is a 686 trustworthy public key available, PEF-1.0 (cf. Section 2.9.2) MUST 687 be used to send the email. 689 In any case, the "X-pEp-Version" header field MUST be set to version 690 2.0, as the highest version that the sender supports. 692 The following example shows a PEF-2.0 multipart/encrypted email, 693 signed and encrypted, as an 7bit octet stream with a filename 694 "msg.asc", with "Content-Disposition: inline". Within that, the 695 original email message is fully contained in encrypted form (like 696 this, also the subject line gets encrypted). The support of version 697 2.0 is announced in the "X-pEp-Version" header field (in this 698 example, 2.0 is the newest pEp Email Format the pEp-enabled MUA is 699 able to produce and render): 701 From: Alice 702 To: Bob 703 Date: Wed, 1 Jan 2020 23:23:23 +0200 704 X-pEp-Version: 2.0 705 MIME-Version: 1.0 706 Subject: pEp 707 Content-Type: multipart/encrypted; boundary="boundary1"; 708 protocol="application/pgp-encrypted" 710 --boundary1 711 Content-Type: application/pgp-encrypted 713 Version: 1 715 --boundary1 716 Content-Type: application/octet-stream 717 Content-Transfer-Encoding: 7bit 718 Content-Disposition: inline; filename="msg.asc" 720 -----BEGIN PGP MESSAGE----- 722 [...] 724 -----END PGP MESSAGE----- 726 --boundary-- 728 Decrypting "msg.asc" results in a multipart/mixed node, with three 729 elements: 731 (1) a text part indicating this is the encapsulated message 733 (2) the original message encapsulated by a "message/rfc822" MIME 734 entity, and 736 (3) the transferable sender's public key in ASCII-armored format. 738 An unwrapped example looks like this: 740 MIME-Version: 1.0 741 Content-Type: multipart/mixed; boundary="boundary2" 743 --boundary2 744 Content-Type: text/plain; charset="utf-8" 745 Content-Disposition: inline; filename="msg.txt" 747 pEp-Wrapped-Message-Info: OUTER 749 --boundary2 750 Content-Type: message/rfc822 752 Message-ID: 753 Date: Wed, 1 Jan 2020 23:23:23 +0200 754 Subject: Credentials 755 X-pEp-Version: 2.0 756 MIME-Version: 1.0 757 Content-Type: multipart/mixed; boundary="boundary3" 759 --boundary3 760 Content-Type: text/plain; charset="utf-8" 761 Content-Transfer-Encoding: quoted-printable 763 pEp-Wrapped-Message-Info: INNER 765 Dear Bob 767 Please use "bob" with the following password to access the wiki site: 769 correcthorsebatterystaple 771 Please reach out if there are any issues and have a good day! 773 Alice 775 --boundary3-- 777 --boundary2 779 Content-Type: application/pgp-keys 780 Content-Disposition: attachment; filename="pEpkey.asc" 782 -----BEGIN PGP PUBLIC KEY BLOCK----- 784 [...] 785 -----END PGP PUBLIC KEY BLOCK----- 787 --boundary2-- 789 2.9.4. pEp Email Format 2.1 791 pEp Email Format 2.1 (PEF-2.1) introduces further pEp-specific header 792 fields to the inner message, which help to determine the behavior 793 between pEp users. 795 In normal interpersonal messaging those additional header fields are: 797 (1) "X-pEp-Wrapped-Message-Info: INNER" header field stating that the 798 message carrying this is to be considered the most inner message 799 containing the original email (this is particularly relevant for 800 mixnet or other scenarios of nested messaging; cf. [pEp.mixnet]) 802 (2) "X-pEp-Sender-FPR" header field with the value set to sender's 803 full 160-bit public key fingerprint (e.g., 804 "1234567890ABCDEF1234567890ABCDEF12345678"), and 806 (3) the "X-pEp-Version" header field set to version "2.1". 808 As with PEF-2.0 Section 2.9.3, in PEF-2.1 the actual email (inner 809 message) is encapsulated by a MIME entity ("Content-Type: message/ 810 rfc822"), which is the second part of a "multipart/mixed" MIME node. 811 The first part of this MIME node contains a "text/plain" MIME entity, 812 which SHOULD be used to inform about the nature of this format (in 813 case a non-pEp client encounters in the mailbox). It MAY be used to 814 carry the intended subject of the inner message (which is not done in 815 current reference implementations). Like with the PEF-1.0 (cf. 816 Section 2.9.2) and PEF 2.0 (cf. Section 2.9.3), the third (and last) 817 part of this "multipart/mixed" MIME node MUST contain the sender's 818 public key. 820 This "multipart/mixed" MIME node is encrypted inside yet another MIME 821 node ("Content-Type: multipart/encrypted", cf. [RFC1847] / 822 [RFC3156]), which is the body part of the outer message. 824 A caveat of PEF-2.1 is that message rendering varies considerably 825 across different MUAs. This is relevant as it might happen that a 826 non-pEp MUA encounters a PEF-2.1 message (e.g., if a pEp-enabled 827 client was used in the past). No standard is currently available 828 which enables MUAs to reliably determine whenever a nested "message/ 829 rfc822" MIME entity is meant to render the contained email message, 830 or if it was effectively intended to be forwarded as an attachment, 831 where a user needs to click on in order to see its content. To help 832 unaware MUAs, a Content-Type header field parameter with name 833 "forwarded" as per [I-D.melnikov-iana-reg-forwarded] is added to the 834 Content-Type header field. MUAs can use this to distinguish between 835 a forwarded message and a nested message (i.e., using 836 "forwarded=no"). 838 When the receiving peer was registered as being only PEF-2.0-capable, 839 the message must be sent in PEF-2.0 (cf. Section 2.9.3). The reason 840 for this is that pEp-enabled MUAs which are only PEF-2.0-capable rely 841 on the plaintext "pEp-Message-Wrapped-Info: OUTER" and "pEp-Message- 842 Wrapped-Info: INNER" markers to properly display and map the nested 843 message and its encrypted header fields. 845 As with PEF-1.0, if the receiving side is not a known pEp-enabled 846 MUA, but there is a trustworthy public key available, PEF-1.0 (cf. 847 Section 2.9.2) MUST be used to send the email. 849 In any case, the "X-pEp-Version" header field MUST be set to version 850 2.1, as the highest version that the sender supports. 852 This is an example of what the format looks like between two PEF- 853 2.1-capable clients: 855 From: Alice 856 To: Bob 857 Date: Wed, 1 Jan 2020 23:23:23 +0200 858 X-pEp-Version: 2.1 859 MIME-Version: 1.0 860 Subject: pEp 861 Content-Type: multipart/encrypted; boundary="boundary1"; 862 protocol="application/pgp-encrypted" 864 --boundary1 865 Content-Type: application/pgp-encrypted 867 Version: 1 869 --boundary1 870 Content-Type: application/octet-stream 871 Content-Transfer-Encoding: 7bit 872 Content-Disposition: inline; filename="msg.asc" 874 -----BEGIN PGP MESSAGE----- 876 [...] 878 -----END PGP MESSAGE----- 880 --boundary1-- 881 Unwrapping the "multipart/encrypted" MIME node, yields this: 883 MIME-Version: 1.0 884 Content-Type: multipart/mixed; boundary="boundary2" 886 --boundary2 887 Content-Type: text/plain; charset="utf-8" 888 Content-Disposition: inline; filename="msg.txt" 890 This message was encrypted with pEp (https://pep.software). If you 891 are seeing this message, your client does not support raising message 892 attachments. Please click on the message attachment to view it, 893 or better yet, consider using pEp! 895 --boundary2 896 Content-Type: message/rfc822; forwarded="no" 898 Message-ID: 899 Date: Wed, 1 Jan 2020 23:23:23 +0200 900 Subject: Credentials 901 X-pEp-Version: 2.1 902 X-pEp-Wrapped-Message-Info: INNER 903 X-pEp-Sender-FPR: 1234567890ABCDEF1234567890ABCDEF12345678 904 MIME-Version: 1.0 905 Content-Type: multipart/mixed; boundary="boundary3" 907 --boundary3 908 Content-Type: text/plain; charset="utf-8" 909 Content-Transfer-Encoding: quoted-printable 911 Dear Bob 913 Please use "bob" with the following password to access the wiki site: 915 correcthorsebatterystaple 917 Please reach out if there are any issues and have a good day! 919 Alice 921 --boundary3-- 923 --boundary2 925 Content-Type: application/pgp-keys 926 Content-Disposition: attachment; filename="pEpkey.asc" 928 -----BEGIN PGP PUBLIC KEY BLOCK----- 930 [...] 932 -----END PGP PUBLIC KEY BLOCK----- 934 --boundary2-- 936 [[ TODO: Clarify on the "raising message" term in the example. ]] 938 2.9.5. Protocol Negotiation for Format Selection 940 To be able to decide which email format to generate, the pEp-enabled 941 MUA REQUIRES to record state on a per-identity basis. Once a "X-pEp- 942 Version" header field is discovered, the user MUST be recorded as a 943 pEp user and the corresponding pEp Version it supports (according to 944 the highest value of the "X-pEp-Version" header field encountered). 946 2.9.6. Saving Messages 948 In accordance with the Privacy by Default principle, messages sent or 949 received in encrypted form MUST be saved with the identity's 950 respective public key. 952 Messages sent or received in unencrypted form, SHOULD NOT be saved in 953 encrypted form on the email server: this reflects the Privacy Status 954 the user encountered when sending or receiving the email and thus 955 meets the user's expectations. 957 Instead, message drafts MUST always be saved with the identity's 958 public key. 960 Other messages sent and received MUST be saved encrypted by default: 961 for most end-user scenarios, the servers users work with, are 962 considered untrusted. 964 For trusted environments (e.g., in organizations) and to conform to 965 legally binding archiving regulations, pEp implementations MUST 966 provide a "Trusted Server" option. With the user's explicit consent 967 (opt-in), unencrypted copies of the Messages MUST be held on the mail 968 servers controlled by the organization. 970 3. Key Management 972 3.1. Key Generation 974 A pEp-enabled Mail User Agent MUST consider every email account as an 975 new identity: for each identity, a different key pair MUST be created 976 automatically if no key material with sufficient length is available. 977 By default, RSA-4096 key pairs for OpenPGP encryption [RFC4880] 978 SHOULD be generated automatically for each email account. However, 979 the key length MUST be at least 2048 bits. Elliptic curve keys with 980 at least 256 bits MUST be supported, but SHOULD NOT yet be generated 981 and announced by default for interoperability reasons. 983 If for an identity there's an RSA key pair with less than 2048 bits, 984 new keys MUST be generated. 986 3.2. Private Keys 988 [[ TODO: Add here what is specific to email ]] 990 3.2.1. Storage 992 [[ TODO: Add here what is specific to email ]] 994 3.2.2. Passphrase 996 [[ TODO: Add here what is specific to email ]] 998 3.2.3. Private Key Export / Import 1000 3.3. Public Key Distribution 1002 By default, public keys MUST always be attached to any outgoing 1003 message as described in Section 2.9. If this is undesired, Passive 1004 Mode (cf. Section 7.1) can be activated. 1006 3.4. Key Reset 1008 [[ TODO: Add here what is specific to email ]] 1010 4. Trust Management 1012 The following example roughly describes a pEp email scenario with a 1013 typical initial message flow to demonstrate key exchange and basic 1014 trust management: 1016 1. Alice - knowing nothing of Bob - sends an email to Bob. As Alice 1017 has no public key from Bob, this email is sent out unencrypted. 1018 However, Alice's public key is automatically attached. 1020 2. Bob can just reply to Alice and - as he received her public key - 1021 his MUA is now able to encrypt the message. At this point, the 1022 rating for Alice changes to "encrypted" in Bob's MUA, which (UX- 1023 wise) can be displayed using yellow color (cf. Section 4.3). 1025 3. Alice receives Bob's key. As of now Alice is also able to send 1026 secure emails to Bob. The rating for Bob changes to "encrypted" 1027 (with yellow color) in Alice's MUA (cf. Section 4.3). 1029 4. If Alice and Bob want to prevent man-in-the-middle (MITM) 1030 attacks, they can engage in a pEp Handshake comparing their so- 1031 called Trustwords (cf. Section 4.2) and confirm this process if 1032 those match. After doing so, their identity rating changes to 1033 "encrypted and authenticated" (cf. Section 4.3), which (UX-wise) 1034 can be displayed using a green color. 1036 As color code changes for an identity, this is also reflected to 1037 future messages to/from this identity. Past messages, however, MUST 1038 NOT be altered. 1040 ----- ----- 1041 | A | | B | 1042 ----- ----- 1043 | | 1044 +------------------------+ +------------------------+ 1045 | auto-generate key pair | | auto-generate key pair | 1046 | (if no key yet) | | (if no key yet) | 1047 +------------------------+ +------------------------+ 1048 | | 1049 +-----------------------+ +-----------------------+ 1050 | Privacy Status for B: | | Privacy Status for A: | 1051 | *Unencrypted* | | *Unencrypted* | 1052 +-----------------------+ +-----------------------+ 1053 | | 1054 | A sends message to B (Public Key | 1055 | attached) / optionally signed, but | 1056 | NOT ENCRYPTED | 1057 +------------------------------------------>| 1058 | | 1059 | +-----------------------+ 1060 | | Privacy Status for A: | 1061 | | *Encrypted* | 1062 | +-----------------------+ 1063 | | 1064 | B sends message to A (Public Key | 1065 | attached) / signed and ENCRYPTED | 1066 |<------------------------------------------+ 1067 | | 1068 +-----------------------+ | 1069 | Privacy Status for B: | | 1070 | *Encrypted* | | 1071 +-----------------------+ | 1072 | | 1073 | A and B successfully compare their | 1074 | Trustwords over an alternative channel | 1075 | (e.g., phone line) | 1076 |<-- -- -- -- -- -- -- -- -- -- -- -- -- -->| 1077 | | 1078 +-----------------------+ +-----------------------+ 1079 | Privacy Status for B: | | Privacy Status for A: | 1080 | *Trusted* | | *Trusted* | 1081 +-----------------------+ +-----------------------+ 1082 | | 1084 [[ TODO: Add more of what is specific to email ]] 1086 4.1. Privacy Status 1088 [[ TODO: Add here what is specific to email ]] 1090 4.2. Handshake 1092 [[ TODO: Add here what is specific to email ]] 1094 4.3. Trust Rating 1096 [[ TODO: Add here what is specific to email ]] 1098 5. Synchronization 1100 As per [I-D.pep-keysync]: 1102 [[ TODO: Add here what is specific to email ]] 1104 5.1. Private Key Synchronization 1106 [[ TODO: Add here what is specific to email ]] 1108 5.2. Trust Synchronization 1110 [[ TODO: Add here what is specific to email ]] 1112 6. Interoperability 1114 [[ TODO: Add here what is specific to email ]] 1116 7. Options in pEp 1118 7.1. Option "Passive Mode" 1120 In email, Passive Mode primarily exists as an option to avoid 1121 potential usability issues in certain environments where Internet 1122 users might get confused by the exposure of public keys in email 1123 attachments. In principle, however, this "problem" can be mitigated 1124 either by training or by MUA implementers displaying public key 1125 material in a more symbolic way or even importing it automatically 1126 and then hiding this attachment altogether (as pEp implementers are 1127 supposed to do, such that regular Internet users do not have to 1128 bother about keys). 1130 Passive Mode has a negative impact on privacy: additional unencrypted 1131 message exchanges are needed until pEp's by-default encryption can 1132 take place. 1134 Passive Mode MUST only affect unencrypted communications and MUST be 1135 inactive by default. By opting in to Passive Mode, the sender's 1136 public key MUST NOT be attached when sending out unsecure emails. On 1137 the other hand, Passive Mode is without any effect when pEp is able 1138 to send out an encrypted message, because the necessary encryption 1139 key(s) are available. 1141 In this situation, opportunistic by-default encryption MUST take 1142 place: there, the sender's public key is attached in encrypted form 1143 as constituent part of one of pEp's PGP/MIME-based message format 1144 described in Section 2.9. 1146 Additionally, Passive Mode MUST be without effect, if a receiver 1147 learns that an MUA is actually pEp-capable, even if the sender 1148 involved is in Passive Mode, too: this MUST be recognized by the "X- 1149 pEp-Version" header field, as the only clear indicator to detect pEp 1150 users. That means that a pEp-enabled MUA is REQUIRED to attach its 1151 corresponding public key to another pEp user in any case, such that 1152 they can engage in opportunistic encryption. 1154 [[ TODO: Add message examples and a flow chart, if needed ]] 1156 7.2. Option "Disable Protection" 1158 This is an opt-in mechanism to enforce that messages go out 1159 unprotected. Even if encryption keys for recipient(s) are available, 1160 this option MUST enforce that messages are sent in the Section 2.9.1 1161 format. 1163 7.3. Option "Extra Keys" 1165 [[ TODO: Add here what is specific to email ]] 1167 7.4. Option "Blacklist Keys" 1169 [[ TODO: Add here what is specific to email ]] 1171 7.5. Option "Trusted Server" 1173 [[ TODO: Add here what is specific to email ]] 1175 8. Security Considerations 1177 [[ TODO ]] 1179 9. Privacy Considerations 1181 [[ TODO ]] 1183 10. IANA Considerations 1185 This document has no actions for IANA. 1187 11. Implementation Status 1189 11.1. Introduction 1191 This section records the status of known implementations of the 1192 protocol defined by this specification at the time of posting of this 1193 Internet-Draft, and is based on a proposal described in [RFC7942]. 1194 The description of implementations in this section is intended to 1195 assist the IETF in its decision processes in progressing drafts to 1196 RFCs. Please note that the listing of any individual implementation 1197 here does not imply endorsement by the IETF. Furthermore, no effort 1198 has been spent to verify the information presented here that was 1199 supplied by IETF contributors. This is not intended as, and must not 1200 be construed to be, a catalog of available implementations or their 1201 features. Readers are advised to note that other implementations may 1202 exist. 1204 According to [RFC7942], "[...] this will allow reviewers and working 1205 groups to assign due consideration to documents that have the benefit 1206 of running code, which may serve as evidence of valuable 1207 experimentation and feedback that have made the implemented protocols 1208 more mature. It is up to the individual working groups to use this 1209 information as they see fit." 1211 11.2. Current software implementations of pEp 1213 The following software implementations of the pEp protocols (to 1214 varying degrees) already exists: 1216 o pEp for Outlook as add-on for Microsoft Outlook, release 1217 [SRC.pepforoutlook] 1219 o pEp for iOS (implemented in a new MUA), release [SRC.pepforios] 1221 o pEp for Android (based on a fork of the K9 MUA), release 1222 [SRC.pepforandroid] 1224 o pEp for Thunderbird as a new add-on for Thunderbird, beta 1225 [SRC.pepforthunderbird] 1227 o Enigmail/pEp as add-on for Mozilla Thunderbird, release (will be 1228 discontinued late 2020/early 2021) [SRC.enigmailpep] 1230 pEp for Android, iOS, Outlook and Thunderbird are provided by pEp 1231 Security, a commercial entity specializing in end-user pEp 1232 implementations while Enigmail/pEp is pursued as community project, 1233 supported by the pEp Foundation. 1235 All software is available as Free and Open Source Software and 1236 published also in source form. 1238 12. Acknowledgements 1240 Special thanks go to Krista Bennett and Volker Birk for the reference 1241 implementation on pEp and the ideas leading to this draft. 1243 The author would like to thank the following people who provided 1244 substantial contributions, helpful comments or suggestions for this 1245 document: Berna Alp, Kelly Bristol, Bernie Hoeneisen, Claudio Luck 1246 and Lars Rohwedder. 1248 This work was initially created by the pEp Foundation, and was 1249 initially reviewed and extended with funding by the Internet 1250 Society's Beyond the Net Programme on standardizing pEp. [ISOC.bnet] 1252 13. References 1254 13.1. Normative References 1256 [I-D.birk-pep] 1257 Birk, V., Marques, H., and B. Hoeneisen, "pretty Easy 1258 privacy (pEp): Privacy by Default", draft-birk-pep-05 1259 (work in progress), November 2019. 1261 [I-D.marques-pep-handshake] 1262 Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): 1263 Contact and Channel Authentication through Handshake", 1264 draft-marques-pep-handshake-05 (work in progress), July 1265 2020. 1267 [I-D.marques-pep-rating] 1268 Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): 1269 Mapping of Privacy Rating", draft-marques-pep-rating-03 1270 (work in progress), January 2020. 1272 [I-D.melnikov-iana-reg-forwarded] 1273 Melnikov, A. and B. Hoeneisen, "IANA Registration of 1274 Content-Type Header Field Parameter 'forwarded'", draft- 1275 melnikov-iana-reg-forwarded-00 (work in progress), 1276 November 2019. 1278 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 1279 "Security Multiparts for MIME: Multipart/Signed and 1280 Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, 1281 October 1995, . 1283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1284 Requirement Levels", BCP 14, RFC 2119, 1285 DOI 10.17487/RFC2119, March 1997, 1286 . 1288 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1289 "MIME Security with OpenPGP", RFC 3156, 1290 DOI 10.17487/RFC3156, August 2001, 1291 . 1293 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1294 Thayer, "OpenPGP Message Format", RFC 4880, 1295 DOI 10.17487/RFC4880, November 2007, 1296 . 1298 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1299 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1300 . 1302 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1303 DOI 10.17487/RFC5322, October 2008, 1304 . 1306 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1307 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1308 December 2014, . 1310 13.2. Informative References 1312 [I-D.birk-pep-trustwords] 1313 Hoeneisen, B. and H. Marques, "IANA Registration of 1314 Trustword Lists: Guide, Template and IANA Considerations", 1315 draft-birk-pep-trustwords-05 (work in progress), January 1316 2020. 1318 [I-D.pep-keysync] 1319 Birk, V., Hoeneisen, B., and K. Bristol, "pretty Easy 1320 privacy (pEp): Key Synchronization Protocol (KeySync)", 1321 draft-pep-keysync-02 (work in progress), July 2020. 1323 [ISOC.bnet] 1324 Simao, I., "Beyond the Net. 12 Innovative Projects 1325 Selected for Beyond the Net Funding. Implementing Privacy 1326 via Mass Encryption: Standardizing pretty Easy privacy's 1327 protocols", June 2017, . 1331 [pEp.mixnet] 1332 pEp Foundation, "Mixnet", June 2020, 1333 . 1335 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1336 Code: The Implementation Status Section", BCP 205, 1337 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1338 . 1340 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1341 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1342 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1343 April 2019, . 1345 [SRC.enigmailpep] 1346 "Source code for Enigmail/pEp", November 2020, 1347 . 1349 [SRC.pepforandroid] 1350 "Source code for pEp for Android", November 2020, 1351 . 1353 [SRC.pepforios] 1354 "Source code for pEp for iOS", November 2020, 1355 . 1357 [SRC.pepforoutlook] 1358 "Source code for pEp for Outlook", November 2020, 1359 . 1361 [SRC.pepforthunderbird] 1362 "Source code for pEp for Thunderbird", November 2020, 1363 . 1365 Appendix A. Document Changelog 1367 [[ RFC Editor: This section is to be removed before publication ]] 1369 o draft-pep-email-01: 1371 * Minor language improvements 1373 o draft-pep-email-00: 1375 * Major restructure of the document 1377 * Major fixes in the description of the various message formats 1379 * Add many open questions and comments inline (TODO) 1381 * Add IANA Considerations section 1383 * Change authors and acknowledgment section 1385 * Add internal references 1387 * Describe Passive Mode 1389 * Better explanation on how this document relates to other pEp 1390 documents 1392 o draft-marques-pep-email-02: 1394 * Add illustrations 1396 * Minor fixes 1398 * Add longer list of Open Issues (mainly by Bernie Hoeneisen) 1400 o draft-marques-pep-email-01: 1402 * Remove an artefact, fix typos and minor editorial changes; no 1403 changes in content 1405 o draft-marques-pep-email-00: 1407 * Initial version 1409 Appendix B. Open Issues 1411 [[ RFC Editor: This section should be empty and is to be removed 1412 before publication ]] 1414 o Eventually move the many TODOs into this Open Issues section. 1416 o Describe KeyImport to induce the import from secret keys from 1417 other devices 1419 o Describe / Reference KeySync (and other sync, through IMAP) 1421 o Add key pair revocation strategy 1423 o Create clearer relations to the pEp rating draft (draft-marques- 1424 pep-rating), as this plays an important role in how Messages are 1425 rendered and how they need to be presented (after rating) for a 1426 user to have awareness about his privacy status in any given 1427 situation. 1429 o Make document more coherent: check with pEp's general draft pieces 1430 to fill on both sides and how to reference them vice-versa (this 1431 is now pending on the reworked general draft to be published). 1433 o Elaborate more on the X-EncStatus header field and for Trusted 1434 Server situations / mirrors and describe operations. 1436 o Explain Key Mapping (between OpenPGP and S/MIME) 1438 Author's Address 1440 Hernani Marques 1441 pEp Foundation 1442 Oberer Graben 4 1443 CH-8400 Winterthur 1444 Switzerland 1446 Email: hernani.marques@pep.foundation 1447 URI: https://pep.foundation/