idnits 2.17.1 draft-birk-pep-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 == 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: If there is already a known public key from the sender of a message and it is still valid and not expired, new keys MUST not be used for future communication, unless they are signed by the previous key (to avoid a MITM attack). Messages MUST always be encrypted with the receiving peer's oldest public key, as long as it is valid and not expired. == 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 'SHALL not' in this paragraph: This option SHALL not affect the user's ability to decipher already received or sent messages. [[ TODO: Public key added in these cases? ]] -- The document date (June 27, 2018) is 2101 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) -- Looks like a reference, but probably isn't: '3' on line 842 ** 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 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Birk 3 Internet-Draft H. Marques 4 Intended status: Standards Track S. Shelburn 5 Expires: December 29, 2018 pEp Foundation 6 June 27, 2018 8 pretty Easy privacy (pEp): Privacy by Default 9 draft-birk-pep-02 11 Abstract 13 Building on already available security formats and message transports 14 (like PGP/MIME for email), and with the intention to stay 15 interoperable to systems widespreadly deployed, pretty Easy privacy 16 (pEp) describes protocols to automatize operations (key management, 17 key discovery, private key handling including peer-to-peer 18 synchronization of private keys and other user data across devices) 19 that have been seen to be barriers to deployment of end-to-end secure 20 interpersonal messaging. pEp also relies on "Trustwords" (as a word 21 mapping of of fingerprints) to verify communication peers and 22 proposes a trust rating system to denote secure types of 23 communications and signal the privacy level available on a per-user 24 and per-message level. In this document, the general design choices 25 and principles of pEp are outlined. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 29, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Protocol's Core Design Principles . . . . . . . . . . . . . . 4 64 3.1. Privacy by Default . . . . . . . . . . . . . . . . . . . 4 65 3.2. Interoperability . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Peer-to-Peer (P2P) . . . . . . . . . . . . . . . . . . . 5 67 3.4. User Experience (UX) . . . . . . . . . . . . . . . . . . 6 68 4. pEp identity system . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.1.1. Key . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1.2. User . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1.3. Address . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 7 74 4.2. Example: Difference between pEp and OpenPGP . . . . . . . 8 75 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . 8 76 5.1. Private Keys . . . . . . . . . . . . . . . . . . . . . . 9 77 5.2. Public Key Distribution . . . . . . . . . . . . . . . . . 9 78 5.3. Passphrases . . . . . . . . . . . . . . . . . . . . . . . 10 79 6. Privacy Status . . . . . . . . . . . . . . . . . . . . . . . 10 80 7. Options in pEp . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. Option "Passive Mode" . . . . . . . . . . . . . . . . . . 11 82 7.2. Option "Disable Protection" . . . . . . . . . . . . . . . 11 83 7.2.1. For all communications . . . . . . . . . . . . . . . 11 84 7.2.2. For some communications . . . . . . . . . . . . . . . 11 85 7.3. Option "Extra Keys" . . . . . . . . . . . . . . . . . . . 12 86 7.4. Option "Blacklist Keys" . . . . . . . . . . . . . . . . . 12 87 7.5. Establishing trust between peers . . . . . . . . . . . . 12 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 89 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 90 9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 13 91 9.2. Reference implementation of pEp's core . . . . . . . . . 13 92 9.3. Abstract Crypto API examples . . . . . . . . . . . . . . 14 93 9.4. Current software implementing pEp . . . . . . . . . . . . 15 94 10. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 98 12.2. Informative References . . . . . . . . . . . . . . . . . 16 99 Appendix A. Excerpts from the pEp Reference Implementation . . . 18 100 A.1. pEp Identity . . . . . . . . . . . . . . . . . . . . . . 18 101 A.1.1. Corresponding SQL . . . . . . . . . . . . . . . . . . 19 102 A.2. pEp Communication Type . . . . . . . . . . . . . . . . . 20 103 A.3. Abstract Crypto API examples . . . . . . . . . . . . . . 21 104 A.3.1. Encrypting a Message . . . . . . . . . . . . . . . . 21 105 A.3.2. Decrypting a Message . . . . . . . . . . . . . . . . 22 106 A.3.3. Obtain Common Trustwords . . . . . . . . . . . . . . 24 107 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 24 108 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 25 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 111 1. Introduction 113 The pretty Easy privacy (pEp) protocols are propositions to the 114 Internet community to create software for peers to automatically 115 encrypt, anonymize (where possible, depending on the message 116 transport used) and verify their daily written digital communications 117 - this is done by building upon already existing standards and tools 118 and automatizing all steps a user would need to carry out to engage 119 in secure end-to-end encrypted communications without depending on 120 centralized infrastructures. 122 Particularly, pEp proposes to automatize key management, key 123 discovery and also synchronization of secret key material by an in- 124 band peer-to-peer approach. 126 To mitigate Man-In-The-Middle Attacks (MITM) and as the only manual 127 step users may carry out, Trustwords [I-D.birk-pep-trustwords] as 128 natural language representations of two peers' fingerprints are 129 proposed, for peers to put trust on their communication channel. 131 [[ Note: The pEp initiators had to learn from the CryptoParty 132 movement, from which the project emerged, that step-by-step guides 133 can be helpful to a particular set of users to engage in secure end- 134 to-end communications, but that for a much major fraction of users it 135 would be more convenient to have the step-by-step procedures put into 136 actual code (as such, following a protocol) and thus automatizing the 137 initial configuration and whole usage of cryptographic tools.]] 139 The Privacy by Default principles that pretty Easy privacy (pEp) 140 introduces, are in accordance with the perspective outlined in 141 [RFC7435] to bring Opportunistic Security in the sense of "some 142 protection most of the time", with the subtle, but important 143 difference that when privacy is weighted against security, the choice 144 falls to privacy. Therefore, data minimization is a primary goal in 145 pEp (e.g., omitting unnecessary email headers and encrypting the 146 subject line). 148 The pEp propositions are focused on (but not limited to) written 149 digital communications and cover asynchronous (offline) types of 150 communications like email as well as synchronous (online) types such 151 as chat. 153 pEp's goal is to bridge the different standardized and/or widely 154 spread communications channels, such that users can reach their peers 155 in the most privacy-enhancing way possible. 157 [[At this stage it is not year clear to us how many of our 158 implementation details should be part of new RFCs and at which places 159 we can safely refer to already existing RFCs to make clear on which 160 RFCs we are already relying.]] 162 2. Terms 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 o Handshake: The process when Alice - e.g. in-person or via phone - 169 contacts Bob to verify Trustwords (or by fallback: fingerprints) 170 is called handshake. [E-D.birk-pep-handshake] 172 o Trustwords: A scalar-to-word representation of 16-bit numbers (0 173 to 65535) to natural language words. When doing a handshake, 174 peers are shown combined Trustwords of both public keys involved 175 to ease the comparison. [I-D.birk-pep-trustwords] 177 o Trust on First Use (TOFU): cf. [RFC7435] 179 o Man-in-the-middle attack (MITM): cf. [RFC4949] 181 3. Protocol's Core Design Principles 183 3.1. Privacy by Default 185 The pEp protocols are about to ensure privacy. However, there are 186 cases where privacy and security are contradicting, e.g., in PGP's 187 Web of Trust, because relations between people and trust levels are 188 leaked. Also query privacy is not ensured in such a model when 189 obtaining keys from remote locations. Whenever security and privacy 190 fit together, highest security and privacy is to be reached. 191 However, where they contradict each other, privacy is always to be 192 chosen over security. Though, users SHOULD have the choice to 193 override the default by corresponding options. 195 In pEp messaging (e.g., when using HTML) content SHALL NOT be 196 obtained from remote locations as this constitutes a privacy breach. 198 3.2. Interoperability 200 The pEp propositions seek to be interoperable with message formats 201 and cryptography already widespread. Seamless communication between 202 users of software, which implements pEp and other messaging tools for 203 end-to-end encryption, is a design goal. 205 Therefore: 207 o Be conservative (strict) in requirements for pEp implementations 208 and how they behave between each other. 210 o Be liberal (accepting) in what comes in from non-pEp 211 implementations (e.g., do not send, but support to decipher PGP/ 212 INLINE formats). 214 o Where pEp requires diverging from an RFC for privacy reasons 215 (e.g., from OpenPGP propositions as defined in [RFC4880], options 216 SHOULD be implemented to empower the user to comply to practices 217 already (widespreadly) used (either at contact level or globally). 219 3.3. Peer-to-Peer (P2P) 221 Messaging and verification processes in pEp are designed to work 222 Peer-to-Peer (P2P) without intermediaries in between. 224 This means, there MUST NOT be any pEp-specific central services 225 whatsoever needed for implementers of pEp to rely on, neither for 226 verification of peers nor for the actual encryption. 228 Still, implementers of pEp MAY provide options to interoperate with 229 providers of centralized infrastructures (e.g., to enable users to 230 communicate with their peers on platforms with vendor lock-in). 232 Trust provided by global Certificate Authorities (e.g., commercial 233 X.509 CAs) SHALL NOT be signaled as trustworthy (cf. 234 [E-D.birk-pep-trust-rating]) to users of pEp (e.g., when 235 interoperating with peers using S/MIME) by default. 237 3.4. User Experience (UX) 239 Implementers of pEp MUST take special care not to confuse users with 240 technical terms, especially those of cryptography (e.g., "keys", 241 "certificates" or "fingerprints"), unless users explicitly ask for 242 such terms; i.e., advanced settings MAY be available, in some cases 243 further options may even be required. However, those SHALL NOT be 244 unnecessarily exposed to users of pEp implementations at the first 245 sight. 247 The authors believe widespread adoption of end-to-end cryptography is 248 much less of an issue, if the users are not hassled and visibly 249 forced in any way to use cryptography, i.e., a goal of pEp is that 250 users can just rely on the principles of Privacy by Default. 252 By consequence, this means that users must not wait for cryptographic 253 tasks (e.g., key generation or public key retrieval) to finish, 254 before being able to have their respective message clients ready to 255 communicate. This finally means, pEp implementers MUST ensure that 256 the ability to draft, send and receive messages is always preserved - 257 even if that means a message is sent out unencrypted, thus being in 258 accordance with the Opportunistic Security approach outlined in 259 [RFC7435]. 261 In turn, pEp implementers MUST ensure a Privacy Status is clearly 262 visible to the user - on contact as well as on message level - so 263 that users easily understand, which level of privacy messages are 264 about to be sent or were received with, respectively. 266 [[Note: We are aware of the fact that usually UX requirements are not 267 part of RFCs. However, to have massively more people engaged in 268 secure end-to-end encryption and at the same time to avoid putting 269 users at risk, we believe requiring certain straightforward signaling 270 for the users to be a good idea - in a similar way as this happens to 271 be the case for already popular Instant Messaging services.]] 273 4. pEp identity system 275 In pEp, users MUST have the possibility to have different identities. 277 pEp users MUST have the option to choose different identities. This 278 allows an Internet user to decide how to reveal oneself to the world 279 and is an important element to achieve privacy. 281 The different identities MUST NOT correlate with other by default. 282 On the other hand, combining different identities MUST be supported 283 (to support aliases). 285 4.1. Terms 287 4.1.1. Key 289 A key is an OpenPGP compatible asymmetric key pair. Other formats 290 and temporary symmetrical keys can be generated by Key Mapping. 292 Keys in pEp are identified by the full fingerprint (fpr) of its 293 public key. 295 4.1.2. User 297 A user is a real world human being or a group of human beings. If it 298 is a single human being, it can be called person. 300 A user is identified by a user ID (user_id). The user_id SHOULD be 301 an UUID, it MAY be an arbitrary unique string. 303 The own user can have a user_id like all other users. If it doesn't, 304 then it has PEP_OWN_USERID "pEp_own_userId" as user_id. 306 A user can have a default key. 308 4.1.3. Address 310 An address is a network address, e.g., an SMTP address or another 311 URI. 313 [[ Note: It might be necessary to introduce further addressing 314 schemes through IETF contributions or IANA registrations, e.g., 315 implementing pEp to bridge to popular messaging services with no URIs 316 defined. ]] 318 4.1.4. Identity 320 An identity is a (possibly pseudonymous) representation of a user 321 encapsulating how this user appears in the network. 323 An identity is defined by the mapping of user_id to address. If no 324 user_id is known, it is guessed by mapping of username and address. 326 An identity can have a temporary user_id as a placeholder until a 327 real user_id is known. 329 An identity can have a default key. 331 [[ Note: This is the reason why in current pEp implementations for 332 each email account a different key pair is created, which allows a 333 user to retain different identities. ]] 335 In Appendix A.1 you can find how a pEp identity is defined in the 336 reference implementation of the pEp Engine. 338 4.2. Example: Difference between pEp and OpenPGP 340 +--------------------+--------------+-------------------------------+ 341 | pEp | OpenPGP | Comments | 342 +--------------------+--------------+-------------------------------+ 343 | user_id | (no concept) | ID for a person, i.e. a | 344 | | | contact | 345 | | | | 346 | username + address | uid | comparable only for email | 347 | | | | 348 | fpr | fingerprint | used as key ID in pEp | 349 | | | | 350 | (no concept) | Key ID | does not exist in pEp | 351 +--------------------+--------------+-------------------------------+ 353 5. Key Management 355 In order to achieve the goal of widespread adoption of secure 356 communications, key management in pEp MUST be automatized 358 A pEp implementation MUST ensure cryptographic keys for end-to-end 359 cryptography are generated for every identity configured (or 360 instantly upon its configuration [[ TODO: unclear/rewrite/simplify 361 ]]), if no secure cryptographic setup can be found. Users SHALL NOT 362 be stopped from communicating - this also applies for initial 363 situations where cryptographic keys are not generated fast enough. 364 This process MUST be carried out in the background so the user is not 365 stopped from communicating. [[ TODO: rewrite/simplify ]] 367 pEp includes a Trust Rating system [E-D.birk-pep-trust-rating] 368 defining what kind of encryption is considered reliable and is thus 369 secure enough for usage in pEp implementations. This also applies 370 for keys already available for the given identity. If the available 371 keys are considered insecure (e.g, insufficient key length), pEp 372 implementers are REQUIRED to generate new keys for use with the 373 respective identity. 375 An example for the rating of communication types, the definition of 376 the data structure by the pEp Engine reference implementation is 377 provided in Appendix A.2. 379 5.1. Private Keys 381 Private keys in pEp implementations MUST always be held on the end 382 user's device(s): pEp implementers MUST NOT rely on private keys 383 stored in centralized remote locations. This applies even for key 384 storages where the private keys are protected with sufficiently long 385 passphrases. It MUST be considered a violation of pEp's P2P design 386 principle to rely on centralized infrastructures. This also applies 387 for pEp implementations created for applications not residing on a 388 user's device (e.g., web-based MUAs). In such cases, pEp 389 implementations MUST be done in a way the locally-held private key 390 can neither be directly accessed nor leaked to the outside world. 392 [[ Note: It is particularly important that browser add-ons 393 implementing pEp functionality do not obtain their cryptographic code 394 from a centralized (cloud) service, as this must be considered a 395 centralized attack vector allowing for backdoors, negatively 396 impacting privacy. ]] 398 A decentralized proposition - the pEp Key Synchronization protocol. 399 [E-D.birk-pep-keysync] - defines how pEp users can distribute their 400 private keys among different devices in a secure and trusted manner: 401 this allows Internet users to read their messages across their 402 different devices, when sharing a common address (e.g., the same 403 email account). 405 5.2. Public Key Distribution 407 Implementers of pEp are REQUIRED to ensure that the identity's public 408 key is attached to every outgoing message. However, this MAY be 409 omitted if the peer previously received a message encrypted with the 410 public key of the sender. 412 The sender's public key SHOULD be sent encrypted whenever possible, 413 i.e. when a public key of the receiving peer is available. If no 414 encryption key of the recipient is available, the sender's public key 415 MAY be sent unencrypted. In either case, this approach ensures that 416 messaging clients (e.g., MUAs that at least implement OpenPGP) do not 417 need to have pEp implemented to see a user's public key. Such peers 418 thus have the chance to (automatically) import the sender's public 419 key. 421 If there is already a known public key from the sender of a message 422 and it is still valid and not expired, new keys MUST not be used for 423 future communication, unless they are signed by the previous key (to 424 avoid a MITM attack). Messages MUST always be encrypted with the 425 receiving peer's oldest public key, as long as it is valid and not 426 expired. 428 Implementers of pEp SHALL prevent that public keys attached to 429 messages (e.g, in email) are displayed to the user, in order to avoid 430 users getting confused by a file they cannot potentially deal with. 432 Metadata (e.g., email headers) MUST NOT be added to announce a user's 433 public key. This is considered unnecessary information leakage as it 434 may affect users' privacy, which depends also on a country's data 435 retention laws. Furthermore, this affects interoperability to 436 existing users (e.g., in the OpenPGP field) that have no notion of 437 such header fields and thus lose the ability to import any such keys 438 distributed this way. It SHOULD, though, be supported to obtain 439 other users' public keys by extracting them from respective header 440 fields of received messages (in case such approaches get widespread). 442 Keyservers or generally intermediate approaches to obtain a peer's 443 public key SHALL NOT be used by default. On the other hand, the user 444 MAY be provided with the option to opt-in for remote locations to 445 obtain keys, considering the widespread adoption of such approaches 446 for key distribution. 448 Keys generated or obtained by pEp clients SHALL NOT be uploaded to 449 any (intermediate) keystore locations without the user's explicit 450 consent. 452 5.3. Passphrases 454 Passphrases to protect a user's private key MUST be supported by pEp 455 implementations, but SHALL NOT be enforced by default. That is, if a 456 pEp implementation finds a suitable (i.e., secure enough) 457 cryptographic setup, which uses passphrases, pEp implementations MUST 458 provide a way to unlock the key. However, if a new key pair is 459 generated for a given identity no passphrase SHALL be put in place. 460 The authors assume that the enforcement of secure (i.e., unique and 461 long enough) passphrases would massively reduce the number of pEp 462 users (by hassling them), while providing little to no additional 463 privacy for the common cases of passive monitoring being carried out 464 by corporations or state-level actors. 466 6. Privacy Status 468 For end-users, the most important component of pEp, which MUST be 469 made visible on a per-recipient and per-message level, is the Privacy 470 Status. 472 By colors, symbols and texts a user SHALL immediately understand how 473 private 475 o a communication channel with a given peer was or ought to be and 476 o a given message was or ought to be. 478 The Privacy Status in its most general form MUST be expressed with 479 traffic lights semantics (and respective symbols and texts), whereas 480 the three colors yellow, green and red can be applied for any peer or 481 message - like this immediately indicating how secure and trustworthy 482 (and thus private) a communication was or ought to be considered. In 483 cases no (special) Privacy Status can be inferred for peers or 484 messages, no color (or the gray color) MUST be shown and respective 485 texts - being "unknown" or "unreliable" - MUST be shown. 487 The detailed Privacy Status as an end-user element of the pEp Trust 488 Rating system with all its states and respective representations to 489 be followed is outlined in [E-D.birk-pep-trust-rating]. 491 7. Options in pEp 493 In this section a non-exhaustive selection of options is provided. 495 7.1. Option "Passive Mode" 497 By default the sender attaches its public key to any outgoing message 498 (cf. Section 5.2). For situations where a sender wants to ensure 499 that it only attaches a public key to an Internet user which has a 500 pEp implementation, a Passive Mode MUST be available. 502 7.2. Option "Disable Protection" 504 This option SHALL not affect the user's ability to decipher already 505 received or sent messages. [[ TODO: Public key added in these cases? 506 ]] 508 Protection can be disabled generally or selectively. 510 7.2.1. For all communications 512 Implementers of pEp MUST provide an option "Disable Protection" for 513 the user's choice to disable any outgoing encryption and signing. 515 7.2.2. For some communications 517 Implementers of pEp MUST provide an option to allow users to disable 518 protection (encryption and signing) for specific contacts or 519 messages. 521 7.3. Option "Extra Keys" 523 For internal environments there may be a need to centrally decrypt 524 persons' messages for archiving or other legal purposes (e.g., in the 525 contexts of public offices and enterprises) by authorized personnel. 526 Therefore, pEp implementers MAY provide an "Extra Keys" option where 527 a message gets encrypted with at least one additional public key. 528 The corresponding (shared) secret(s) to decrypt are intended to be 529 held - safely - by CISO staff and/or other authorized personnel for 530 such an organization. [[ TODO: Shared secret? no private key? ]] 532 The Extra Keys feature MUST NOT be activated by default for any 533 network address and is intended to be an option only for 534 organizational identities and their corresponding network addresses 535 and accounts - not for addresses used for private purposes. That is, 536 the Extra Keys feature is a feature which SHOULD NOT apply to all 537 identities a user might posses, even if activated. 539 7.4. Option "Blacklist Keys" 541 An option "Blacklist Keys" MUST be provided for an advanced user to 542 be able to disable keys which the user does not want to be used 543 anymore for any new communications. However, the keys SHALL NOT be 544 deleted. It MUST still be possible to verify and decipher past 545 communications. 547 7.5. Establishing trust between peers 549 In pEp, Trustwords [I-D.birk-pep-trustwords] are used for users to 550 compare the authenticity of peers in order to mitigate MITM attacks. 552 By default, Trustwords MUST be used to represent two peers' 553 fingerprints of their public keys in pEp implementations. 555 In order to retain compatibility with peers not using pEp 556 implementations (e.g., Mail User Agents (MUAs) with OpenPGP 557 implementations without Trustwords), it is REQUIRED that pEp 558 implementers give the user the choice to show both peers' 559 fingerprints instead of just their common Trustwords. 561 8. Security Considerations 563 By attaching the sender's public key to outgoing messages, Trust on 564 First Use (TOFU) is established. However, this is prone to MITM 565 attacks. Cryptographic key subversion is considered Pervasive 566 Monitoring (PM) according to [RFC7258]. Those attacks can be 567 mitigated, if the involved users compare their common Trustwords. 568 This possibility MUST be made easily accessible to pEp users in the 569 user interface implementation. If for compatibility reasons (e.g., 570 with OpenPGP users) no Trustwords can be used, then an comparatively 571 easy way to verify the respective public key fingerprints MUST be 572 implemented. 574 As the use of passphrases for private keys is not advised, devices 575 themselves SHOULD use encryption. 577 9. Implementation Status 579 9.1. Introduction 581 This section records the status of known implementations of the 582 protocol defined by this specification at the time of posting of this 583 Internet-Draft, and is based on a proposal described in [RFC7942]. 584 The description of implementations in this section is intended to 585 assist the IETF in its decision processes in progressing drafts to 586 RFCs. Please note that the listing of any individual implementation 587 here does not imply endorsement by the IETF. Furthermore, no effort 588 has been spent to verify the information presented here that was 589 supplied by IETF contributors. This is not intended as, and must not 590 be construed to be, a catalog of available implementations or their 591 features. Readers are advised to note that other implementations may 592 exist. 594 According to [RFC7942], "[...] this will allow reviewers and working 595 groups to assign due consideration to documents that have the benefit 596 of running code, which may serve as evidence of valuable 597 experimentation and feedback that have made the implemented protocols 598 more mature. It is up to the individual working groups to use this 599 information as they see fit." 601 9.2. Reference implementation of pEp's core 603 The pEp Foundation provides a reference implementation of pEp's core 604 principles and functionalities, which go beyond the documentation 605 status of this Internet-Draft. [SRC.pepcore] 607 pEp's reference implementation is composed of pEp Engine and pEp 608 Adapters (or bindings), alongside with some libraries which pEp 609 Engine relies on to function on certain platforms (like a NetPGP fork 610 we maintain for the iOS platform). 612 The pEp engine is a Free Software library encapsulating 613 implementations of: 615 o Key Management 616 Key Management in pEp engine is based on GnuPG key chains (NetPGP 617 on iOS). Keys are stored in an OpenPGP compatible format and can 618 be used for different crypto implementations. 620 o Trust Rating 622 pEp engine is sporting a two phase trust rating system. In phase 623 one there is a rating based on channel, crypto and key security 624 named "comm_types". In phase 2 these are mapped to user 625 representable values which have attached colors to present them in 626 traffic light semantics. 628 o Abstract Crypto API 630 The Abstract Crypto API is providing functions to encrypt and 631 decrypt data or full messages without requiring an application 632 programmer to understand the different formats and standards. 634 o Message Transports 636 pEp engine will support a growing list of Message Transports to 637 support any widespread text messaging system including email, SMS, 638 XMPP and many more. 640 pEp engine is written in C99 programming language. It is not meant 641 to be used in application code directly. Instead, pEp engine is 642 coming together with a list of software adapters for a variety of 643 programming languages and development environments, which are: 645 o pEp COM Server Adapter 647 o pEp JNI Adapter 649 o pEp JSON Adapter 651 o pEp ObjC (and Swift) Adapter 653 o pEp Python Adapter 655 o pEp Qt Adapter 657 9.3. Abstract Crypto API examples 659 A selection of code excerpts from the pEp Engine reference 660 implementation (encrypt message, decrypt message, and obtain 661 trustwords) can be found in Appendix A.3. 663 9.4. Current software implementing pEp 665 The following software implementing the pEp protocols (to varying 666 degrees) already exists; it does not yet go beyond implementing pEp 667 for email, which is described nearer in [E-D.birk-pep-email]: 669 o pEp for Outlook as add-on for Microsoft Outlook, release 670 [SRC.pepforoutlook] 672 o pEp for Android (based on a fork of the K9 MUA), release 673 [SRC.pepforandroid] 675 o Enigmail/pEp as add-on for Mozilla Thunderbird, release 676 [SRC.enigmailpep] 678 o pEp for iOS (implemented in a new MUA), beta [SRC.pepforios] 680 pEp for Android, iOS and Outlook are provided by pEp Security, a 681 commercial entity specializing in end-user software implementing pEp 682 while Enigmail/pEp is pursued as community project, supported by the 683 pEp Foundation. 685 10. Notes 687 The pEp logo and "pretty Easy privacy" are registered trademarks 688 owned by pEp Foundation in Switzerland, a tax-free, non-commercial 689 entity. 691 Primarily, we want to ensure the following: 693 o Software using the trademarks MUST be backdoor-free. 695 o Software using the trademarks MUST be accompanied by a serious 696 (detailed) code audit carried out by a reputable third-party, for 697 any proper release. 699 The pEp Foundation will help to support any community-run (non- 700 commercial) project with the latter, be it organizationally or 701 financially. 703 Through this, the foundation wants to make sure that software using 704 the pEp trademarks is as safe as possible from a security and privacy 705 point of view. 707 11. Acknowledgments 709 The authors would like to thank the following people who have 710 provided feedback or significant contributions to the development of 711 this document: Bernie Hoeneisen, Brian Trammell, Enrico Tomae, Eric 712 Rescorla Neal Walfield, and Stephen Farrel. 714 [[ TODO: Add those who commented on mailing list (on this draft) as 715 well as those who provided feedback in person or during BarBoFs. ]] 717 This work was initially created by pEp Foundation, and then reviewed 718 and extended with funding by the Internet Society's Beyond the Net 719 Programme on standardizing pEp. [ISOC.bnet] 721 12. References 723 12.1. Normative References 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, 727 DOI 10.17487/RFC2119, March 1997, 728 . 730 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 731 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 732 . 734 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 735 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 736 December 2014, . 738 12.2. Informative References 740 [E-D.birk-pep-email] 741 Birk, V. and H. Marques, "pretty Easy privacy (pEp): 742 Secure and Trusted Email Communication", June 2018, 743 . 746 Early draft 748 [E-D.birk-pep-handshake] 749 Marques, H., "pretty Easy privacy (pEp): Contact 750 Authentication through Handshake", June 2018, 751 . 755 Early draft 757 [E-D.birk-pep-keysync] 758 Birk, V. and H. Marques, "pretty Easy privacy (pEp): Key 759 Synchronization Protocol", June 2018, 760 . 764 Early draft 766 [E-D.birk-pep-trust-rating] 767 Birk, V. and H. Marques, "pretty Easy privacy (pEp): Trust 768 Rating System", June 2018, 769 . 772 Early draft 774 [I-D.birk-pep-trustwords] 775 Birk, V., Marques, H., and B. Hoeneisen, "IANA 776 Registration of Trustword Lists: Guide, Template and IANA 777 Considerations", draft-birk-pep-trustwords-02 (work in 778 progress), June 2018. 780 [ISOC.bnet] 781 Simao, I., "Beyond the Net. 12 Innovative Projects 782 Selected for Beyond the Net Funding. Implementing Privacy 783 via Mass Encryption: Standardizing pretty Easy privacy's 784 protocols", June 2017, . 788 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 789 Thayer, "OpenPGP Message Format", RFC 4880, 790 DOI 10.17487/RFC4880, November 2007, 791 . 793 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 794 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 795 2014, . 797 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 798 Code: The Implementation Status Section", BCP 205, 799 RFC 7942, DOI 10.17487/RFC7942, July 2016, 800 . 802 [SRC.enigmailpep] 803 "Source code for Enigmail/pEp", June 2018, 804 . 806 [SRC.pepcore] 807 "Core source code and reference implementation of pEp 808 (engine and adapters)", June 2018, 809 . 811 [SRC.pepforandroid] 812 "Source code for pEp for Android", June 2018, 813 . 815 [SRC.pepforios] 816 "Source code for pEp for iOS", June 2018, 817 . 819 [SRC.pepforoutlook] 820 "Source code for pEp for Outlook", June 2018, 821 . 823 Appendix A. Excerpts from the pEp Reference Implementation 825 This section provides excerpts of the running code from the pEp 826 reference implementation pEp engine (C99 programming language). [[ 827 TODO: Maybe rewrite sentence a bit ]] 829 A.1. pEp Identity 831 How the pEp identity is defined in the data structure (cf. src/ 832 pEpEngine.h): 834 typedef struct _pEp_identity { 835 char *address; // C string with address UTF-8 encoded 836 char *fpr; // C string with fingerprint UTF-8 837 // encoded 838 char *user_id; // C string with user ID UTF-8 encoded 839 char *username; // C string with user name UTF-8 840 // encoded 841 PEP_comm_type comm_type; // type of communication with this ID 842 char lang[3]; // language of conversation 843 // ISO 639-1 ALPHA-2, last byte is 0 844 bool me; // if this is the local user 845 // herself/himself 846 identity_flags_t flags; // identity_flag1 | identity_flag2 847 // | ... 848 } pEp_identity; 850 A.1.1. Corresponding SQL 852 Relational table scheme excerpts (in SQL) used in current pEp 853 implementations, held locally for every pEp installation in a SQLite 854 database: 856 CREATE TABLE person ( 857 id text primary key, 858 username text not null, 859 main_key_id text 860 references pgp_keypair (fpr) 861 on delete set null, 862 lang text, 863 comment text, 864 device_group text, 865 is_pep_user integer default 0 866 ); 868 CREATE TABLE identity ( 869 address text, 870 user_id text 871 references person (id) 872 on delete cascade on update cascade, 873 main_key_id text 874 references pgp_keypair (fpr) 875 on delete set null, 876 comment text, 877 flags integer default 0, 878 is_own integer default 0, 879 timestamp integer default (datetime('now')), 880 primary key (address, user_id) 881 ); 883 CREATE TABLE pgp_keypair ( 884 fpr text primary key, 885 created integer, 886 expires integer, 887 comment text, 888 flags integer default 0 889 ); 890 CREATE INDEX pgp_keypair_expires on pgp_keypair ( 891 expires 892 ); 894 A.2. pEp Communication Type 896 In the following, an example for the rating of communication types, 897 the definition of the data structure (cf. src/pEpEngine.h 898 [SRC.pepcore]): 900 typedef enum _PEP_comm_type { 901 PEP_ct_unknown = 0, 903 // range 0x01 to 0x09: no encryption, 0x0a to 0x0e: 904 // nothing reasonable 906 PEP_ct_no_encryption = 0x01, // generic 907 PEP_ct_no_encrypted_channel = 0x02, 908 PEP_ct_key_not_found = 0x03, 909 PEP_ct_key_expired = 0x04, 910 PEP_ct_key_revoked = 0x05, 911 PEP_ct_key_b0rken = 0x06, 912 PEP_ct_my_key_not_included = 0x09, 914 PEP_ct_security_by_obscurity = 0x0a, 915 PEP_ct_b0rken_crypto = 0x0b, 916 PEP_ct_key_too_short = 0x0c, 918 PEP_ct_compromized = 0x0e, // known compromized connection 919 PEP_ct_mistrusted = 0x0f, // known mistrusted key 921 // range 0x10 to 0x3f: unconfirmed encryption 923 PEP_ct_unconfirmed_encryption = 0x10, // generic 924 PEP_ct_OpenPGP_weak_unconfirmed = 0x11, // RSA 1024 is weak 926 PEP_ct_to_be_checked = 0x20, // generic 927 PEP_ct_SMIME_unconfirmed = 0x21, 928 PEP_ct_CMS_unconfirmed = 0x22, 930 PEP_ct_strong_but_unconfirmed = 0x30, // generic 931 PEP_ct_OpenPGP_unconfirmed = 0x38, // key at least 2048 bit 932 // RSA or EC 933 PEP_ct_OTR_unconfirmed = 0x3a, 935 // range 0x40 to 0x7f: unconfirmed encryption and anonymization 937 PEP_ct_unconfirmed_enc_anon = 0x40, // generic 938 PEP_ct_pEp_unconfirmed = 0x7f, 940 PEP_ct_confirmed = 0x80, // this bit decides if trust 941 // is confirmed 943 // range 0x81 to 0x8f: reserved 944 // range 0x90 to 0xbf: confirmed encryption 946 PEP_ct_confirmed_encryption = 0x90, // generic 947 PEP_ct_OpenPGP_weak = 0x91, // RSA 1024 is weak (unused) 949 PEP_ct_to_be_checked_confirmed = 0xa0, //generic 950 PEP_ct_SMIME = 0xa1, 951 PEP_ct_CMS = 0xa2, 953 PEP_ct_strong_encryption = 0xb0, // generic 954 PEP_ct_OpenPGP = 0xb8, // key at least 2048 bit RSA or EC 955 PEP_ct_OTR = 0xba, 957 // range 0xc0 to 0xff: confirmed encryption and anonymization 959 PEP_ct_confirmed_enc_anon = 0xc0, // generic 960 PEP_ct_pEp = 0xff 961 } PEP_comm_type; 963 A.3. Abstract Crypto API examples 965 The following code excerpts are from the pEp Engine reference 966 implementation, to be found in src/message_api.h. 968 [[ Note: Just a selection; more functionality is available. ]] 970 A.3.1. Encrypting a Message 972 Cf. src/message_api.h [SRC.pepcore]: 974 // encrypt_message() - encrypt message in memory 975 // 976 // parameters: 977 // session (in) session handle 978 // src (in) message to encrypt 979 // extra (in) extra keys for encryption 980 // dst (out) pointer to new encrypted message or NULL if no 981 // encryption could take place 982 // enc_format (in) encrypted format 983 // flags (in) flags to set special encryption features 984 // 985 // return value: 986 // PEP_STATUS_OK on success 987 // PEP_KEY_HAS_AMBIG_NAME at least one of the recipient 988 // keys has an ambiguous name 989 // PEP_UNENCRYPTED no recipients with usable key, 990 // message is left unencrypted, 991 // and key is attached to it 992 // 993 // caveat: 994 // the ownership of src remains with the caller 995 // the ownership of dst goes to the caller 996 DYNAMIC_API PEP_STATUS encrypt_message( 997 PEP_SESSION session, 998 message *src, 999 stringlist_t *extra, 1000 message **dst, 1001 PEP_enc_format enc_format, 1002 PEP_encrypt_flags_t flags 1003 ); 1005 Cf. src/message_api.h [SRC.pepcore]: 1007 A.3.2. Decrypting a Message 1009 Cf. src/message_api.h [SRC.pepcore]: 1011 // decrypt_message() - decrypt message in memory 1012 // 1013 // parameters: 1014 // session (in) session handle 1015 // src (in) message to decrypt 1016 // dst (out) pointer to new decrypted message 1017 // or NULL on failure 1018 // keylist (out) stringlist with keyids 1019 // rating (out) rating for the message 1020 // flags (out) flags to signal special decryption features 1021 // 1022 // return value: 1023 // error status 1024 // or PEP_DECRYPTED if message decrypted but not verified 1025 // or PEP_CANNOT_REENCRYPT if message was decrypted (and possibly 1026 // verified) but a reencryption operation is expected by the 1027 // caller and failed 1028 // or PEP_STATUS_OK on success 1029 // 1030 // flag values: 1031 // in: 1032 // PEP_decrypt_flag_untrusted_server 1033 // used to signal that decrypt function should engage in 1034 // behaviour specified for when the server storing the 1035 // source is untrusted 1036 // out: 1037 // PEP_decrypt_flag_own_private_key 1038 // private key was imported for one of our addresses (NOT 1039 // trusted or set to be used - handshake/trust is required 1040 // for that) 1041 // PEP_decrypt_flag_src_modified 1042 // indicates that the src object has been modified. At the 1043 // moment, this is always as a direct result of the 1044 // behaviour driven by the input flags. This flag is the 1045 // ONLY value that should be relied upon to see if such 1046 // changes have taken place. 1047 // PEP_decrypt_flag_consume 1048 // used by sync 1049 // PEP_decrypt_flag_ignore 1050 // used by sync 1051 // 1052 // 1053 // caveat: 1054 // the ownership of src remains with the caller - however, the 1055 // contents might be modified (strings freed and allocated anew 1056 // or set to NULL, etc) intentionally; when this happens, 1057 // PEP_decrypt_flag_src_modified is set. 1058 // the ownership of dst goes to the caller 1059 // the ownership of keylist goes to the caller 1060 // if src is unencrypted this function returns PEP_UNENCRYPTED and 1061 // sets 1062 // dst to NULL 1063 DYNAMIC_API PEP_STATUS decrypt_message( 1064 PEP_SESSION session, 1065 message *src, 1066 message **dst, 1067 stringlist_t **keylist, 1068 PEP_rating *rating, 1069 PEP_decrypt_flags_t *flags 1071 ); 1073 A.3.3. Obtain Common Trustwords 1075 Cf. src/message_api.h [SRC.pepcore]: 1077 // get_trustwords() - get full trustwords string 1078 // for a *pair* of identities 1079 // 1080 // parameters: 1081 // session (in) session handle 1082 // id1 (in) identity of first party in communication 1083 // - fpr can't be NULL 1084 // id2 (in) identity of second party in communication 1085 // - fpr can't be NULL 1086 // lang (in) C string with ISO 639-1 language code 1087 // words (out) pointer to C string with all trustwords 1088 // UTF-8 encoded, separated by a blank each 1089 // NULL if language is not supported or 1090 // trustword wordlist is damaged or unavailable 1091 // wsize (out) length of full trustwords string 1092 // full (in) if true, generate ALL trustwords for these 1093 // identities. 1094 // else, generate a fixed-size subset. 1095 // (TODO: fixed-minimum-entropy subset 1096 // in next version) 1097 // 1098 // return value: 1099 // PEP_STATUS_OK trustwords retrieved 1100 // PEP_OUT_OF_MEMORY out of memory 1101 // PEP_TRUSTWORD_NOT_FOUND at least one trustword not found 1102 // 1103 // caveat: 1104 // the word pointer goes to the ownership of the caller 1105 // the caller is responsible to free() it 1106 // (on Windoze use pEp_free()) 1107 // 1108 DYNAMIC_API PEP_STATUS get_trustwords( 1109 PEP_SESSION session, const pEp_identity* id1, 1110 const pEp_identity* id2, const char* lang, 1111 char **words, size_t *wsize, bool full 1112 ); 1114 Appendix B. Document Changelog 1116 [[ RFC Editor: This section is to be removed before publication ]] 1118 o draft-birk-pep-02: 1120 * Move (updated) code to Appendix 1122 * Add Changelog to Appendix 1124 * Add Open Issue section to Appendix 1126 * Fix description of what Extra Keys are 1128 * Fix Passive Mode description 1130 * Better explain pEp's identity system 1132 o draft-birk-pep-01: 1134 * Mostly editorial 1136 o draft-birk-pep-00: 1138 * Initial version 1140 Appendix C. Open Issues 1142 [[ RFC Editor: This section should be empty and is to be removed 1143 before publication ]] 1145 o Better explain Passive Mode 1147 o Better explain / illustrate pEp's identity system 1149 o Explain Key Mapping 1151 Authors' Addresses 1153 Volker Birk 1154 pEp Foundation 1155 Oberer Graben 4 1156 CH-8400 Winterthur 1157 Switzerland 1159 Email: volker.birk@pep.foundation 1160 URI: https://pep.foundation/ 1161 Hernani Marques 1162 pEp Foundation 1163 Oberer Graben 4 1164 CH-8400 Winterthur 1165 Switzerland 1167 Email: hernani.marques@pep.foundation 1168 URI: https://pep.foundation/ 1170 Shelburn 1171 pEp Foundation 1172 Oberer Graben 4 1173 CH-8400 Winterthur 1174 Switzerland 1176 Email: shelburn@pep.foundation 1177 URI: https://pep.foundation/