idnits 2.17.1 draft-ietf-lamps-e2e-mail-guidance-00.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: ---------------------------------------------------------------------------- == There are 67 instances of lines with non-ascii characters in the document. 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 'SHOULD not' in this paragraph: Aside from this cryptographic summary, the message itself should be rendered as though the Cryptographic Payload is the body of the message. The Cryptographic Layers themselves SHOULD not be rendered otherwise. -- The document date (26 July 2021) is 997 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lamps D.K. Gillmor, Ed. 3 Internet-Draft ACLU 4 Intended status: Informational 26 July 2021 5 Expires: 27 January 2022 7 Guidance on End-to-End E-mail Security 8 draft-ietf-lamps-e2e-mail-guidance-00 10 Abstract 12 End-to-end cryptographic protections for e-mail messages can provide 13 useful security. However, the standards for providing cryptographic 14 protection are extremely flexible. That flexibility can trap users 15 and cause surprising failures. This document offers guidance for 16 mail user agent implementers that need to compose or interpret e-mail 17 messages with end-to-end cryptographic protection. It provides a 18 useful set of vocabulary as well as suggestions to avoid common 19 failures. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 27 January 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2.1. Structural Headers . . . . . . . . . . . . . . . . . 4 58 2. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.2. E-mail Users Want a Familiar Experience . . . . . . . . . 5 61 2.3. Warning About Failure vs. Announcing Success . . . . . . 6 62 3. Types of Protection . . . . . . . . . . . . . . . . . . . . . 7 63 4. Cryptographic MIME Message Structure . . . . . . . . . . . . 7 64 4.1. Cryptographic Layers . . . . . . . . . . . . . . . . . . 7 65 4.1.1. S/MIME Cryptographic Layers . . . . . . . . . . . . . 8 66 4.1.2. PGP/MIME Cryptographic Layers . . . . . . . . . . . . 9 67 4.2. Cryptographic Envelope . . . . . . . . . . . . . . . . . 9 68 4.3. Cryptographic Payload . . . . . . . . . . . . . . . . . . 10 69 4.4. Types of Cryptographic Envelope . . . . . . . . . . . . . 10 70 4.4.1. Simple Cryptographic Envelopes . . . . . . . . . . . 10 71 4.4.2. Multilayer Cryptographic Envelopes . . . . . . . . . 10 72 4.5. Errant Crytptographic Layers . . . . . . . . . . . . . . 11 73 4.5.1. Mailing List Wrapping . . . . . . . . . . . . . . . . 11 74 4.5.2. A Baroque Example . . . . . . . . . . . . . . . . . . 11 75 5. Message Composition . . . . . . . . . . . . . . . . . . . . . 12 76 5.1. Message Composition Algorithm . . . . . . . . . . . . . . 12 77 5.2. Encryption Outside, Signature Inside . . . . . . . . . . 13 78 5.3. Avoid Offering Encrypted-only Messages . . . . . . . . . 13 79 5.4. Composing a Reply Message . . . . . . . . . . . . . . . . 14 80 6. Message Interpretation . . . . . . . . . . . . . . . . . . . 15 81 6.1. Rendering Well-formed Messages . . . . . . . . . . . . . 15 82 6.2. Errant Cryptographic Layers . . . . . . . . . . . . . . . 15 83 6.2.1. Errant Signing Layer . . . . . . . . . . . . . . . . 15 84 6.2.2. Errant Encryption Layer . . . . . . . . . . . . . . . 17 85 6.3. Forwarded Messages with Cryptographic Protection . . . . 18 86 6.4. Signature failures . . . . . . . . . . . . . . . . . . . 18 87 7. Certificate Management . . . . . . . . . . . . . . . . . . . 19 88 7.1. Peer Certificates . . . . . . . . . . . . . . . . . . . . 19 89 7.1.1. Cert Discovery from Incoming Messages . . . . . . . . 19 90 7.1.2. Certificate Directories . . . . . . . . . . . . . . . 20 91 7.1.3. Peer Certificate Selection . . . . . . . . . . . . . 20 92 7.1.4. Checking for Revocation . . . . . . . . . . . . . . . 20 93 7.2. Local Certificates . . . . . . . . . . . . . . . . . . . 21 94 7.2.1. Getting a Certificate for the User . . . . . . . . . 21 95 7.2.2. Local Certificate Maintenance . . . . . . . . . . . . 21 96 7.2.3. Shipping Certificates in Outbound Messages . . . . . 22 97 7.3. Certificate Authorities . . . . . . . . . . . . . . . . . 22 98 8. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 22 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 100 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 101 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 103 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 104 12.2. Informative References . . . . . . . . . . . . . . . . . 24 105 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 25 106 Appendix B. Document Considerations . . . . . . . . . . . . . . 25 107 B.1. Document History . . . . . . . . . . . . . . . . . . . . 25 108 B.1.1. Substantive changes from draft-dkg-...-01 to 109 draft-ietf-...-00 . . . . . . . . . . . . . . . . . . 25 110 B.1.2. Substantive changes from draft-dkg-...-00 to 111 draft-dkg-...-01 . . . . . . . . . . . . . . . . . . 25 112 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 114 1. Introduction 116 E-mail end-to-end security using S/MIME ([RFC8551]) and PGP/MIME 117 ([RFC3156]) cryptographic standards can provide integrity, 118 authentication and confidentiality to MIME ([RFC4289]) e-mail 119 messages. 121 However, there are many ways that a receiving mail user agent can 122 misinterpret or accidentally break these security guarantees (e.g., 123 [EFAIL]). 125 A mail user agent that interprets a message with end-to-end 126 cryptographic protections needs to do so defensively, staying alert 127 to different ways that these protections can be bypassed by mangling 128 (either malicious or accidental) or a failed user experience. 130 A mail user agent that generates a message with end-to-end 131 cryptographic protections should be aware of these defensive 132 interpretation strategies, and should compose any new outbound 133 message conservatively if they want the protections to remain intact. 135 1.1. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 ([RFC2119] and [RFC8174]) when, and only when, they appear in all 141 capitals, as shown here. 143 1.2. Terminology 145 For the purposes of this document, we define the following concepts: 147 * _MUA_ is short for Mail User Agent; an e-mail client. 149 * _Protection_ of message data refers to cryptographic encryption 150 and/or signatures, providing confidentiality, authenticity, and/or 151 integrity. 153 * _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic 154 Payload_, and _Errant Cryptographic Layer_ are defined in 155 Section 4 157 * A _well-formed_ e-mail message with cryptographic protection has 158 both a _Cryptographic Envelope_ and a _Cryptographic Payload_. 160 * _Structural Headers_ are documented in Section 1.2.1. 162 1.2.1. Structural Headers 164 A message header whose name begins with "Content-" is referred to in 165 this document as a "structural" header. 167 These headers indicate something about the specific MIME part they 168 are attached to, and cannot be transferred or copied to other parts 169 without endangering the readability of the message. 171 This includes (but is not limited to): 173 * "Content-Type" 175 * "Content-Transfer-Encoding" 177 * "Content-Disposition" 179 FIXME: are there any non-"Content-*" headers we should consider as 180 structural? 182 2. Usability 184 Any MUA that enables its user to transition from unprotected messages 185 to messages with end-to-end cryptographic protection needs to 186 consider how the user understands this transition. That said, the 187 primary goal of the user of an MUA is communication -- so interface 188 elements that get in the way of communication should be avoided where 189 possible. 191 Furthermore, it is likely is that the user will continue to encounter 192 unprotected messages, and may need to send unprotected messages (for 193 example, if a given recipient cannot handle cryptographic 194 protections). This means that the MUA needs to provide the user with 195 some guidance, so that they understand what protections any given 196 message or conversation has. But the user should not be overwhelmed 197 with choices or presented with unactionable information. 199 2.1. Simplicity 201 The end user (the operator of the MUA) is unlikely to understand 202 complex end-to-end cryptographic protections on any e-mail message, 203 so keep it simple. 205 For clarity to the user, any cryptographic protections should apply 206 to the message as a whole, not just to some subparts. 208 This is true for message composition: the standard message 209 composition user interface of an MUA should offer minimal controls 210 which indicate which types of protection to apply to the new message 211 as a whole. 213 This is also true for message interpretation: the standard message 214 rendering user interface of an MUA should offer a minimal, clear 215 indicator about the end-to-end cryptographic status of the message as 216 a whole. 218 2.2. E-mail Users Want a Familiar Experience 220 A person communicating over the Internet today often has many options 221 for reaching their desired correspondent, including web-based 222 bulletin boards, contact forms, and instant messaging services. 224 E-mail offers a few distinctions from these other systems, most 225 notably features like: 227 * Ubiquity: Most correspondents will have an e-mail address, while 228 not everyone is present on every alternate messaging service, 230 * Federation: interaction between users on distinct domains who have 231 not agreed on a common communications provider is still possible, 232 and 234 * User Control: the user can interact with the e-mail system using a 235 MUA of their choosing, including automation and other control over 236 their preferred and/or customized workflow. 238 Other systems (like some popular instant messaging applications, such 239 as WhatsApp and Signal Private Messenger) offer built-in end-to-end 240 cryptographic protections by default, which are simpler for the user 241 to understand. ("All the messages I see on Signal are confidential 242 and integrity-protected" is a clean user story) 244 A user of e-mail is likely using e-mail instead of other systems 245 because of the distinctions outlined above. When adding end-to-end 246 cryptographic protection to an e-mail endpoint, care should be taken 247 not to negate any of the distinct features of e-mail as a whole. If 248 these features are violated to provide end-to-end crypto, the user 249 may just as well choose one of the other systems that don't have the 250 drawbacks that e-mail has. Implmenters should try to provide end-to- 251 end protections that retain the familiar experience of e-mail itself. 253 Furthermore, an e-mail user is likely to regularly interact with 254 other e-mail correspondents who _cannot_ handle or produce end-to-end 255 cryptographic protections. Care should be taken that enabling 256 cryptography in a MUA does not inadvertently limit the ability of the 257 user to interact with legacy correspondents. 259 2.3. Warning About Failure vs. Announcing Success 261 Moving the web from http to https offers useful historical 262 similarities to adding end-to-end encryption to e-mail. 264 In particular, the indicators of what is "secure" vs. "insecure" for 265 web browsers have changed over time. For example, years ago the 266 default experience was http, and https sites were flagged with 267 "secure" indicators like a lock icon. In 2018, some browsers 268 reversed that process by downplaying https, and instead visibly 269 marking http as "not secure" (see [chrome-indicators]). 271 By analogy, when the user of a MUA first enables end-to-end 272 cryptographic protection, it's likely that they will want to see 273 which messages _have_ protection. But a user whose e-mail 274 communications are entirely end-to-end protected might instead want 275 to know which messages do _not_ have the expected protections. 277 Note also that some messages are expected to be confidential, but 278 other messages are expected to be public -- the types of protection 279 (see Section 3) that apply to each particular message will be 280 different. And the types of protection that are _expected_ to be 281 present in any context might differ (for example, by sender, by 282 thread, or by date). 284 It is out of scope for this document to define expectations about 285 protections for any given message, but an implementer who cares about 286 usable experience should be deliberate and judicious about the 287 expectations their interface assumes that the user has in a given 288 context. 290 3. Types of Protection 292 A given message might be: 294 * signed, 296 * encrypted, 298 * both signed and encrypted, or 300 * none of the above. 302 Given that many e-mail messages offer no cryptographic protections, 303 the user needs to be able to detect which protections are present for 304 any given message. 306 4. Cryptographic MIME Message Structure 308 Implementations use the structure of an e-mail message to protect the 309 headers. This section establishes some conventions about how to 310 think about message structure. 312 4.1. Cryptographic Layers 314 "Cryptographic Layer" refers to a MIME substructure that supplies 315 some cryptographic protections to an internal MIME subtree. The 316 internal subtree is known as the "protected part" though of course it 317 may itself be a multipart object. 319 In the diagrams below, "↧" (DOWNWARDS ARROW FROM BAR, U+21A7) 320 indicates "decrypts to", and "⇩" (DOWNWARDS WHITE ARROW, U+21E9) 321 indicates "unwraps to". 323 4.1.1. S/MIME Cryptographic Layers 325 For S/MIME [RFC8551], there are four forms of Cryptographic Layers: 326 multipart/signed, PKCS#7 signed-data, PKCS7 enveloped-data, PKCS7 327 authEnveloped-data. 329 4.1.1.1. S/MIME Multipart Signed Cryptographic Layer 331 └┬╴multipart/signed; protocol="application/pkcs7-signature" 332 ├─╴[protected part] 333 └─╴application/pkcs7-signature 335 This MIME layer offers authentication and integrity. 337 4.1.1.2. S/MIME PKCS7 signed-data Cryptographic Layer 339 └─╴application/pkcs7-mime; smime-type="signed-data" 340 ⇩ (unwraps to) 341 └─╴[protected part] 343 This MIME layer offers authentication and integrity. 345 4.1.1.3. S/MIME PKCS7 enveloped-data Cryptographic Layer 347 └─╴application/pkcs7-mime; smime-type="enveloped-data" 348 ↧ (decrypts to) 349 └─╴[protected part] 351 This MIME layer offers confidentiality. 353 4.1.1.4. S/MIME PKCS7 authEnveloped-data Cryptographic Layer 355 └─╴application/pkcs7-mime; smime-type="authEnveloped-data" 356 ↧ (decrypts to) 357 └─╴[protected part] 359 This MIME layer offers confidentiality and integrity. 361 Note that "enveloped-data" (Section 4.1.1.3) and "authEnveloped-data" 362 (Section 4.1.1.4) have identical message structure and semantics. 363 The only difference between the two is ciphertext malleability. 365 The examples in this document only include "enveloped-data", but the 366 implications for that layer apply to "authEnveloped-data" as well. 368 4.1.1.5. PKCS7 Compression is NOT a Cryptographic Layer 370 The Cryptographic Message Syntax (CMS) provides a MIME compression 371 layer ("smime-type="compressed-data""), as defined in [RFC3274]. 372 While the compression layer is technically a part of CMS, it is not 373 considered a Cryptographic Layer for the purposes of this document. 375 4.1.2. PGP/MIME Cryptographic Layers 377 For PGP/MIME [RFC3156] there are two forms of Cryptographic Layers, 378 signing and encryption. 380 4.1.2.1. PGP/MIME Signing Cryptographic Layer (multipart/signed) 382 └┬╴multipart/signed; protocol="application/pgp-signature" 383 ├─╴[protected part] 384 └─╴application/pgp-signature 386 This MIME layer offers authenticity and integrity. 388 4.1.2.2. PGP/MIME Encryption Cryptographic Layer (multipart/encrypted) 390 └┬╴multipart/encrypted 391 ├─╴application/pgp-encrypted 392 └─╴application/octet-stream 393 ↧ (decrypts to) 394 └─╴[protected part] 396 This MIME layer can offer any of: 398 * confidentiality (via a Symmetrically Encrypted Data Packet, see 399 Section 5.7 of [RFC4880]; a MUA MUST NOT generate this form due to 400 ciphertext malleability) 402 * confidentiality and integrity (via a Symmetrically Encrypted 403 Integrity Protected Data Packet (SEIPD), see section 5.13 of 404 [RFC4880]), or 406 * confidentiality, integrity, and authenticity all together (by 407 including an OpenPGP Signature Packet within the SEIPD). 409 4.2. Cryptographic Envelope 411 The Cryptographic Envelope is the largest contiguous set of 412 Cryptographic Layers of an e-mail message starting with the outermost 413 MIME type (that is, with the Content-Type of the message itself). 415 If the Content-Type of the message itself is not a Cryptographic 416 Layer, then the message has no cryptographic envelope. 418 "Contiguous" in the definition above indicates that if a 419 Cryptographic Layer is the protected part of another Cryptographic 420 Layer, the layers together comprise a single Cryptographic Envelope. 422 Note that if a non-Cryptographic Layer intervenes, all Cryptographic 423 Layers within the non-Cryptographic Layer _are not_ part of the 424 Cryptographic Envelope. They are Errant Cryptographic Layers (see 425 Section 4.5). 427 Note also that the ordering of the Cryptographic Layers implies 428 different cryptographic properties. A signed-then-encrypted message 429 is different than an encrypted-then-signed message. See Section 5.2. 431 4.3. Cryptographic Payload 433 The Cryptographic Payload of a message is the first non-Cryptographic 434 Layer -- the "protected part" -- within the Cryptographic Envelope. 436 4.4. Types of Cryptographic Envelope 438 4.4.1. Simple Cryptographic Envelopes 440 As described above, if the "protected part" identified in the sction 441 above is not itself a Cryptographic Layer, that part _is_ the 442 Cryptographic Payload. 444 If the application wants to generate a message that is both encrypted 445 and signed, it MAY use the simple MIME structure from Section 4.1.2.2 446 by ensuring that the [RFC4880] Encrypted Message within the 447 "application/octet-stream" part contains an [RFC4880] Signed Message 448 (the final option described in Section 4.1.2.2. 450 4.4.2. Multilayer Cryptographic Envelopes 452 It is possible to construct a Cryptographic Envelope consisting of 453 multiple layers with either S/MIME or PGP/MIME , for example using 454 the following structure: 456 A └─╴application/pkcs7-mime; smime-type="enveloped-data" 457 B ↧ (decrypts to) 458 C └─╴application/pkcs7-mime; smime-type="signed-data" 459 D ⇩ (unwraps to) 460 E └─╴[protected part] 461 When handling such a message, the properties of the Cryptographic 462 Envelope are derived from the series "A", "C". 464 As noted in Section 4.4.1, PGP/MIME applications also have a simpler 465 MIME construction available with the same cryptographic properties. 467 4.5. Errant Crytptographic Layers 469 Due to confusion, malice, or well-intentioned tampering, a message 470 may contain a Cryptographic Layer that is not part of the 471 Cryptographic Envelope. Such a layer is an Errant Cryptographic 472 Layer. 474 An Errant Cryptographic Layer SHOULD NOT contribute to the message's 475 overall cryptographic state. 477 Guidance for dealing with Errant Cryptographic Layers can be found in 478 Section 6.2. 480 4.5.1. Mailing List Wrapping 482 Some mailing list software will re-wrap a well-formed signed message 483 before re-sending to add a footer, resulting in the following 484 structure seen by recipients of the e-mail: 486 H └┬╴multipart/mixed 487 I ├┬╴multipart/signed 488 J │├─╴text/plain 489 K │└─╴application/pgp-signature 490 L └─╴text/plain 492 In this message, "L" is the footer added by the mailing list. "I" is 493 now an Errant Cryptographic Layer. 495 Note that this message has no Cryptographic Envelope at all. 497 It is NOT RECOMMENDED to produce e-mail messages with this structure, 498 because the data in part "L" may appear to the user as though it were 499 part of "J", though they have different cryptographic properties. In 500 particular, if the user believes that the message is signed, but 501 cannot distinguish "L" from "J" then the author of "L" can 502 effectively tamper with content of the signed message, breaking the 503 user's expectation of integrity and authenticity. 505 4.5.2. A Baroque Example 507 Consider a message with the following overcomplicated structure: 509 M └┬╴multipart/encrypted 510 N ├─╴application/pgp-encrypted 511 O └─╴application/octet-stream 512 P ↧ (decrypts to) 513 Q └┬╴multipart/signed 514 R ├┬╴multipart/mixed 515 S │├┬╴multipart/signed 516 T ││├─╴text/plain 517 U ││└─╴application/pgp-signature 518 V │└─╴text/plain 519 W └─╴application/pgp-signature 521 The 3 Cryptographic Layers in such a message are rooted in parts "M", 522 "Q", and "S". But the Cryptographic Envelope of the message consists 523 only of the properties derived from the series "M", "Q". The 524 Cryptographic Payload of the message is part "R". Part "S" is an 525 Errant Cryptographic Layer. 527 Note that this message has both a Cryptographic Envelope _and_ an 528 Errant Cryptographic Layer. 530 It is NOT RECOMMENDED to generate messages with such complicated 531 structures. Even if a receiving MUA can parse this structure 532 properly, it is nearly impossible to render in a way that the user 533 can reason about the cryptographic properties of part "T" compared to 534 part "V". 536 5. Message Composition 538 This section describes the ideal composition of an e-mail message 539 with end-to-end cryptographic protection. A message composed with 540 this form is most likely to achieve its end-to-end security goals. 542 5.1. Message Composition Algorithm 544 This section roughly describes the steps that a MUA should use to 545 compose a cryptographically-protected message that has a proper 546 cryptographic envelope and payload. 548 The message composition algorithm takes three parameters: 550 * "origbody": the traditional unprotected message body as a well- 551 formed MIME tree (possibly just a single MIME leaf part). As a 552 well-formed MIME tree, "origbody" already has structural headers 553 present (see Section 1.2.1). 555 * "origheaders": the intended non-structural headers for the 556 message, represented here as a list of "(h,v)" pairs, where "h" is 557 a header field name and "v" is the associated value. 559 * "crypto": The series of cryptographic protections to apply (for 560 example, "sign with the secret key corresponding to X.509 561 certificate X, then encrypt to X.509 certificates X and Y"). This 562 is a routine that accepts a MIME tree as input (the Cryptographic 563 Payload), wraps the input in the appropriate Cryptographic 564 Envelope, and returns the resultant MIME tree as output. 566 The algorithm returns a MIME object that is ready to be injected into 567 the mail system: 569 * Apply "crypto" to "origbody", yielding MIME tree "output" 571 * For each header name and value "(h,v)" in "origheaders": 573 - Add header "h" of "output" with value "v" 575 * Return "output" 577 5.2. Encryption Outside, Signature Inside 579 Users expect any message that is both signed and encrypted to be 580 signed _inside_ the encryption, and not the other way around. 582 Putting the signature inside the encryption has two advantages: 584 * The details of the signature remain confidential, visible only to 585 the parties capable of decryption. 587 * Any mail transport agent that modifies the message is unlikely to 588 be able to accidentally break the signature. 590 A MUA SHOULD NOT generate an encrypted and signed message where the 591 only signature is outside the encryption. 593 5.3. Avoid Offering Encrypted-only Messages 595 When generating an e-mail, the user has options about what forms of 596 end-to-end cryptographic protections to apply to it. 598 In some cases, offering any end-to-end cryptographic protection is 599 harmful: it may confuse the recipient and offer no benefit. 601 In other cases, signing a message is useful (authenticity and 602 integrity are desirable) but encryption is either impossible (for 603 example, if the sender does not know how to encrypt to all 604 recipients) or meaningless (for example, an e-mail message to a 605 mailing list that is intended to be be published to a public 606 archive). 608 In other cases, full end-to-end confidentiality, authenticity, and 609 integrity are desirable. 611 It is unclear what the use case is for an e-mail message with end-to- 612 end confidentiality but without authenticity or integrity. 614 A reasonable MUA will keep its message composition interface simple, 615 so when presenting the user with a choice of cryptographic 616 protection, it SHOULD offer no more than three choices: 618 * no end-to-end cryptographic protection 620 * signing-only 622 * signed and encrypted 624 5.4. Composing a Reply Message 626 When replying to a message, most MUAs compose an initial draft of the 627 reply that contains quoted text from the original message. A 628 responsible MUA will take precautions to avoid leaking the cleartext 629 of an encrypted message in such a reply. 631 If the original message was end-to-end encrypted, the replying MUA 632 MUST either: 634 * compose the reply with end-to-end encryption, or 636 * avoid including quoted text from the original message. 638 In general, MUAs SHOULD prefer the first option: to compose an 639 encrypted reply. This is what users expect. 641 However, in some circumstances, the replying MUA cannot compose an 642 encrypted reply. For example, the MUA might not have a valid, 643 unexpired, encryption-capable certificate for all recipients. This 644 can also happen during composition when a user adds a new recipient 645 into the reply, or manually toggles the cryptographic protections to 646 remove encryption. 648 In this circumstance, the composing MUA SHOULD strip the quoted text 649 from the original message. 651 Note additional nuance about replies to malformed messages that 652 contain encryption in Section 6.2.2.1. 654 6. Message Interpretation 656 Despite the best efforts of well-intentioned senders to create e-mail 657 messages with well-formed end-to-end cryptographic protection, 658 receiving MUAs will inevitably encounter some messages with malformed 659 end-to-end cryptographic protection. 661 This section offers guidance on dealing with both well-formed and 662 malformed messages containing Cryptographic Layers. 664 6.1. Rendering Well-formed Messages 666 A message is well-formed when it has a Cryptographic Envelope, a 667 Cryptographic Payload, and no Errant Cryptographic Layers. Rendering 668 a well-formed message is straightforward. 670 The receiving MUA should evaluate and summarize the cryptographic 671 properties of the Cryptographic Envelope, and display that status to 672 the user in a secure, strictly-controlled part of the UI. In 673 particular, the part of the UI used to render the cryptographic 674 summary of the message MUST NOT be spoofable, modifiable, or 675 otherwise controllable by the received message itself. 677 Aside from this cryptographic summary, the message itself should be 678 rendered as though the Cryptographic Payload is the body of the 679 message. The Cryptographic Layers themselves SHOULD not be rendered 680 otherwise. 682 6.2. Errant Cryptographic Layers 684 If an incoming message has any Errant Cryptographic Layers, the 685 interpreting MUA SHOULD ignore those layers when rendering the 686 cryptographic summary of the message to the user. 688 6.2.1. Errant Signing Layer 690 When rendering a message with an Errant Cryptographic Layer that 691 provides authenticity and integrity (via signatures), the message 692 should be rendered by replacing the Cryptographic layer with the part 693 it encloses. 695 For example, a message with this structure: 697 A └┬╴multipart/mixed 698 B ├╴text/plain 699 C ├┬╴multipart/signed 700 D │├─╴image/jpeg 701 E │└─╴application/pgp-signature 702 F └─╴text/plain 704 Should be rendered identically to this: 706 A └┬╴multipart/mixed 707 B ├─╴text/plain 708 D ├─╴image/jpeg 709 F └─╴text/plain 711 In such a situation, an MUA SHOULD NOT indicate in the cryptographic 712 summary that the message is signed. 714 6.2.1.1. Exception: Mailing List Footers 716 The use case described in Section 4.5.1 is common enough in some 717 contexts, that a MUA MAY decide to handle it as a special exception. 719 If the MUA determines that the message comes from a mailing list (it 720 has a "List-ID" header), and it has a structure that appends a footer 721 to a signing-only Cryptographic Layer with a valid signature, such 722 as: 724 H └┬╴multipart/mixed 725 I ├┬╴multipart/signed 726 J │├─╴[protected part, may be arbitrary MIME subtree] 727 K │└─╴application/{pgp,pkcs7}-signature 728 L └─╴[footer, typically text/plain] 730 or: 732 H └┬╴multipart/mixed 733 I ├─╴application/pkcs7-mime; smime-type="signed-data" 734 │⇩ (unwraps to) 735 J │└─╴[protected part, may be an arbitrary MIME subtree] 736 L └─╴[footer, typically text/plain] 738 Then, the MUA MAY indicate to the user that this is a signed message 739 that has been wrapped by the mailing list. 741 In this case, the MUA MUST distinguish the footer (part "L") from the 742 protected part (part "J") when rendering any information about the 743 signature. 745 One way to do this is to offer the user two different views of the 746 message: the "mailing list" view, which hides any cryptographic 747 summary but shows the footer: 749 Cryptographic Protections: none 750 H └┬╴multipart/mixed 751 J ├─╴[protected part, may be arbitrary MIME subtree] 752 L └─╴[footer, typically text/plain] 754 or the "sender's view", which shows the cryptographic summary but 755 hides the footer: 757 Cryptographic Protections: signed [details from part I] 758 J └─╴[protected part, may be arbitrary MIME subtree] 760 6.2.2. Errant Encryption Layer 762 An MUA may encounter a message with an Errant Cryptographic Layer 763 that offers confidentiality (encryption), and the MUA is capable of 764 decrypting it. 766 The user wants to be able to see the contents of any message that 767 they receive, so an MUA in this situation SHOULD decrypt the part. 769 In this case, though, the MUA MUST NOT indicate in the message's 770 cryptographic summary that the message itself was encrypted. Such an 771 indication could be taken to mean that other (non-encrypted) parts of 772 the message arrived with cryptographic confidentiality. 774 6.2.2.1. Replying to a Message with an Errant Encryption Layer 776 Note that there is an asymmetry here between rendering and replying 777 to a message with an Errant Encryption Layer. 779 When rendering, the MUA does not indicate that the message was 780 encrypted, even if some subpart of it was decrypted for rendering. 782 But when composing a reply that contains quoted text from the 783 decrypted subpart, the reply message SHOULD be marked for encryption, 784 as noted in {#composing-reply}. 786 Alternately, if the reply message cannot be encrypted (or if the user 787 elects to not encrypt the reply), the composed reply MUST NOT include 788 any material from the decrypted subpart. 790 6.3. Forwarded Messages with Cryptographic Protection 792 An incoming e-mail message may include an attached forwarded message, 793 typically as a MIME subpart with "Content-Type: message/rfc822" 794 ([RFC5322]) or "Content-Type: message/global" ([RFC5355]). 796 Regardless of the cryptographic protections and structure of the 797 incoming message, the internal forwarded message may have its own 798 Cryptographic Envelope. 800 The Cryptographic Layers that are part of the Cryptographic Envelope 801 of the forwarded message are not Errant Cryptographic Layers of the 802 surrounding message -- they are simply layers that apply to the 803 forwarded message itself. 805 The rendering MUA MUST NOT conflate the cryptographic protections of 806 the forwarded message with the cryptographic protections of the 807 incoming message. 809 The rendering MUA MAY render a cryptograpic summary of the 810 protections afforded to the forwarded message by its own 811 Cryptographic Envelope, as long as that rendering is unambiguously 812 tied to the forwarded message itself. 814 6.4. Signature failures 816 A cryptographic signature may fail in multiple ways. A receiving MUA 817 that discovers a failed signature should treat the message as though 818 the signature did not exist. This is similar to the standard 819 guidance for about failed DKIM signatures (see section 6.1 of 820 [RFC6376]). 822 A MUA SHOULD NOT render a message with a failed signature as more 823 dangerous or more dubious than a comparable message without any 824 signature at all. 826 A MUA that encounters an encrypted-and-signed message where the 827 signature is invalid SHOULD treat the message the same way that it 828 would treat a message that is encryption-only. 830 Some different ways that a signature may be invalid on a given 831 message: 833 * the signature is not cryptographically valid (the math fails). 835 * the signature relies on suspect cryptographic primitives (e.g. 836 over a legacy digest algorithm, or was made by a weak key, e.g., 837 1024-bit R.SA) 839 * the signature is made by a certificate which the receiving MUA 840 does not have access to. 842 * the certificate that made the signature was revoked. 844 * the certificate that made the signature was expired at the time 845 that the signature was made. 847 * the certificate that made the signature does not correspond to the 848 author of the message. (for X.509, there is no subjectAltName of 849 type RFC822Name whose value matches an e-mail address found in 850 "From:" or "Sender:") 852 * the certificate that made the signature was not issued by an 853 authority that the MUA user is willing to rely on for certifying 854 the sender's e-mail address. 856 * the signature indicates that it was made at a time much before or 857 much after from the date of the message itself. 859 A valid signature must pass all these tests, but of course invalid 860 signatures may be invalid in more than one of the ways listed above. 862 7. Certificate Management 864 A cryptographically-capable MUA typically maintains knowledge about 865 certificates for the user's own account(s), as well as certificates 866 for the peers that it communicates with. 868 7.1. Peer Certificates 870 Most certificates that a cryptographically-capable MUA will use will 871 be certificates belonging to the parties that the user communicates 872 with through the MUA. This section discusses how to manage the 873 certificates that belong to such a peer. 875 The MUA will need to be able to discover X.509 certificates for each 876 peer, cache them, and select among them when composing an encrypted 877 message. 879 7.1.1. Cert Discovery from Incoming Messages 881 TODO: incoming PKCS#7 messages tend to have a bundle of certificates 882 in them. How should these certs be handled? 884 TODO: point to Autocrypt certificate discovery mechanism 886 TODO: point to OpenPGP embedded certificate subpacket proposal 887 TODO: compare mechanisms, explain where each case is useful. 889 7.1.2. Certificate Directories 891 Some MUAs may have the capability to look up peer certificates in a 892 directory. 894 TODO: more information here about X.509 directories -- LDAP? 896 TODO: mention WKD for OpenPGP certificates? 898 7.1.3. Peer Certificate Selection 900 When composing an encrypted message, the MUA needs to select a 901 certificate for each recipient that is capable of encryption. 903 To select such a certificate for a given destination e-mail address, 904 the MUA should look through all of its known certificates and verify 905 that _all_ of the conditions below are met: 907 * The certificate must be valid, not expired or revoked. 909 * It must have a subjectAltName of type rFC822Name whose contents 910 exactly match the destination address. 912 * The algorithm OID in the certificate's SPKI is known to the MUA 913 and capable of encryption. Examples include (TODO: need OIDs) 915 - RSA, with keyUsage present and the "key encipherment" bit set 917 - EC Public Key, with keyUsage present and the "key agreement" 918 bit set 920 - EC DH, with keyUsage present and the "key agreement" bit set 922 * If extendedKeyUsage is present, it contains at least one of the 923 following OIDs: e-mail protection, anyExtendedKeyUsage. 925 TODO: If OID is EC Public Key and keyUsage is absent, what should 926 happen? 928 TODO: what if multiple certificates meet all of these criteria for a 929 given recipient? 931 7.1.4. Checking for Revocation 933 TODO: discuss how/when to check for peer certificate revocation 934 TODO: privacy concerns: what information leaks to whom when checking 935 peer cert revocations? 937 7.2. Local Certificates 939 The MUA also needs to know about one or more certificates associated 940 with the user's e-mail account. It is typically expected to have 941 access to the secret key material associated with the public keys in 942 those certificates. 944 7.2.1. Getting a Certificate for the User 946 TODO: mention ACME SMIME? 948 TODO: mention automatic self-signed certs e.g. OpenPGP? 950 TODO: SHOULD generate secret key material locally, and MUST NOT 951 accept secret key material from an untrusted third party as the basis 952 for the user's certificate. 954 7.2.2. Local Certificate Maintenance 956 The MUA should warn the user when/if: 958 * The user's own certificate set does not include a valid, unexpired 959 encryption-capable X.509 certificate, and a valid, unexpired 960 signature-capable X.509 certificate. 962 * Any of the user's own certificates is due to expire soon (TODO: 963 what is "soon"?) 965 * Any of the user's own certificates does not match the e-mail 966 address associated with the user's account. 968 * Any of the user's own certificates does not have a keyUsage 969 section 971 * Any of the user's own certificates does not contain an 972 extendedKeyUsage extension 974 TODO: how does the MUA do better than warning in the cases above? 975 What can the MUA actually _do_ here to fix problems before they 976 happen? 978 TODO: discuss how/when to check for own certificate revocation, and 979 what to do if it (or any intermediate certificate authority) is found 980 to be revoked. 982 7.2.3. Shipping Certificates in Outbound Messages 984 TODO: What certificates should the MUA include in an outbound message 985 so that peers can discover them? 987 * local signing certificate so that signature can be validated 989 * local encryption-capable certificate(s) so that incoming messages 990 can be encypted. 992 * On an encrypted message to multiple recipients, the encryption- 993 capable peer certs of the other recipients (to enable "reply 994 all")? 996 * intermediate certificates to chain all of the above to some set of 997 root authorities? 999 7.3. Certificate Authorities 1001 TODO: how should the MUA select root certificate authorities? 1003 TODO: should the MUA cache intermediate CAs? 1005 TODO: should the MUA share such a cache with other PKI clients (e.g., 1006 web browsers)? Are there distinctions between a CA for S/MIME and 1007 for the web? 1009 8. Common Pitfalls and Guidelines 1011 This section highlights a few "pitfalls" and guidelines based on 1012 these discussions and lessons learned. 1014 FIXME: some possible additional commentary on: 1016 * indexing and search of encrypted messages 1018 * managing access to cryptographic secret keys that require user 1019 interaction 1021 * secure deletion 1023 * inline PGP, ugh 1025 * storage of composed/sent messages 1027 * encrypt-to-self during composition 1029 * cached signature validation 1030 * interaction between encryption and Bcc 1032 * aggregated cryptographic status of threads/conversations ? 1034 * Draft messages 1036 * copies to the Sent folder 1038 9. IANA Considerations 1040 MAYBE: provide an indicator in the IANA header registry for which 1041 headers are "structural" ? This is probably unnecessary. 1043 10. Security Considerations 1045 This entire document addresses security considerations about end-to- 1046 end cryptographic protections for e-mail messages. 1048 11. Acknowledgements 1050 The set of constructs and recommendations in this document are 1051 derived from discussions with many different implementers, including 1052 Alexey Melnikov, Bernie Hoeneisen, Bjarni Runar Einarsson, David 1053 Bremner, Deb Cooley, Holger Krekel, Jameson Rollins, Jonathan 1054 Hammell, juga, Patrick Brunschwig, Santosh Chokhani, and Vincent 1055 Breitmoser. 1057 12. References 1059 12.1. Normative References 1061 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1062 Requirement Levels", BCP 14, RFC 2119, 1063 DOI 10.17487/RFC2119, March 1997, 1064 . 1066 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1067 "MIME Security with OpenPGP", RFC 3156, 1068 DOI 10.17487/RFC3156, August 2001, 1069 . 1071 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 1072 Extensions (MIME) Part Four: Registration Procedures", 1073 BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005, 1074 . 1076 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1077 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1078 May 2017, . 1080 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1081 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1082 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1083 April 2019, . 1085 12.2. Informative References 1087 [chrome-indicators] 1088 Schechter, E., "Evolving Chrome's security indicators", 1089 May 2018, . 1092 [EFAIL] "EFAIL", n.d., . 1094 [I-D.draft-bre-openpgp-samples-01] 1095 Einarsson, B. R., "juga", and D. K. Gillmor, "OpenPGP 1096 Example Keys and Certificates", Work in Progress, 1097 Internet-Draft, draft-bre-openpgp-samples-01, 20 December 1098 2019, . 1101 [I-D.draft-dkg-lamps-samples-05] 1102 Gillmor, D. K., "S/MIME Example Keys and Certificates", 1103 Work in Progress, Internet-Draft, draft-dkg-lamps-samples- 1104 05, 18 February 2021, . 1107 [RFC3274] Gutmann, P., "Compressed Data Content Type for 1108 Cryptographic Message Syntax (CMS)", RFC 3274, 1109 DOI 10.17487/RFC3274, June 2002, 1110 . 1112 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1113 Thayer, "OpenPGP Message Format", RFC 4880, 1114 DOI 10.17487/RFC4880, November 2007, 1115 . 1117 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1118 DOI 10.17487/RFC5322, October 2008, 1119 . 1121 [RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Sengodan, S., 1122 and M. Holdrege, "Threats Introduced by Reliable Server 1123 Pooling (RSerPool) and Requirements for Security in 1124 Response to Threats", RFC 5355, DOI 10.17487/RFC5355, 1125 September 2008, . 1127 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1128 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1129 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1130 . 1132 Appendix A. Test Vectors 1134 FIXME: This document should contain examples of well-formed and 1135 malformed messages using cryptographic key material and certificates 1136 from [I-D.draft-bre-openpgp-samples-01] and 1137 [I-D.draft-dkg-lamps-samples-05]. 1139 It may also include example renderings of these messages. 1141 Appendix B. Document Considerations 1143 [ RFC Editor: please remove this section before publication ] 1145 This document is currently edited as markdown. Minor editorial 1146 changes can be suggested via merge requests at 1147 https://gitlab.com/dkg/e2e-mail-guidance or by e-mail to the editor. 1148 Please direct all significant commentary to the public IETF LAMPS 1149 mailing list: spasm@ietf.org 1151 B.1. Document History 1153 B.1.1. Substantive changes from draft-dkg-...-01 to draft-ietf-...-00 1155 * WG adopted draft 1157 * moved Document History and Document Considerations sections to end 1158 of appendix, to avoid section renumbering when removed 1160 B.1.2. Substantive changes from draft-dkg-...-00 to draft-dkg-...-01 1162 * consideration of success/failure indicators for usability 1164 * clarify extendedKeyUsage and keyUsage algorithm-specific details 1166 * initial section on certificate management 1168 * added more TODO items 1170 Author's Address 1172 Daniel Kahn Gillmor (editor) 1173 American Civil Liberties Union 1174 125 Broad St. 1175 New York, NY, 10004 1176 United States of America 1178 Email: dkg@fifthhorseman.net