idnits 2.17.1 draft-ietf-lamps-e2e-mail-guidance-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: ---------------------------------------------------------------------------- == There are 85 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 (25 January 2022) is 822 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-lamps-samples-05 Summary: 0 errors (**), 0 flaws (~~), 5 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 25 January 2022 5 Expires: 29 July 2022 7 Guidance on End-to-End E-mail Security 8 draft-ietf-lamps-e2e-mail-guidance-02 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 29 July 2022. 38 Copyright Notice 40 Copyright (c) 2022 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 Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised 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 1.2.2. User-Facing Headers . . . . . . . . . . . . . . . . . 5 59 2. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.2. E-mail Users Want a Familiar Experience . . . . . . . . . 6 62 2.3. Warning About Failure vs. Announcing Success . . . . . . 7 63 3. Types of Protection . . . . . . . . . . . . . . . . . . . . . 8 64 4. Cryptographic MIME Message Structure . . . . . . . . . . . . 8 65 4.1. Cryptographic Layers . . . . . . . . . . . . . . . . . . 8 66 4.1.1. S/MIME Cryptographic Layers . . . . . . . . . . . . . 8 67 4.1.2. PGP/MIME Cryptographic Layers . . . . . . . . . . . . 9 68 4.2. Cryptographic Envelope . . . . . . . . . . . . . . . . . 10 69 4.3. Cryptographic Payload . . . . . . . . . . . . . . . . . . 11 70 4.4. Types of Cryptographic Envelope . . . . . . . . . . . . . 11 71 4.4.1. Simple Cryptographic Envelopes . . . . . . . . . . . 11 72 4.4.2. Multilayer Cryptographic Envelopes . . . . . . . . . 11 73 4.5. Errant Crytptographic Layers . . . . . . . . . . . . . . 11 74 4.5.1. Mailing List Wrapping . . . . . . . . . . . . . . . . 12 75 4.5.2. A Baroque Example . . . . . . . . . . . . . . . . . . 12 76 5. Message Composition . . . . . . . . . . . . . . . . . . . . . 13 77 5.1. Message Composition Algorithm . . . . . . . . . . . . . . 13 78 5.2. Encryption Outside, Signature Inside . . . . . . . . . . 14 79 5.3. Avoid Offering Encrypted-only Messages . . . . . . . . . 14 80 5.4. Composing a Reply Message . . . . . . . . . . . . . . . . 15 81 6. Message Interpretation . . . . . . . . . . . . . . . . . . . 15 82 6.1. Rendering Well-formed Messages . . . . . . . . . . . . . 16 83 6.2. Errant Cryptographic Layers . . . . . . . . . . . . . . . 16 84 6.2.1. Errant Signing Layer . . . . . . . . . . . . . . . . 16 85 6.2.2. Errant Encryption Layer . . . . . . . . . . . . . . . 18 86 6.3. Forwarded Messages with Cryptographic Protection . . . . 18 87 6.4. Signature failures . . . . . . . . . . . . . . . . . . . 19 88 7. Reasoning about Message Parts . . . . . . . . . . . . . . . . 20 89 7.1. Main Body Part . . . . . . . . . . . . . . . . . . . . . 20 90 7.2. Attachments . . . . . . . . . . . . . . . . . . . . . . . 21 91 7.3. MIME Part Examples . . . . . . . . . . . . . . . . . . . 21 92 8. Certificate Management . . . . . . . . . . . . . . . . . . . 22 93 8.1. Peer Certificates . . . . . . . . . . . . . . . . . . . . 23 94 8.1.1. Cert Discovery from Incoming Messages . . . . . . . . 23 95 8.1.2. Certificate Directories . . . . . . . . . . . . . . . 23 96 8.1.3. Peer Certificate Selection . . . . . . . . . . . . . 23 97 8.1.4. Checking for Revocation . . . . . . . . . . . . . . . 24 98 8.2. Local Certificates . . . . . . . . . . . . . . . . . . . 24 99 8.2.1. Getting a Certificate for the User . . . . . . . . . 24 100 8.2.2. Local Certificate Maintenance . . . . . . . . . . . . 24 101 8.2.3. Shipping Certificates in Outbound Messages . . . . . 25 102 8.3. Certificate Authorities . . . . . . . . . . . . . . . . . 25 103 9. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 26 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 106 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 107 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 108 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 109 13.2. Informative References . . . . . . . . . . . . . . . . . 27 110 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 28 111 Appendix B. Document Considerations . . . . . . . . . . . . . . 29 112 B.1. Document History . . . . . . . . . . . . . . . . . . . . 29 113 B.1.1. Substantive changes from draft-ietf-...-01 to 114 draft-ietf-...-02 . . . . . . . . . . . . . . . . . . 29 115 B.1.2. Substantive changes from draft-ietf-...-00 to 116 draft-ietf-...-01 . . . . . . . . . . . . . . . . . . 29 117 B.1.3. Substantive changes from draft-dkg-...-01 to 118 draft-ietf-...-00 . . . . . . . . . . . . . . . . . . 29 119 B.1.4. Substantive changes from draft-dkg-...-00 to 120 draft-dkg-...-01 . . . . . . . . . . . . . . . . . . 29 121 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 123 1. Introduction 125 E-mail end-to-end security using S/MIME ([RFC8551]) and PGP/MIME 126 ([RFC3156]) cryptographic standards can provide integrity, 127 authentication and confidentiality to MIME ([RFC4289]) e-mail 128 messages. 130 However, there are many ways that a receiving mail user agent can 131 misinterpret or accidentally break these security guarantees (e.g., 132 [EFAIL]). 134 A mail user agent that interprets a message with end-to-end 135 cryptographic protections needs to do so defensively, staying alert 136 to different ways that these protections can be bypassed by mangling 137 (either malicious or accidental) or a failed user experience. 139 A mail user agent that generates a message with end-to-end 140 cryptographic protections should be aware of these defensive 141 interpretation strategies, and should compose any new outbound 142 message conservatively if they want the protections to remain intact. 144 1.1. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14 ([RFC2119] and [RFC8174]) when, and only when, they appear in all 150 capitals, as shown here. 152 1.2. Terminology 154 For the purposes of this document, we define the following concepts: 156 * _MUA_ is short for Mail User Agent; an e-mail client. 158 * _Protection_ of message data refers to cryptographic encryption 159 and/or signatures, providing confidentiality, authenticity, and/or 160 integrity. 162 * _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic 163 Payload_, and _Errant Cryptographic Layer_ are defined in 164 Section 4 166 * A _well-formed_ e-mail message with cryptographic protection has 167 both a _Cryptographic Envelope_ and a _Cryptographic Payload_. 169 * _Structural Headers_ are documented in Section 1.2.1. 171 * _User-Facing Headers_ are documented in Section 1.2.2. 173 * _Main Body Part_ is the part (or parts) that are typically 174 rendered to the user as the message itself (not "as an 175 attachment). See Section 7.1. 177 1.2.1. Structural Headers 179 A message header whose name begins with Content- is referred to in 180 this document as a "structural" header. 182 These headers indicate something about the specific MIME part they 183 are attached to, and cannot be transferred or copied to other parts 184 without endangering the readability of the message. 186 This includes (but is not limited to): 188 * Content-Type 190 * Content-Transfer-Encoding 192 * Content-Disposition 194 FIXME: are there any non-Content-* headers we should consider as 195 structural? 197 1.2.2. User-Facing Headers 199 Of all the headers that an e-mail message may contain, only a handful 200 are typically presented directly to the user. The user-facing 201 headers are: 203 * Subject 205 * From 207 * To 209 * Cc 211 * Date 213 * Reply-To 215 * Followup-To 217 The above is a complete list. No other headers are considered "user- 218 facing". 220 Other headers may affect the visible rendering of the message (e.g., 221 References and In-Reply-To may affect the placement of a message in a 222 threaded discussion), but they are not directly displayed to the user 223 and so are not considered "user-facing". 225 2. Usability 227 Any MUA that enables its user to transition from unprotected messages 228 to messages with end-to-end cryptographic protection needs to 229 consider how the user understands this transition. That said, the 230 primary goal of the user of an MUA is communication -- so interface 231 elements that get in the way of communication should be avoided where 232 possible. 234 Furthermore, it is likely is that the user will continue to encounter 235 unprotected messages, and may need to send unprotected messages (for 236 example, if a given recipient cannot handle cryptographic 237 protections). This means that the MUA needs to provide the user with 238 some guidance, so that they understand what protections any given 239 message or conversation has. But the user should not be overwhelmed 240 with choices or presented with unactionable information. 242 2.1. Simplicity 244 The end user (the operator of the MUA) is unlikely to understand 245 complex end-to-end cryptographic protections on any e-mail message, 246 so keep it simple. 248 For clarity to the user, any cryptographic protections should apply 249 to the message as a whole, not just to some subparts. 251 This is true for message composition: the standard message 252 composition user interface of an MUA should offer minimal controls 253 which indicate which types of protection to apply to the new message 254 as a whole. 256 This is also true for message interpretation: the standard message 257 rendering user interface of an MUA should offer a minimal, clear 258 indicator about the end-to-end cryptographic status of the message as 259 a whole. 261 2.2. E-mail Users Want a Familiar Experience 263 A person communicating over the Internet today often has many options 264 for reaching their desired correspondent, including web-based 265 bulletin boards, contact forms, and instant messaging services. 267 E-mail offers a few distinctions from these other systems, most 268 notably features like: 270 * Ubiquity: Most correspondents will have an e-mail address, while 271 not everyone is present on every alternate messaging service, 273 * Federation: interaction between users on distinct domains who have 274 not agreed on a common communications provider is still possible, 275 and 277 * User Control: the user can interact with the e-mail system using a 278 MUA of their choosing, including automation and other control over 279 their preferred and/or customized workflow. 281 Other systems (like some popular instant messaging applications, such 282 as WhatsApp and Signal Private Messenger) offer built-in end-to-end 283 cryptographic protections by default, which are simpler for the user 284 to understand. ("All the messages I see on Signal are confidential 285 and integrity-protected" is a clean user story) 287 A user of e-mail is likely using e-mail instead of other systems 288 because of the distinctions outlined above. When adding end-to-end 289 cryptographic protection to an e-mail endpoint, care should be taken 290 not to negate any of the distinct features of e-mail as a whole. If 291 these features are violated to provide end-to-end crypto, the user 292 may just as well choose one of the other systems that don't have the 293 drawbacks that e-mail has. Implmenters should try to provide end-to- 294 end protections that retain the familiar experience of e-mail itself. 296 Furthermore, an e-mail user is likely to regularly interact with 297 other e-mail correspondents who _cannot_ handle or produce end-to-end 298 cryptographic protections. Care should be taken that enabling 299 cryptography in a MUA does not inadvertently limit the ability of the 300 user to interact with legacy correspondents. 302 2.3. Warning About Failure vs. Announcing Success 304 Moving the web from http to https offers useful historical 305 similarities to adding end-to-end encryption to e-mail. 307 In particular, the indicators of what is "secure" vs. "insecure" for 308 web browsers have changed over time. For example, years ago the 309 default experience was http, and https sites were flagged with 310 "secure" indicators like a lock icon. In 2018, some browsers 311 reversed that process by downplaying https, and instead visibly 312 marking http as "not secure" (see [chrome-indicators]). 314 By analogy, when the user of a MUA first enables end-to-end 315 cryptographic protection, it's likely that they will want to see 316 which messages _have_ protection. But a user whose e-mail 317 communications are entirely end-to-end protected might instead want 318 to know which messages do _not_ have the expected protections. 320 Note also that some messages are expected to be confidential, but 321 other messages are expected to be public -- the types of protection 322 (see Section 3) that apply to each particular message will be 323 different. And the types of protection that are _expected_ to be 324 present in any context might differ (for example, by sender, by 325 thread, or by date). 327 It is out of scope for this document to define expectations about 328 protections for any given message, but an implementer who cares about 329 usable experience should be deliberate and judicious about the 330 expectations their interface assumes that the user has in a given 331 context. 333 3. Types of Protection 335 A given message might be: 337 * signed, 339 * encrypted, 341 * both signed and encrypted, or 343 * none of the above. 345 Given that many e-mail messages offer no cryptographic protections, 346 the user needs to be able to detect which protections are present for 347 any given message. 349 4. Cryptographic MIME Message Structure 351 Implementations use the structure of an e-mail message to protect the 352 headers. This section establishes some conventions about how to 353 think about message structure. 355 4.1. Cryptographic Layers 357 "Cryptographic Layer" refers to a MIME substructure that supplies 358 some cryptographic protections to an internal MIME subtree. The 359 internal subtree is known as the "protected part" though of course it 360 may itself be a multipart object. 362 In the diagrams below, "↧" (DOWNWARDS ARROW FROM BAR, U+21A7) 363 indicates "decrypts to", and "⇩" (DOWNWARDS WHITE ARROW, U+21E9) 364 indicates "unwraps to". 366 4.1.1. S/MIME Cryptographic Layers 368 For S/MIME [RFC8551], there are four forms of Cryptographic Layers: 369 multipart/signed, PKCS#7 signed-data, PKCS7 enveloped-data, PKCS7 370 authEnveloped-data. 372 4.1.1.1. S/MIME Multipart Signed Cryptographic Layer 373 └┬╴multipart/signed; protocol="application/pkcs7-signature" 374 ├─╴[protected part] 375 └─╴application/pkcs7-signature 377 This MIME layer offers authentication and integrity. 379 4.1.1.2. S/MIME PKCS7 signed-data Cryptographic Layer 381 └─╴application/pkcs7-mime; smime-type="signed-data" 382 ⇩ (unwraps to) 383 └─╴[protected part] 385 This MIME layer offers authentication and integrity. 387 4.1.1.3. S/MIME PKCS7 enveloped-data Cryptographic Layer 389 └─╴application/pkcs7-mime; smime-type="enveloped-data" 390 ↧ (decrypts to) 391 └─╴[protected part] 393 This MIME layer offers confidentiality. 395 4.1.1.4. S/MIME PKCS7 authEnveloped-data Cryptographic Layer 397 └─╴application/pkcs7-mime; smime-type="authEnveloped-data" 398 ↧ (decrypts to) 399 └─╴[protected part] 401 This MIME layer offers confidentiality and integrity. 403 Note that enveloped-data (Section 4.1.1.3) and authEnveloped-data 404 (Section 4.1.1.4) have identical message structure and semantics. 405 The only difference between the two is ciphertext malleability. 407 The examples in this document only include enveloped-data, but the 408 implications for that layer apply to authEnveloped-data as well. 410 4.1.1.5. PKCS7 Compression is NOT a Cryptographic Layer 412 The Cryptographic Message Syntax (CMS) provides a MIME compression 413 layer (smime-type="compressed-data"), as defined in [RFC3274]. While 414 the compression layer is technically a part of CMS, it is not 415 considered a Cryptographic Layer for the purposes of this document. 417 4.1.2. PGP/MIME Cryptographic Layers 419 For PGP/MIME [RFC3156] there are two forms of Cryptographic Layers, 420 signing and encryption. 422 4.1.2.1. PGP/MIME Signing Cryptographic Layer (multipart/signed) 424 └┬╴multipart/signed; protocol="application/pgp-signature" 425 ├─╴[protected part] 426 └─╴application/pgp-signature 428 This MIME layer offers authenticity and integrity. 430 4.1.2.2. PGP/MIME Encryption Cryptographic Layer (multipart/encrypted) 432 └┬╴multipart/encrypted 433 ├─╴application/pgp-encrypted 434 └─╴application/octet-stream 435 ↧ (decrypts to) 436 └─╴[protected part] 438 This MIME layer can offer any of: 440 * confidentiality (via a Symmetrically Encrypted Data Packet, see 441 Section 5.7 of [RFC4880]; a MUA MUST NOT generate this form due to 442 ciphertext malleability) 444 * confidentiality and integrity (via a Symmetrically Encrypted 445 Integrity Protected Data Packet (SEIPD), see section 5.13 of 446 [RFC4880]), or 448 * confidentiality, integrity, and authenticity all together (by 449 including an OpenPGP Signature Packet within the SEIPD). 451 4.2. Cryptographic Envelope 453 The Cryptographic Envelope is the largest contiguous set of 454 Cryptographic Layers of an e-mail message starting with the outermost 455 MIME type (that is, with the Content-Type of the message itself). 457 If the Content-Type of the message itself is not a Cryptographic 458 Layer, then the message has no cryptographic envelope. 460 "Contiguous" in the definition above indicates that if a 461 Cryptographic Layer is the protected part of another Cryptographic 462 Layer, the layers together comprise a single Cryptographic Envelope. 464 Note that if a non-Cryptographic Layer intervenes, all Cryptographic 465 Layers within the non-Cryptographic Layer _are not_ part of the 466 Cryptographic Envelope. They are Errant Cryptographic Layers (see 467 Section 4.5). 469 Note also that the ordering of the Cryptographic Layers implies 470 different cryptographic properties. A signed-then-encrypted message 471 is different than an encrypted-then-signed message. See Section 5.2. 473 4.3. Cryptographic Payload 475 The Cryptographic Payload of a message is the first non-Cryptographic 476 Layer -- the "protected part" -- within the Cryptographic Envelope. 478 4.4. Types of Cryptographic Envelope 480 4.4.1. Simple Cryptographic Envelopes 482 As described above, if the "protected part" identified in the sction 483 above is not itself a Cryptographic Layer, that part _is_ the 484 Cryptographic Payload. 486 If the application wants to generate a message that is both encrypted 487 and signed, it MAY use the simple MIME structure from Section 4.1.2.2 488 by ensuring that the [RFC4880] Encrypted Message within the 489 application/octet-stream part contains an [RFC4880] Signed Message 490 (the final option described in Section 4.1.2.2. 492 4.4.2. Multilayer Cryptographic Envelopes 494 It is possible to construct a Cryptographic Envelope consisting of 495 multiple layers with either S/MIME or PGP/MIME , for example using 496 the following structure: 498 A └─╴application/pkcs7-mime; smime-type="enveloped-data" 499 B ↧ (decrypts to) 500 C └─╴application/pkcs7-mime; smime-type="signed-data" 501 D ⇩ (unwraps to) 502 E └─╴[protected part] 504 When handling such a message, the properties of the Cryptographic 505 Envelope are derived from the series A, C. 507 As noted in Section 4.4.1, PGP/MIME applications also have a simpler 508 MIME construction available with the same cryptographic properties. 510 4.5. Errant Crytptographic Layers 512 Due to confusion, malice, or well-intentioned tampering, a message 513 may contain a Cryptographic Layer that is not part of the 514 Cryptographic Envelope. Such a layer is an Errant Cryptographic 515 Layer. 517 An Errant Cryptographic Layer SHOULD NOT contribute to the message's 518 overall cryptographic state. 520 Guidance for dealing with Errant Cryptographic Layers can be found in 521 Section 6.2. 523 4.5.1. Mailing List Wrapping 525 Some mailing list software will re-wrap a well-formed signed message 526 before re-sending to add a footer, resulting in the following 527 structure seen by recipients of the e-mail: 529 H └┬╴multipart/mixed 530 I ├┬╴multipart/signed 531 J │├─╴text/plain 532 K │└─╴application/pgp-signature 533 L └─╴text/plain 535 In this message, L is the footer added by the mailing list. I is now 536 an Errant Cryptographic Layer. 538 Note that this message has no Cryptographic Envelope at all. 540 It is NOT RECOMMENDED to produce e-mail messages with this structure, 541 because the data in part L may appear to the user as though it were 542 part of J, though they have different cryptographic properties. In 543 particular, if the user believes that the message is signed, but 544 cannot distinguish L from J then the author of L can effectively 545 tamper with content of the signed message, breaking the user's 546 expectation of integrity and authenticity. 548 4.5.2. A Baroque Example 550 Consider a message with the following overcomplicated structure: 552 M └┬╴multipart/encrypted 553 N ├─╴application/pgp-encrypted 554 O └─╴application/octet-stream 555 P ↧ (decrypts to) 556 Q └┬╴multipart/signed 557 R ├┬╴multipart/mixed 558 S │├┬╴multipart/signed 559 T ││├─╴text/plain 560 U ││└─╴application/pgp-signature 561 V │└─╴text/plain 562 W └─╴application/pgp-signature 563 The 3 Cryptographic Layers in such a message are rooted in parts M, 564 Q, and S. But the Cryptographic Envelope of the message consists 565 only of the properties derived from the series M, Q. The 566 Cryptographic Payload of the message is part R. Part S is an Errant 567 Cryptographic Layer. 569 Note that this message has both a Cryptographic Envelope _and_ an 570 Errant Cryptographic Layer. 572 It is NOT RECOMMENDED to generate messages with such complicated 573 structures. Even if a receiving MUA can parse this structure 574 properly, it is nearly impossible to render in a way that the user 575 can reason about the cryptographic properties of part T compared to 576 part V. 578 5. Message Composition 580 This section describes the ideal composition of an e-mail message 581 with end-to-end cryptographic protection. A message composed with 582 this form is most likely to achieve its end-to-end security goals. 584 5.1. Message Composition Algorithm 586 This section roughly describes the steps that a MUA should use to 587 compose a cryptographically-protected message that has a proper 588 cryptographic envelope and payload. 590 The message composition algorithm takes three parameters: 592 * origbody: the traditional unprotected message body as a well- 593 formed MIME tree (possibly just a single MIME leaf part). As a 594 well-formed MIME tree, origbody already has structural headers 595 present (see Section 1.2.1). 597 * origheaders: the intended non-structural headers for the message, 598 represented here as a list of (h,v) pairs, where h is a header 599 field name and v is the associated value. 601 * crypto: The series of cryptographic protections to apply (for 602 example, "sign with the secret key corresponding to X.509 603 certificate X, then encrypt to X.509 certificates X and Y"). This 604 is a routine that accepts a MIME tree as input (the Cryptographic 605 Payload), wraps the input in the appropriate Cryptographic 606 Envelope, and returns the resultant MIME tree as output. 608 The algorithm returns a MIME object that is ready to be injected into 609 the mail system: 611 * Apply crypto to origbody, yielding MIME tree output 613 * For each header name and value (h,v) in origheaders: 615 - Add header h of output with value v 617 * Return output 619 5.2. Encryption Outside, Signature Inside 621 Users expect any message that is both signed and encrypted to be 622 signed _inside_ the encryption, and not the other way around. 624 Putting the signature inside the encryption has two advantages: 626 * The details of the signature remain confidential, visible only to 627 the parties capable of decryption. 629 * Any mail transport agent that modifies the message is unlikely to 630 be able to accidentally break the signature. 632 A MUA SHOULD NOT generate an encrypted and signed message where the 633 only signature is outside the encryption. 635 5.3. Avoid Offering Encrypted-only Messages 637 When generating an e-mail, the user has options about what forms of 638 end-to-end cryptographic protections to apply to it. 640 In some cases, offering any end-to-end cryptographic protection is 641 harmful: it may confuse the recipient and offer no benefit. 643 In other cases, signing a message is useful (authenticity and 644 integrity are desirable) but encryption is either impossible (for 645 example, if the sender does not know how to encrypt to all 646 recipients) or meaningless (for example, an e-mail message to a 647 mailing list that is intended to be be published to a public 648 archive). 650 In other cases, full end-to-end confidentiality, authenticity, and 651 integrity are desirable. 653 It is unclear what the use case is for an e-mail message with end-to- 654 end confidentiality but without authenticity or integrity. 656 A reasonable MUA will keep its message composition interface simple, 657 so when presenting the user with a choice of cryptographic 658 protection, it SHOULD offer no more than three choices: 660 * no end-to-end cryptographic protection 662 * signing-only 664 * signed and encrypted 666 5.4. Composing a Reply Message 668 When replying to a message, most MUAs compose an initial draft of the 669 reply that contains quoted text from the original message. A 670 responsible MUA will take precautions to avoid leaking the cleartext 671 of an encrypted message in such a reply. 673 If the original message was end-to-end encrypted, the replying MUA 674 MUST either: 676 * compose the reply with end-to-end encryption, or 678 * avoid including quoted text from the original message. 680 In general, MUAs SHOULD prefer the first option: to compose an 681 encrypted reply. This is what users expect. 683 However, in some circumstances, the replying MUA cannot compose an 684 encrypted reply. For example, the MUA might not have a valid, 685 unexpired, encryption-capable certificate for all recipients. This 686 can also happen during composition when a user adds a new recipient 687 into the reply, or manually toggles the cryptographic protections to 688 remove encryption. 690 In this circumstance, the composing MUA SHOULD strip the quoted text 691 from the original message. 693 Note additional nuance about replies to malformed messages that 694 contain encryption in Section 6.2.2.1. 696 6. Message Interpretation 698 Despite the best efforts of well-intentioned senders to create e-mail 699 messages with well-formed end-to-end cryptographic protection, 700 receiving MUAs will inevitably encounter some messages with malformed 701 end-to-end cryptographic protection. 703 This section offers guidance on dealing with both well-formed and 704 malformed messages containing Cryptographic Layers. 706 6.1. Rendering Well-formed Messages 708 A message is well-formed when it has a Cryptographic Envelope, a 709 Cryptographic Payload, and no Errant Cryptographic Layers. Rendering 710 a well-formed message is straightforward. 712 The receiving MUA should evaluate and summarize the cryptographic 713 properties of the Cryptographic Envelope, and display that status to 714 the user in a secure, strictly-controlled part of the UI. In 715 particular, the part of the UI used to render the cryptographic 716 summary of the message MUST NOT be spoofable, modifiable, or 717 otherwise controllable by the received message itself. 719 Aside from this cryptographic summary, the message itself should be 720 rendered as though the Cryptographic Payload is the body of the 721 message. The Cryptographic Layers themselves SHOULD not be rendered 722 otherwise. 724 6.2. Errant Cryptographic Layers 726 If an incoming message has any Errant Cryptographic Layers, the 727 interpreting MUA SHOULD ignore those layers when rendering the 728 cryptographic summary of the message to the user. 730 6.2.1. Errant Signing Layer 732 When rendering a message with an Errant Cryptographic Layer that 733 provides authenticity and integrity (via signatures), the message 734 should be rendered by replacing the Cryptographic layer with the part 735 it encloses. 737 For example, a message with this structure: 739 A └┬╴multipart/mixed 740 B ├╴text/plain 741 C ├┬╴multipart/signed 742 D │├─╴image/jpeg 743 E │└─╴application/pgp-signature 744 F └─╴text/plain 746 Should be rendered identically to this: 748 A └┬╴multipart/mixed 749 B ├─╴text/plain 750 D ├─╴image/jpeg 751 F └─╴text/plain 752 In such a situation, an MUA SHOULD NOT indicate in the cryptographic 753 summary that the message is signed. 755 6.2.1.1. Exception: Mailing List Footers 757 The use case described in Section 4.5.1 is common enough in some 758 contexts, that a MUA MAY decide to handle it as a special exception. 760 If the MUA determines that the message comes from a mailing list (it 761 has a List-ID header), and it has a structure that appends a footer 762 to a signing-only Cryptographic Layer with a valid signature, such 763 as: 765 H └┬╴multipart/mixed 766 I ├┬╴multipart/signed 767 J │├─╴[protected part, may be arbitrary MIME subtree] 768 K │└─╴application/{pgp,pkcs7}-signature 769 L └─╴[footer, typically text/plain] 771 or: 773 H └┬╴multipart/mixed 774 I ├─╴application/pkcs7-mime; smime-type="signed-data" 775 │⇩ (unwraps to) 776 J │└─╴[protected part, may be an arbitrary MIME subtree] 777 L └─╴[footer, typically text/plain] 779 Then, the MUA MAY indicate to the user that this is a signed message 780 that has been wrapped by the mailing list. 782 In this case, the MUA MUST distinguish the footer (part L) from the 783 protected part (part J) when rendering any information about the 784 signature. 786 One way to do this is to offer the user two different views of the 787 message: the "mailing list" view, which hides any cryptographic 788 summary but shows the footer: 790 Cryptographic Protections: none 791 H └┬╴multipart/mixed 792 J ├─╴[protected part, may be arbitrary MIME subtree] 793 L └─╴[footer, typically text/plain] 795 or the "sender's view", which shows the cryptographic summary but 796 hides the footer: 798 Cryptographic Protections: signed [details from part I] 799 J └─╴[protected part, may be arbitrary MIME subtree] 801 6.2.2. Errant Encryption Layer 803 An MUA may encounter a message with an Errant Cryptographic Layer 804 that offers confidentiality (encryption), and the MUA is capable of 805 decrypting it. 807 The user wants to be able to see the contents of any message that 808 they receive, so an MUA in this situation SHOULD decrypt the part. 810 In this case, though, the MUA MUST NOT indicate in the message's 811 cryptographic summary that the message itself was encrypted. Such an 812 indication could be taken to mean that other (non-encrypted) parts of 813 the message arrived with cryptographic confidentiality. 815 6.2.2.1. Replying to a Message with an Errant Encryption Layer 817 Note that there is an asymmetry here between rendering and replying 818 to a message with an Errant Encryption Layer. 820 When rendering, the MUA does not indicate that the message was 821 encrypted, even if some subpart of it was decrypted for rendering. 823 But when composing a reply that contains quoted text from the 824 decrypted subpart, the reply message SHOULD be marked for encryption, 825 as noted in {#composing-reply}. 827 Alternately, if the reply message cannot be encrypted (or if the user 828 elects to not encrypt the reply), the composed reply MUST NOT include 829 any material from the decrypted subpart. 831 6.3. Forwarded Messages with Cryptographic Protection 833 An incoming e-mail message may include an attached forwarded message, 834 typically as a MIME subpart with Content-Type: message/rfc822 835 ([RFC5322]) or Content-Type: message/global ([RFC5355]). 837 Regardless of the cryptographic protections and structure of the 838 incoming message, the internal forwarded message may have its own 839 Cryptographic Envelope. 841 The Cryptographic Layers that are part of the Cryptographic Envelope 842 of the forwarded message are not Errant Cryptographic Layers of the 843 surrounding message -- they are simply layers that apply to the 844 forwarded message itself. 846 The rendering MUA MUST NOT conflate the cryptographic protections of 847 the forwarded message with the cryptographic protections of the 848 incoming message. 850 The rendering MUA MAY render a cryptograpic summary of the 851 protections afforded to the forwarded message by its own 852 Cryptographic Envelope, as long as that rendering is unambiguously 853 tied to the forwarded message itself. 855 6.4. Signature failures 857 A cryptographic signature may fail in multiple ways. A receiving MUA 858 that discovers a failed signature should treat the message as though 859 the signature did not exist. This is similar to the standard 860 guidance for about failed DKIM signatures (see section 6.1 of 861 [RFC6376]). 863 A MUA SHOULD NOT render a message with a failed signature as more 864 dangerous or more dubious than a comparable message without any 865 signature at all. 867 A MUA that encounters an encrypted-and-signed message where the 868 signature is invalid SHOULD treat the message the same way that it 869 would treat a message that is encryption-only. 871 Some different ways that a signature may be invalid on a given 872 message: 874 * the signature is not cryptographically valid (the math fails). 876 * the signature relies on suspect cryptographic primitives (e.g. 877 over a legacy digest algorithm, or was made by a weak key, e.g., 878 1024-bit R.SA) 880 * the signature is made by a certificate which the receiving MUA 881 does not have access to. 883 * the certificate that made the signature was revoked. 885 * the certificate that made the signature was expired at the time 886 that the signature was made. 888 * the certificate that made the signature does not correspond to the 889 author of the message. (for X.509, there is no subjectAltName of 890 type RFC822Name whose value matches an e-mail address found in 891 From: or Sender:) 893 * the certificate that made the signature was not issued by an 894 authority that the MUA user is willing to rely on for certifying 895 the sender's e-mail address. 897 * the signature indicates that it was made at a time much before or 898 much after from the date of the message itself. 900 A valid signature must pass all these tests, but of course invalid 901 signatures may be invalid in more than one of the ways listed above. 903 7. Reasoning about Message Parts 905 When generating or rendering messages, it is useful to know what 906 parts of the message are likely to be displayed, and how. This 907 section introduces some common terms that can be applied to parts 908 within the Cryptographic Payload. 910 7.1. Main Body Part 912 When an e-mail message is composed or rendered to the user there is 913 typically one main view that presents a (mostly textual) part of the 914 message. 916 While the message itself may be constructed of several distinct MIME 917 parts in a tree, but the part that is rendered to the user is the 918 "Main Body Part". 920 When rendering a message, one of the primary jobs of the recieving 921 MUA is identifying which part (or parts) is the Main Body Part. 922 Typically, this is found by traversing the MIME tree of the message 923 looking for a leaf node that has a primary content type of text (e.g. 924 text/plain or text/html) and is not Content-Disposition: attachment. 926 MIME tree traversal follows the first child of every multipart node, 927 with the exception of multipart/alternative. When traversing a 928 multipart/alternative node, all children should be scanned, with 929 preference given to the last child node with a MIME type that the MUA 930 is capable of rendering directly. 932 A MUA MAY offer the user a mechanism to prefer a particular MIME type 933 within multipart/alternative instead of the last renderable child. 934 For example, a user may explicitly prefer a text/plain alternative 935 part over text/html. 937 Note that due to uncertainty about the capabilities and configuration 938 of the receiving MUA, the composing MUA SHOULD consider that multiple 939 parts might be rendered as the Main Body Part when the message is 940 ultimately viewed. 942 When composing a message, an originating MUA operating on behalf of 943 an active user can identify which part (or parts) are the "main" 944 parts: these are the parts the MUA generates from the user's editor. 946 Tooling that automatically generates e-mail messages should also have 947 a reasonable estimate of which part (or parts) are the "main" parts, 948 as they can be programmatically identified by the message author. 950 For a filtering program that attempts to transform an outbound 951 message without any special knowledge about which parts are Main Body 952 Parts, it can identify the likely parts by following the same routine 953 as a receiving MUA. 955 7.2. Attachments 957 A message may contain one or more separated MIME parts that are 958 intended for download or extraction. Such a part is commonly called 959 an "attachment", and is commonly identified by having Content- 960 Disposition: attachment, and is a subpart of a multipart/mixed or 961 multipart/related container. 963 An MUA MAY identify a subpart as an attachment, or permit extraction 964 of a subpart even when the subpart does not have Content-Disposition: 965 attachment. 967 For end-to-end encrypted messages, attachments _MUST_ be included 968 within the Cryptographic Payload. If an attachment is found outside 969 the Cryptographic Payload, then the message is not well-formed (see 970 Section 6.1). 972 Some MUAs have tried to compose messages where each attachment is 973 placed in its own cryptographic envelope. Such a message is 974 problematic for several reasons: 976 * The attachments can be stripped, replaced, or reordered without 977 breaking any cryptographic integrity mechanism. 979 * The resulting message may have a mix of cryptographic statuses 980 (e.g. if a signature on one part fails but another succeeds, or if 981 one part is encrypted and another is not). This mix of statuses 982 is difficult to represent to the user in a comprehensible way. 984 7.3. MIME Part Examples 986 Consider a common message with the folloiwing MIME structure: 988 M └─╴application/pkcs7-mime 989 ↧ (decrypts to) 990 N └─╴application/pkcs7-mime 991 ⇩ (unwraps to) 992 O └┬╴multipart/mixed 993 P ├┬╴multipart/alternative 994 Q │├─╴text/plain 995 R │└─╴text/html 996 S └─╴image/png 998 Parts M and N comprise the Cryptographic Envelope. 1000 Parts Q and R are both Main Body Parts. 1002 If part S is Content-Disposition: attachment, then it is an 1003 attachment. If part S has no Content-Disposition header, it is 1004 potentially ambiguous whether it is an attachment or not. 1006 Consider also this alternate structure: 1008 M └─╴application/pkcs7-mime 1009 ↧ (decrypts to) 1010 N └─╴application/pkcs7-mime 1011 ⇩ (unwraps to) 1012 O └┬╴multipart/alternative 1013 P ├─╴text/plain 1014 Q └┬╴multipart/related 1015 R ├─╴text/html 1016 S └─╴image/png 1018 In this case, parts M and N are still the Cryptographic Envelope. 1020 Parts P and R (the first two leaf nodes within each subtree of part 1021 O) are the Main Body Parts. 1023 Part S is more likely not to be an attachment, as the subtree layout 1024 suggests that it is only relevant for the HTML version of the 1025 message. For example, it might be rendered as an image within the 1026 HTML alternative. 1028 8. Certificate Management 1030 A cryptographically-capable MUA typically maintains knowledge about 1031 certificates for the user's own account(s), as well as certificates 1032 for the peers that it communicates with. 1034 8.1. Peer Certificates 1036 Most certificates that a cryptographically-capable MUA will use will 1037 be certificates belonging to the parties that the user communicates 1038 with through the MUA. This section discusses how to manage the 1039 certificates that belong to such a peer. 1041 The MUA will need to be able to discover X.509 certificates for each 1042 peer, cache them, and select among them when composing an encrypted 1043 message. 1045 8.1.1. Cert Discovery from Incoming Messages 1047 TODO: incoming PKCS#7 messages tend to have a bundle of certificates 1048 in them. How should these certs be handled? 1050 TODO: point to Autocrypt certificate discovery mechanism 1052 TODO: point to OpenPGP embedded certificate subpacket proposal 1054 TODO: compare mechanisms, explain where each case is useful. 1056 8.1.2. Certificate Directories 1058 Some MUAs may have the capability to look up peer certificates in a 1059 directory. 1061 TODO: more information here about X.509 directories -- LDAP? 1063 TODO: mention WKD for OpenPGP certificates? 1065 8.1.3. Peer Certificate Selection 1067 When composing an encrypted message, the MUA needs to select a 1068 certificate for each recipient that is capable of encryption. 1070 To select such a certificate for a given destination e-mail address, 1071 the MUA should look through all of its known certificates and verify 1072 that _all_ of the conditions below are met: 1074 * The certificate must be valid, not expired or revoked. 1076 * It must have a subjectAltName of type rFC822Name whose contents 1077 exactly match the destination address. 1079 * The algorithm OID in the certificate's SPKI is known to the MUA 1080 and capable of encryption. Examples include (TODO: need OIDs) 1081 - RSA, with keyUsage present and the "key encipherment" bit set 1083 - EC Public Key, with keyUsage present and the "key agreement" 1084 bit set 1086 - EC DH, with keyUsage present and the "key agreement" bit set 1088 * If extendedKeyUsage is present, it contains at least one of the 1089 following OIDs: e-mail protection, anyExtendedKeyUsage. 1091 TODO: If OID is EC Public Key and keyUsage is absent, what should 1092 happen? 1094 TODO: what if multiple certificates meet all of these criteria for a 1095 given recipient? 1097 8.1.4. Checking for Revocation 1099 TODO: discuss how/when to check for peer certificate revocation 1101 TODO: privacy concerns: what information leaks to whom when checking 1102 peer cert revocations? 1104 8.2. Local Certificates 1106 The MUA also needs to know about one or more certificates associated 1107 with the user's e-mail account. It is typically expected to have 1108 access to the secret key material associated with the public keys in 1109 those certificates. 1111 8.2.1. Getting a Certificate for the User 1113 TODO: mention ACME SMIME? 1115 TODO: mention automatic self-signed certs e.g. OpenPGP? 1117 TODO: SHOULD generate secret key material locally, and MUST NOT 1118 accept secret key material from an untrusted third party as the basis 1119 for the user's certificate. 1121 8.2.2. Local Certificate Maintenance 1123 The MUA should warn the user when/if: 1125 * The user's own certificate set does not include a valid, unexpired 1126 encryption-capable X.509 certificate, and a valid, unexpired 1127 signature-capable X.509 certificate. 1129 * Any of the user's own certificates is due to expire soon (TODO: 1130 what is "soon"?) 1132 * Any of the user's own certificates does not match the e-mail 1133 address associated with the user's account. 1135 * Any of the user's own certificates does not have a keyUsage 1136 section 1138 * Any of the user's own certificates does not contain an 1139 extendedKeyUsage extension 1141 TODO: how does the MUA do better than warning in the cases above? 1142 What can the MUA actually _do_ here to fix problems before they 1143 happen? 1145 TODO: discuss how/when to check for own certificate revocation, and 1146 what to do if it (or any intermediate certificate authority) is found 1147 to be revoked. 1149 8.2.3. Shipping Certificates in Outbound Messages 1151 TODO: What certificates should the MUA include in an outbound message 1152 so that peers can discover them? 1154 * local signing certificate so that signature can be validated 1156 * local encryption-capable certificate(s) so that incoming messages 1157 can be encypted. 1159 * On an encrypted message to multiple recipients, the encryption- 1160 capable peer certs of the other recipients (to enable "reply 1161 all")? 1163 * intermediate certificates to chain all of the above to some set of 1164 root authorities? 1166 8.3. Certificate Authorities 1168 TODO: how should the MUA select root certificate authorities? 1170 TODO: should the MUA cache intermediate CAs? 1172 TODO: should the MUA share such a cache with other PKI clients (e.g., 1173 web browsers)? Are there distinctions between a CA for S/MIME and 1174 for the web? 1176 9. Common Pitfalls and Guidelines 1178 This section highlights a few "pitfalls" and guidelines based on 1179 these discussions and lessons learned. 1181 FIXME: some possible additional commentary on: 1183 * indexing and search of encrypted messages 1185 * managing access to cryptographic secret keys that require user 1186 interaction 1188 * secure deletion 1190 * inline PGP, ugh 1192 * storage of composed/sent messages 1194 * encrypt-to-self during composition 1196 * cached signature validation 1198 * interaction between encryption and Bcc 1200 * aggregated cryptographic status of threads/conversations ? 1202 * Draft messages 1204 * copies to the Sent folder 1206 10. IANA Considerations 1208 MAYBE: provide an indicator in the IANA header registry for which 1209 headers are "structural" and which are "user-facing"? This is 1210 probably unnecessary. 1212 11. Security Considerations 1214 This entire document addresses security considerations about end-to- 1215 end cryptographic protections for e-mail messages. 1217 12. Acknowledgements 1219 The set of constructs and recommendations in this document are 1220 derived from discussions with many different implementers, including 1221 Alexey Melnikov, Bernie Hoeneisen, Bjarni Runar Einarsson, David 1222 Bremner, Deb Cooley, Holger Krekel, Jameson Rollins, Jonathan 1223 Hammell, juga, Patrick Brunschwig, Santosh Chokhani, and Vincent 1224 Breitmoser. 1226 13. References 1228 13.1. Normative References 1230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1231 Requirement Levels", BCP 14, RFC 2119, 1232 DOI 10.17487/RFC2119, March 1997, 1233 . 1235 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1236 "MIME Security with OpenPGP", RFC 3156, 1237 DOI 10.17487/RFC3156, August 2001, 1238 . 1240 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 1241 Extensions (MIME) Part Four: Registration Procedures", 1242 BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005, 1243 . 1245 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1246 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1247 May 2017, . 1249 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1250 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1251 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1252 April 2019, . 1254 13.2. Informative References 1256 [chrome-indicators] 1257 Schechter, E., "Evolving Chrome's security indicators", 1258 May 2018, . 1261 [EFAIL] "EFAIL", n.d., . 1263 [I-D.draft-bre-openpgp-samples-01] 1264 Einarsson, B. R., "juga", and D. K. Gillmor, "OpenPGP 1265 Example Keys and Certificates", Work in Progress, 1266 Internet-Draft, draft-bre-openpgp-samples-01, 20 December 1267 2019, . 1270 [I-D.draft-ietf-lamps-samples-05] 1271 Gillmor, D. K., "S/MIME Example Keys and Certificates", 1272 Work in Progress, Internet-Draft, draft-ietf-lamps- 1273 samples-05, 5 August 2021, 1274 . 1277 [RFC3274] Gutmann, P., "Compressed Data Content Type for 1278 Cryptographic Message Syntax (CMS)", RFC 3274, 1279 DOI 10.17487/RFC3274, June 2002, 1280 . 1282 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1283 Thayer, "OpenPGP Message Format", RFC 4880, 1284 DOI 10.17487/RFC4880, November 2007, 1285 . 1287 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1288 DOI 10.17487/RFC5322, October 2008, 1289 . 1291 [RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Sengodan, S., 1292 and M. Holdrege, "Threats Introduced by Reliable Server 1293 Pooling (RSerPool) and Requirements for Security in 1294 Response to Threats", RFC 5355, DOI 10.17487/RFC5355, 1295 September 2008, . 1297 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1298 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1299 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1300 . 1302 Appendix A. Test Vectors 1304 FIXME: This document should contain examples of well-formed and 1305 malformed messages using cryptographic key material and certificates 1306 from [I-D.draft-bre-openpgp-samples-01] and 1307 [I-D.draft-ietf-lamps-samples-05]. 1309 It may also include example renderings of these messages. 1311 Appendix B. Document Considerations 1313 [ RFC Editor: please remove this section before publication ] 1315 This document is built from markdown using ruby-kramdown-rfc2629 1316 (https://rubygems.org/gems/kramdown-rfc2629), and tracked using git 1317 (https://git-scm.com/). The markdown source under development can be 1318 found in the file e2e-mail-guidance.md in the main branch of the git 1319 repository (https://gitlab.com/dkg/e2e-mail-guidance). 1321 You may also be interested in the latest editor's copy 1322 (https://dkg.gitlab.io/e2e-mail-guidance/). 1324 Minor editorial changes can be suggested via merge requests at 1325 https://gitlab.com/dkg/e2e-mail-guidance or by e-mail to the editor. 1326 Please direct all significant commentary to the public IETF LAMPS 1327 mailing list, spasm@ietf.org (https://www.ietf.org/mailman/listinfo/ 1328 spasm). 1330 B.1. Document History 1332 B.1.1. Substantive changes from draft-ietf-...-01 to draft-ietf-...-02 1334 * Added definition of "user-facing" headers 1336 B.1.2. Substantive changes from draft-ietf-...-00 to draft-ietf-...-01 1338 * Added section about distinguishing Main Body Parts and Attachments 1340 * Updated document considerations section, including reference to 1341 auto-built editor's copy 1343 B.1.3. Substantive changes from draft-dkg-...-01 to draft-ietf-...-00 1345 * WG adopted draft 1347 * moved Document History and Document Considerations sections to end 1348 of appendix, to avoid section renumbering when removed 1350 B.1.4. Substantive changes from draft-dkg-...-00 to draft-dkg-...-01 1352 * consideration of success/failure indicators for usability 1354 * clarify extendedKeyUsage and keyUsage algorithm-specific details 1356 * initial section on certificate management 1358 * added more TODO items 1360 Author's Address 1362 Daniel Kahn Gillmor (editor) 1363 American Civil Liberties Union 1364 125 Broad St. 1365 New York, NY, 10004 1366 United States of America 1368 Email: dkg@fifthhorseman.net