idnits 2.17.1 draft-marques-pep-email-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2018) is 2010 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-02 == Outdated reference: A later version (-05) exists of draft-marques-pep-handshake-00 ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Downref: Normative reference to an Informational RFC: RFC 7435 == Outdated reference: A later version (-05) exists of draft-birk-pep-trustwords-02 == Outdated reference: A later version (-03) exists of draft-marques-pep-rating-00 Summary: 3 errors (**), 0 flaws (~~), 5 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 October 24, 2018 5 Expires: April 27, 2019 7 pretty Easy privacy (pEp): Email Formats and Protocols 8 draft-marques-pep-email-02 10 Abstract 12 The pretty Easy privacy (pEp) propositions for email are based upon 13 already existing email and encryption formats (i.e., PGP/MIME) and 14 designed to allow for easy implementable and interoperable 15 opportunistic encryption: this ranging from key distribution to 16 mechanisms of subject encryption. 18 The goal of pEp for email is to automatize operations in order to 19 make email encryption usable by a wider range of Internet users, to 20 achieve wide application of confidentiality and privacy practices in 21 the real world. 23 This document defines basic operations of pEp's approach towards 24 email and two PGP/MIME formats (pEp Email Format 1 and 2) to provide 25 certain security guarantees. 27 The proposed operations and formats are targeted to Opportunistic 28 Security scenarios and are already implemented in several 29 applications of pretty Easy privacy (pEp). 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 27, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Opportunistic Security with pEp for email . . . . . . . . . . 5 68 3.1. Automatic keypair generation . . . . . . . . . . . . . . 5 69 3.2. Key Distribution . . . . . . . . . . . . . . . . . . . . 5 70 4. Encryption of email header fields and interoperability . . . 6 71 5. pEp message formats for email . . . . . . . . . . . . . . . . 6 72 5.1. Unencrypted plain text message with public key attached . 6 73 5.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 6 74 5.2. pEp email format version 1 . . . . . . . . . . . . . . . 7 75 5.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 8 76 5.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 9 77 5.3. pEp email format version 2 . . . . . . . . . . . . . . . 11 78 5.3.1. Example (Outer and Inner Message) . . . . . . . . . . 11 79 6. Rendering Incoming Messages and Message Rating . . . . . . . 13 80 7. Encryption to Bcc recipients . . . . . . . . . . . . . . . . 14 81 7.1. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 14 82 7.1.1. Split To and Cc recipients from Bcc recipients . . . 15 83 7.1.2. Split Bcc recipients in two groups . . . . . . . . . 15 84 7.1.3. Send one email with only To/Cc recipients . . . . . . 15 85 7.1.4. Send one Bcc email for the first Bcc group . . . . . 15 86 7.1.5. Send individual Bcc emails for the second group . . . 15 87 8. Saving messages . . . . . . . . . . . . . . . . . . . . . . . 15 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 90 10.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 16 91 10.2. Current software implementing pEp . . . . . . . . . . . 16 92 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 95 12.2. Informative References . . . . . . . . . . . . . . . . . 18 97 Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 19 98 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 19 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 101 1. Introduction 103 This document contains specific propositions to those parts of pretty 104 Easy privacy (pEp) [I-D.birk-pep] that are specific to email 105 [RFC5322]. 107 All changes required for the pEp propositions on email to work just 108 affect implementers of Mail User Agents (MUAs). 110 pretty Easy privacy (pEp) for email is a proposition to both, 111 implementers and Internet users, to make end-to-end encryption of 112 emails straightforward. 114 Whereas Pretty Good Privacy (PGP) and OpenPGP [RFC4880] provide a 115 basis for good encryption, we still miss implementations that also 116 provide a sufficient level of usability for ordinary Internet users. 118 Two users using pEp-enabled mail clients basically don't need to do 119 anything else than just writing emails. 121 The following example roughly describes a typical pEp scenario: 123 1. Alice - knowing nothing of Bob - just writes an email to Bob: 124 this mail is sent out unencrypted. However, Alice's public key 125 is automatically attached. 127 2. Bob can just reply to Alice and - as he got her public key - is 128 now able to encrypt a message at this point. Through a color- 129 rating (cf. [I-D.marques-pep-rating] Bob becomes aware of his 130 message now going out in a secure fashion. 132 3. As Alice receives Bob's key, as of now she is also able to send 133 secure messages to Bob. 135 4. If Alice and Bob want to prevent man-in-the-middle (MITM) 136 attacks, they can engage in a Handshake 137 [I-D.marques-pep-handshake], comparing their so-called Trustwords 138 [I-D.birk-pep-trustwords] and confirm this process if those 139 match. After doing so, their identity rating changes to 140 "encrypted and authenticated" [I-D.marques-pep-rating], which 141 (UX-wise) can be signaled, e.g., using a green color rating. 142 This color rating is also applied to messages (in- and outgoing). 144 ----- ----- 145 | A | | B | 146 ----- ----- 147 | | 148 +------------------------+ +------------------------+ 149 | auto-generate key pair | | auto-generate key pair | 150 | (if no key yet) | | (if no key yet) | 151 +------------------------+ +------------------------+ 152 | | 153 +-----------------------+ +-----------------------+ 154 | Privacy Status for B: | | Privacy Status for A: | 155 | *Unencrypted* | | *Unencrypted* | 156 +-----------------------+ +-----------------------+ 157 | | 158 | A sends message to B (Public Key | 159 | attached) / optionally signed, but | 160 | NOT ENCRYPTED | 161 +------------------------------------------>| 162 | | 163 | +-----------------------+ 164 | | Privacy Status for A: | 165 | | *Encrypted* | 166 | +-----------------------+ 167 | | 168 | B sends message to A (Public Key | 169 | attached) / signed and ENCRYPTED | 170 |<------------------------------------------+ 171 | | 172 +-----------------------+ | 173 | Privacy Status for B: | | 174 | *Encrypted* | | 175 +-----------------------+ | 176 | | 177 | A and B sucessfully compare their | 178 | Trustwords over an alternative channel | 179 | (e.g. phone line) | 180 |<-- -- -- -- -- -- -- -- -- -- -- -- -- -->| 181 | | 182 +-----------------------+ +-----------------------+ 183 | Privacy Status for B: | | Privacy Status for A: | 184 | *Trusted* | | *Trusted* | 185 +-----------------------+ +-----------------------+ 186 | | 188 This workflow is implemented as running code already in various pEp- 189 enabled software, cf. Section 10. 191 Note: No propositions are made at this point in time that would 192 require implementers to change the behavior or feature set of email 193 servers. Another Internet-Draft may propose changes to the Simple 194 Mail Transfer Protocol (SMTP) [RFC5321] as to allow for onion routing 195 of email messages in a way metadata can be furtherly protected for 196 communication peers - achievable by message encapsulation. pEp's 197 email message format 2 described below is already prepared for this 198 scenario. 200 2. Terms 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 o Handshake: The process when Alice - e.g. in-person or via phone - 207 contacts Bob to verify Trustwords (or by fallback: fingerprints) 208 is called Handshake. [I-D.marques-pep-handshake] 210 o Trustwords: A scalar-to-word representation of 16-bit numbers (0 211 to 65535) to natural language words. When doing a Handshake, 212 peers are shown combined Trustwords of both public keys involved 213 to ease the comparison. [I-D.birk-pep-trustwords] 215 o Trust on First Use (TOFU): cf. [RFC7435] 217 o Man-in-the-middle attack (MITM): cf. [RFC4949] 219 3. Opportunistic Security with pEp for email 221 3.1. Automatic keypair generation 223 For every email account a user has in a pEp-enabled Mail User Agent 224 (MUA), a different keypair SHOULD be used by default. If there are 225 no keys whatsoever, RSA-4096 keypairs for OpenPGP encryption 226 [RFC4880] SHOULD be generated automatically for each email account. 227 However, the key length MUST be at least RSA-2048. 229 If for an identity there's an RSA keypair with less than 2048 bits, 230 new keys MUST be generated. 232 [[ TODO: Shouldn't this go to general I-D ]] 234 3.2. Key Distribution 236 By default, public keys MUST always be attached to any outgoing 237 message. 239 4. Encryption of email header fields and interoperability 241 In pEp, implementers MUST put privacy first: email metadata (i.e., 242 headers) MUST either be omitted or encrypted whenever possible. 244 In case of email header encryption: implementers of pEp SHOULD be 245 liberal in accepting other approaches to encrypt email headers, but 246 MUST use the strict and interoperable pEp formats for any outgoing 247 communication. 249 5. pEp message formats for email 251 The pEp message formats 1 and 2 (as described in the following) are 252 email security formats used for sending signed and encrypted emails 253 whenever public key(s) for the recipient(s) exist. 255 5.1. Unencrypted plain text message with public key attached 257 If for a recipient there's no public key available, a pEp message 258 MUST be sent out in plain text as MIME message version 1, with 259 "Content-Type: multipart/mixed" and the OpenPGP public key attached 260 in ASCII armored format, named "pEpkey.asc". 262 For a MUA implementer this fulfills two functions: 264 1. It can be easily detected that the sender is a pEp user. 266 2. The MUA (if at least OpenPGP-enabled) can enable the receiving 267 user to import the public key to engage in end-to-end encryption 268 with the sender; a MUA implementer can also decide to 269 automatically import the key such that the user can immediately 270 engage in opportunistic encryption. 272 The plain text messages SHOULD be sent out with the UTF-8 charset 273 Content-Type set. 275 5.1.1. Example 277 Please note that in the following examples the "pEpkey.asc" 278 attachments encoded in base64 format are only shown in its first and 279 last line (and otherwise shortened by three points). 281 From: John Doe 282 To: Mary Smith 283 Subject: Test 284 MIME-Version: 1.0 285 Content-Type: multipart/mixed; 286 boundary="----3YNFBU8B6LV244ZJNQZL12LVUAPGG6" 287 Content-Transfer-Encoding: 7bit 289 ------3YNFBU8B6LV244ZJNQZL12LVUAPGG6 290 Content-Transfer-Encoding: quoted-printable 291 Content-Type: text/plain; 292 charset=UTF-8 294 Test 296 ------3YNFBU8B6LV244ZJNQZL12LVUAPGG6 297 Content-Type: application/pgp-keys; 298 name="pEpkey.asc" 299 Content-Transfer-Encoding: base64 300 Content-Disposition: attachment; 301 filename="pEpkey.asc"; 302 size=3813 304 LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkZxNWlkd 305 ... 306 SUXFhQT09Cj1adlFnCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZIEJMT0NLLS0tLS0K 308 ------3YNFBU8B6LV244ZJNQZL12LVUAPGG6-- 310 5.2. pEp email format version 1 312 pEp email format 1 is an encrypted and signed PGP/MIME format, which 313 by default ensures: 315 o correctly signed messages 317 o delivery of public keys (at least and automatically: the sender's 318 public key) 320 By default, when a public key for a peer is available, pEp-capable 321 MUAs are REQUIRED to send out email messages according to [RFC5322] 322 and in PGP/MIME format [RFC3156] with the informational "Subject:" 323 header field set to "pEp", as follows: 325 Subject: pEp 327 In turn, the intended human-readable subject (in pEp called short 328 message) MUST be moved to the body of the message (in pEp called long 329 message) and appear as the first line there. pEp implementers are 330 REQUIRED to display the intended "Subject:" field as the real subject 331 line in the respective MUAs to help users to easily grasp the real 332 subject. 334 Alternatively, the "Subject:" header field can also be set to its 335 UTF-8 variant with "pEp" written with the equivalence symbol instead 336 of an "E": 338 Subject: =?utf-8?Q?p=E2=89=A1p?= 340 Additionally, a header field "X-Pep-Version: 1.0" is added to signal 341 compatibility with pEp email format to pEp-enabled MUAs. 343 5.2.1. Example 1 345 Example. Using the well-known example of [RFC5322], an email message 346 sent out with pEp in message format 1 looks like this: 348 From: John Doe 349 Sender: Michael Jones 350 To: Mary Smith 351 Subject: pEp 352 Date: Fri, 30 Jun 2018 09:55:06 +0200 353 Message-ID: <1234@local.machine.example> 354 MIME-Version: 1.0 355 Content-Type: multipart/mixed; 356 boundary="----=_NextPart_000_0016_01D0E64A.33EC31B" 357 Content-Language: en-us 358 X-Pep-Version: 1.0 360 This is a multipart message in MIME format. 362 ------=_NextPart_000_0016_01D0E64A.33EC31B 363 Content-Type: text/plain; charset="utf-8" 364 Content-Transfer-Encoding: 7bit 366 -----BEGIN PGP MESSAGE----- 367 hQIMAwusnBHN80H+AQ//cJLQLOl+6hOofKEkQJeu0wedmwt+TkzPx/sCUQ80dzLv 368 ... 369 j/ES8ndDBftM5mZLzFQ2VatqB9G9cqCgiOVFs6jfTI13nPfLit9IPWRavcVIMdwt 370 Xd9bdvHx/ReenAk/ 371 =7WaL 372 -----END PGP MESSAGE----- 374 ------=_NextPart_000_0060_01D0EAEF.2D54F450 375 Content-Type: application/pgp-keys; name="pEpkey.asc" 376 Content-Transfer-Encoding: 7bit 377 Content-Disposition: attachment; filename="pEpkey.asc" 379 -----BEGIN PGP PUBLIC KEY BLOCK----- 380 mQINBFQRqIcBEACpsz3mK1zqPdqDlxU6Yws/Xz14LJpszDLlKJckpa7hSc9jfZ4Q 381 ... 382 Ag7IIk/Gj628hYTdCpNCUc9b1vS6xMAkxJWYgNVwLFS2goikEHCiyzDe 383 =MicJ 384 -----END PGP PUBLIC KEY BLOCK----- 386 ------=_NextPart_000_0060_01D0EAEF.2D54F450-- 388 5.2.2. Example 2 390 Using the UTF-8 variant of writing "pEp" with the equivalence symbol, 391 and an additional document attached (an example PDF attachment), an 392 OpenPGP-signed and -encrypted pEp email would look like the 393 following: 395 From: John Doe 396 Sender: Michael Jones 397 To: Mary Smith 398 Subject: =?utf-8?Q?p=E2=89=A1p?= 399 Date: Fri, 30 Jun 2018 09:55:06 +0200 400 Message-ID: <1234@local.machine.example> 401 MIME-Version: 1.0 402 Content-Type: multipart/mixed; 403 boundary="----=_NextPart_000_0016_01D0E64A.33EC31B" 404 Content-Language: en-us 405 X-Pep-Version: 1.0 407 This is a multipart message in MIME format. 409 ------=_NextPart_000_0016_01D0E64A.33EC31B 410 Content-Type: text/plain; charset="utf-8" 411 Content-Transfer-Encoding: 7bit 413 -----BEGIN PGP MESSAGE----- 414 hQIMAwusnBHN80H+AQ//cJLQLOl+6hOofKEkQJeu0wedmwt+TkzPx/sCUQ80dzLv 415 ... 416 j/ES8ndDBftM5mZLzFQ2VatqB9G9cqCgiOVFs6jfTI13nPfLit9IPWRavcVIMdwt 417 Xd9bdvHx/ReenAk/ 418 =7WaL 419 -----END PGP MESSAGE----- 421 ------=_NextPart_000_003A_01D10CF6.2DA15150 422 Content-Type: application/octet-stream; name="example.pdf.pgp" 423 Content-Transfer-Encoding: 7bit 424 Content-Disposition: attachment; filename="example.pdf.pgp" 426 -----BEGIN PGP MESSAGE----- 427 hQIMA/bohV/mG7k7ARAAyy+sdpZYZBhUH/p0gJ+wIlEGTTG2rjLpLuixBrm5Cuj3 428 ... 429 oAXrQJJgD0F3Ung24Kkundua2gSa9cyeYvUXtA2mbXT7YyN7RdxrMFNfdVFqXZEc 430 pXqIjL2uKBbyjpS44fc3GmOZNih3bI6q8nl/ 431 =Mvna 433 ------=_NextPart_000_0060_01D0EAEF.2D54F450 434 Content-Type: application/pgp-keys; name="pEpkey.asc" 435 Content-Transfer-Encoding: 7bit 436 Content-Disposition: attachment; filename="pEpkey.asc" 438 -----BEGIN PGP PUBLIC KEY BLOCK----- 439 mQINBFQRqIcBEACpsz3mK1zqPdqDlxU6Yws/Xz14LJpszDLlKJckpa7hSc9jfZ4Q 440 ... 441 Ag7IIk/Gj628hYTdCpNCUc9b1vS6xMAkxJWYgNVwLFS2goikEHCiyzDe 442 =MicJ 443 -----END PGP PUBLIC KEY BLOCK----- 445 ------=_NextPart_000_0060_01D0EAEF.2D54F450-- 447 5.3. pEp email format version 2 449 pEp email format 2 is a strict PGP/MIME format, which by default 450 ensures: 452 o correctly signed messages 454 o delivery of public keys (at least: the sender's public key) 456 In pEp email format 2 the actual email is encapsulated by an outside 457 multipart/encrypted message (i.e., the actual email is sent like a 458 forwarded message). 460 Headers of messages (received, to be forwarded etc.) can thus be 461 preserved in the inner message, which is OpenPGP-signed and 462 -encrypted by the application/pgp-encrypted "Content-Type". 464 In the outer message, unnecessary email headers MUST be omitted to 465 the fullest extent. 467 In contrast to pEp email format 1, the public key and other files 468 attached cannot be seen in the MIME tree. The only part which can be 469 seen is an application/octet-stream "Content-Type" with name 470 "msg.asc". 472 5.3.1. Example (Outer and Inner Message) 474 A pEp email format 2 message, with the "Subject:" header field set to 475 "pEp" looks like the following (please note that the inner message is 476 fully contained in the OpenPGP-signed and -encrypted file named 477 "msg.asc", including possible attachments and with the sender's 478 public key as "pEpkey.asc" attached at the very end): 480 From: John Doe 481 Sender: Michael Jones 482 To: Mary Smith 483 Subject: =?utf-8?Q?p=E2=89=A1p?= 484 Date: Fri, 30 Jun 2018 09:55:06 +0200 485 Message-ID: <1234@local.machine.example> 486 MIME-Version: 1.0 487 Subject: pEp 488 X-Pep-Version: 2.0 489 Content-Type: multipart/encrypted; 490 boundary="261a304d18692673570d913f7e24b8cb"; 491 protocol="application/pgp-encrypted" 493 --261a304d18692673570d913f7e24b8cb 494 Content-Type: application/pgp-encrypted 496 Version: 1 497 --261a304d18692673570d913f7e24b8cb 498 Content-Type: application/octet-stream 499 Content-Transfer-Encoding: 7bit 500 Content-Disposition: inline; filename="msg.asc" 502 -----BEGIN PGP MESSAGE----- 504 hQGMAzDKu5MiiyCzAQv9Edg8ulxgxyQfiZRxOpThL0aMFkK7JZH7AJfgdxunLAJk 505 ... 506 a2jDdzNxotItZk8tWW2h/REdKtRMyXg633DyFLbsIx+cCMnMR1NDChCzvyzUjAw6 507 XeCGXnY3LB1K 508 =sdgE 509 -----END PGP MESSAGE----- 511 --261a304d18692673570d913f7e24b8cb-- 513 The inner message in a simple form without further nesting might look 514 like the following, when decrypted: 516 MIME-Version: 1.0 517 Content-Type: multipart/mixed; 518 boundary="17d3c87b380049a821c764604aaf9272" 520 --17d3c87b380049a821c764604aaf9272 521 Content-Type: text/plain; charset="utf-8" 522 Content-Transfer-Encoding: quoted-printable 523 Content-Disposition: inline; filename="msg.txt" 525 Subject: The real encrypted subject 527 Hello, there! 529 --17d3c87b380049a821c764604aaf9272 530 Content-Type: application/pgp-keys 531 Content-Disposition: attachment; filename="pEpkey.asc" 533 -----BEGIN PGP PUBLIC KEY BLOCK----- 534 mQGNBFmwE70BDACyR/yQ48QSaQAZyvyUgp7f/4WXxiX1OS9vC/UuewdGLosvl3G+ 535 ... 536 A0KQ6HDwLFuLzneg6Nse4pX0hNWGbLNCouYKdL3vfUHokqp/MTzxyPQlOadDHrDV 537 H9RC4kMrB/ONGe5yn+u4zjrgq9gWCbdJ43fMoiU3lfMIKy5sZ2NPzh9l 538 =p5bZ 539 -----END PGP PUBLIC KEY BLOCK----- 541 It does not only carry the encrypted subject, which pEp implementers 542 are supposed to map (UX-wise) such as to replace the "pEp" subject in 543 the outer message, but also the actual message (as inline file named 544 "msg.txt" in case of plain text) as well as the sender's public key. 546 6. Rendering Incoming Messages and Message Rating 548 pEp-enabled clients MUST NOT blindly render messages. Special care 549 MUST be taken when rendering the pEp email formats, which provide 550 certain guarantees: 552 +--------------+----------------+--------+--------------------------+ 553 | Message | Error State | Render | Status Code | 554 | Format | | | | 555 +--------------+----------------+--------+--------------------------+ 556 | PGP/MIME | Unsigned | Yes | DECRYPTED_BUT_UNSIGNED | 557 | | Signed, no key | Yes | NO_KEY_FOR_SIGNER | 558 | | Bad signature | No | SIGNATURE_DOES_NOT_MATCH | 559 +--------------+----------------+--------+--------------------------+ 560 | pEp Email | Unsigned | No | DECRYPTED_BUT_UNSIGNED | 561 | 1.0 | Signed, no key | No | NO_KEY_FOR_SIGNER | 562 | | Bad signature | No | SIGNATURE_DOES_NOT_MATCH | 563 +--------------+----------------+--------+--------------------------+ 564 | pEp Email | Unsigned | No | MODIFICATION_DETECTED | 565 | 2.0 | Signed, no key | No | MODIFICATION_DETECTED | 566 | | Bad signature | No | SIGNATURE_DOES_NOT_MATCH | 567 +--------------+----------------+--------+--------------------------+ 569 For cases where messages appear unsigned, signed without a key or 570 with a bad signature, pEp's privacy rating can be employed to signal 571 issues to a user in an easily understandable manner, cf. 572 [I-D.marques-pep-rating]. 574 [[TODO: This needs more work to be understandable. ]] 576 7. Encryption to Bcc recipients 578 7.1. Algorithm 580 For encryption of emails that contain Bcc recipients a simple 581 algorithm MAY be used. 583 Recipients MUST be partitioned into three lists, one for each of 584 three possible outgoing messages: 586 1. To and Cc recipients (without Bcc recipients) 588 2. Bcc recipients unable to encrypt 590 3. Bcc recipients able to encrypt 592 It's RECOMMENDED that if the original message the user drafted is 593 saved in the user's sent folder, that all recipient fields ("To:", 594 "Cc:", "Bcc:") be preserved. 596 7.1.1. Split To and Cc recipients from Bcc recipients 598 To and Cc recipients MUST be split from the Bcc recipients. 600 7.1.2. Split Bcc recipients in two groups 602 Bcc recipients MUST be split in two groups: 604 o First group of Bcc recipients who will receive clear text emails. 606 o Second group of Bcc recipients who are able to receive encrypted 607 emails. 609 7.1.3. Send one email with only To/Cc recipients 611 The original email the user drafted SHOULD be sent out with the 612 "Bcc:" field removed. 614 7.1.4. Send one Bcc email for the first Bcc group 616 For the first Bcc group, a regular email message with only Bcc 617 recipients is sent. 619 7.1.5. Send individual Bcc emails for the second group 621 For the second group, individual Bcc email messages are sent. 623 [[TODO: This needs more work to make it better understandable. ]] 625 8. Saving messages 627 [[ TODO: Shouldn't this go to general [] 629 In accordance to the Privacy by Default principle, messages sent or 630 received in encrypted form SHALL be saved with the peer's respective 631 public key. 633 Messages sent or received in unencrypted form, SHOULD NOT be saved in 634 encrypted form on the mail server: this reflects the Privacy Status 635 the user encountered when sending or receiving the email and thus 636 meets the user's expectations. 638 Instead, message drafts MUST always be saved with the user's public 639 key. 641 Other messages sent and received MUST be saved encrypted by default: 642 for most end-user scenarios, the servers users work with, are 643 considered untrusted. 645 For trusted environments (e.g., in organizations) and to conform to 646 legally binding regulations, pEp implementations MUST provide a 647 "Trusted Server" option. With the user's explicit consent (opt-in), 648 unencrypted copies of the messages SHALL be held on the mail servers 649 controlled by the organization. This can also help end-users to 650 archive their emails without needing access to any key material. 652 9. Security Considerations 654 [[ TODO ]] 656 10. Implementation Status 658 10.1. Introduction 660 This section records the status of known implementations of the 661 protocol defined by this specification at the time of posting of this 662 Internet-Draft, and is based on a proposal described in [RFC7942]. 663 The description of implementations in this section is intended to 664 assist the IETF in its decision processes in progressing drafts to 665 RFCs. Please note that the listing of any individual implementation 666 here does not imply endorsement by the IETF. Furthermore, no effort 667 has been spent to verify the information presented here that was 668 supplied by IETF contributors. This is not intended as, and must not 669 be construed to be, a catalog of available implementations or their 670 features. Readers are advised to note that other implementations may 671 exist. 673 According to [RFC7942], "[...] this will allow reviewers and working 674 groups to assign due consideration to documents that have the benefit 675 of running code, which may serve as evidence of valuable 676 experimentation and feedback that have made the implemented protocols 677 more mature. It is up to the individual working groups to use this 678 information as they see fit." 680 10.2. Current software implementing pEp 682 The following software implementing the pEp protocols (to varying 683 degrees) already exists: 685 o pEp for Outlook as add-on for Microsoft Outlook, release 686 [SRC.pepforoutlook] 688 o pEp for Android (based on a fork of the K9 MUA), release 689 [SRC.pepforandroid] 691 o Enigmail/pEp as add-on for Mozilla Thunderbird, release 692 [SRC.enigmailpep] 694 o pEp for iOS (implemented in a new MUA), beta [SRC.pepforios] 696 pEp for Android, iOS and Outlook are provided by pEp Security, a 697 commercial entity specializing in end-user software implementing pEp 698 while Enigmail/pEp is pursued as community project, supported by the 699 pEp Foundation. 701 All software is available as Free Software and published also in 702 source form. 704 11. Acknowledgements 706 Special thanks go to Krista Bennet and Volker Birk for the reference 707 implementation on pEp and the ideas leading to this draft. 709 This work was initially created by pEp Foundation, and will be 710 reviewed and extended with funding by the Internet Society's Beyond 711 the Net Programme on standardizing pEp. [ISOC.bnet] 713 12. References 715 12.1. Normative References 717 [I-D.birk-pep] 718 Birk, V., Marques, H., and S. Shelburn, "pretty Easy 719 privacy (pEp): Privacy by Default", draft-birk-pep-02 720 (work in progress), June 2018. 722 [I-D.marques-pep-handshake] 723 Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): 724 Contact and Channel Authentication through Handshake", 725 draft-marques-pep-handshake-00 (work in progress), June 726 2018. 728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 729 Requirement Levels", BCP 14, RFC 2119, 730 DOI 10.17487/RFC2119, March 1997, 731 . 733 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 734 "MIME Security with OpenPGP", RFC 3156, 735 DOI 10.17487/RFC3156, August 2001, 736 . 738 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 739 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 740 . 742 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 743 DOI 10.17487/RFC5322, October 2008, 744 . 746 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 747 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 748 December 2014, . 750 12.2. Informative References 752 [I-D.birk-pep-trustwords] 753 Birk, V., Marques, H., and B. Hoeneisen, "IANA 754 Registration of Trustword Lists: Guide, Template and IANA 755 Considerations", draft-birk-pep-trustwords-02 (work in 756 progress), June 2018. 758 [I-D.marques-pep-rating] 759 Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): 760 Mapping of Privacy Rating", draft-marques-pep-rating-00 761 (work in progress), July 2018. 763 [ISOC.bnet] 764 Simao, I., "Beyond the Net. 12 Innovative Projects 765 Selected for Beyond the Net Funding. Implementing Privacy 766 via Mass Encryption: Standardizing pretty Easy privacy's 767 protocols", June 2017, . 771 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 772 Thayer, "OpenPGP Message Format", RFC 4880, 773 DOI 10.17487/RFC4880, November 2007, 774 . 776 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 777 DOI 10.17487/RFC5321, October 2008, 778 . 780 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 781 Code: The Implementation Status Section", BCP 205, 782 RFC 7942, DOI 10.17487/RFC7942, July 2016, 783 . 785 [SRC.enigmailpep] 786 "Source code for Enigmail/pEp", July 2018, 787 . 789 [SRC.pepforandroid] 790 "Source code for pEp for Android", July 2018, 791 . 793 [SRC.pepforios] 794 "Source code for pEp for iOS", July 2018, 795 . 797 [SRC.pepforoutlook] 798 "Source code for pEp for Outlook", July 2018, 799 . 801 Appendix A. Document Changelog 803 [[ RFC Editor: This section is to be removed before publication ]] 805 o draft-marques-pep-email-02: 807 * Add illustrations 809 * Minor fixes 811 * Add longer list of Open Issues (mainly by Bernie Hoeneisen) 813 o draft-marques-pep-email-01: 815 * Remove an artefact, fix typos and minor editorial changes; no 816 changes in content 818 o draft-marques-pep-email-00: 820 * Initial version 822 Appendix B. Open Issues 824 [[ RFC Editor: This section should be empty and is to be removed 825 before publication ]] 827 o Ship better example of pEp Message Format 2 829 o Elaborate on omitting headers and better explain pEp Message 830 Format 2 832 o Add notes on EFAIL 834 o Describe KeyImport to induce the import from secret keys from 835 other devices 837 o Describe / Reference KeySync (and other sync, through IMAP) 839 o Add keypair revocation strategy 841 o Better describe required MIME fields and parameters to set for the 842 pEp email formats 844 o Create clearer relations to the pEp rating draft (draft-marques- 845 pep-rating), as this plays an important role in how messages are 846 rendered and how they need to be presented (after rating) for a 847 user to have awareness about his privacy status in any given 848 situation. 850 o Make document more coherent: check with pEp's general draft pieces 851 to fill on both sides and how to reference them vice-versa. 853 o Add existence of internally exposed X-EncStatus header field after 854 decrypt and for Trusted Server situations / mirrors and describe 855 operations. 857 o Add references to https://www.ietf.org/archive/id/draft-melnikov- 858 smime-header-signing-05.txt and https://tools.ietf.org/html/draft- 859 schaad-rfc5751-bis, as well as align text with those (e.g. 860 forwarded=no) 862 o Fix wrong stuff around pEp Message Format 2, especially 863 considering the encryption of the whole inner message (including 864 To, Cc, and other fields) when dealing with pEp users. 866 o Add pEp Message Format 2.1 (additonal MIME container with preview 867 of all headers and some of the initial body text; special case: 868 how to treat HTML; e.g., show a text-only snippet?) 870 Author's Address 872 Hernani Marques 873 pEp Foundation 874 Oberer Graben 4 875 CH-8400 Winterthur 876 Switzerland 878 Email: hernani.marques@pep.foundation 879 URI: https://pep.foundation/