idnits 2.17.1 draft-ietf-lamps-e2e-mail-guidance-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 (24 January 2022) is 795 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 24 January 2022 5 Expires: 28 July 2022 7 Guidance on End-to-End E-mail Security 8 draft-ietf-lamps-e2e-mail-guidance-01 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 28 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 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. Reasoning about Message Parts . . . . . . . . . . . . . . . . 19 88 7.1. Main Body Part . . . . . . . . . . . . . . . . . . . . . 19 89 7.2. Attachments . . . . . . . . . . . . . . . . . . . . . . . 20 90 7.3. MIME Part Examples . . . . . . . . . . . . . . . . . . . 21 92 8. Certificate Management . . . . . . . . . . . . . . . . . . . 22 93 8.1. Peer Certificates . . . . . . . . . . . . . . . . . . . . 22 94 8.1.1. Cert Discovery from Incoming Messages . . . . . . . . 22 95 8.1.2. Certificate Directories . . . . . . . . . . . . . . . 22 96 8.1.3. Peer Certificate Selection . . . . . . . . . . . . . 22 97 8.1.4. Checking for Revocation . . . . . . . . . . . . . . . 23 98 8.2. Local Certificates . . . . . . . . . . . . . . . . . . . 23 99 8.2.1. Getting a Certificate for the User . . . . . . . . . 23 100 8.2.2. Local Certificate Maintenance . . . . . . . . . . . . 24 101 8.2.3. Shipping Certificates in Outbound Messages . . . . . 24 102 8.3. Certificate Authorities . . . . . . . . . . . . . . . . . 25 103 9. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 25 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 106 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 107 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 108 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 109 13.2. Informative References . . . . . . . . . . . . . . . . . 26 110 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 27 111 Appendix B. Document Considerations . . . . . . . . . . . . . . 28 112 B.1. Document History . . . . . . . . . . . . . . . . . . . . 28 113 B.1.1. Substantive changes from draft-ietf-...-00 to 114 draft-ietf-...-01 . . . . . . . . . . . . . . . . . . 28 115 B.1.2. Substantive changes from draft-dkg-...-01 to 116 draft-ietf-...-00 . . . . . . . . . . . . . . . . . . 28 117 B.1.3. Substantive changes from draft-dkg-...-00 to 118 draft-dkg-...-01 . . . . . . . . . . . . . . . . . . 28 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 121 1. Introduction 123 E-mail end-to-end security using S/MIME ([RFC8551]) and PGP/MIME 124 ([RFC3156]) cryptographic standards can provide integrity, 125 authentication and confidentiality to MIME ([RFC4289]) e-mail 126 messages. 128 However, there are many ways that a receiving mail user agent can 129 misinterpret or accidentally break these security guarantees (e.g., 130 [EFAIL]). 132 A mail user agent that interprets a message with end-to-end 133 cryptographic protections needs to do so defensively, staying alert 134 to different ways that these protections can be bypassed by mangling 135 (either malicious or accidental) or a failed user experience. 137 A mail user agent that generates a message with end-to-end 138 cryptographic protections should be aware of these defensive 139 interpretation strategies, and should compose any new outbound 140 message conservatively if they want the protections to remain intact. 142 1.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 ([RFC2119] and [RFC8174]) when, and only when, they appear in all 148 capitals, as shown here. 150 1.2. Terminology 152 For the purposes of this document, we define the following concepts: 154 * _MUA_ is short for Mail User Agent; an e-mail client. 156 * _Protection_ of message data refers to cryptographic encryption 157 and/or signatures, providing confidentiality, authenticity, and/or 158 integrity. 160 * _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic 161 Payload_, and _Errant Cryptographic Layer_ are defined in 162 Section 4 164 * A _well-formed_ e-mail message with cryptographic protection has 165 both a _Cryptographic Envelope_ and a _Cryptographic Payload_. 167 * _Structural Headers_ are documented in Section 1.2.1. 169 * _Main Body Part_ is the part (or parts) that are typically 170 rendered to the user as the message itself (not "as an 171 attachment). See Section 7.1. 173 1.2.1. Structural Headers 175 A message header whose name begins with Content- is referred to in 176 this document as a "structural" header. 178 These headers indicate something about the specific MIME part they 179 are attached to, and cannot be transferred or copied to other parts 180 without endangering the readability of the message. 182 This includes (but is not limited to): 184 * Content-Type 185 * Content-Transfer-Encoding 187 * Content-Disposition 189 FIXME: are there any non-Content-* headers we should consider as 190 structural? 192 2. Usability 194 Any MUA that enables its user to transition from unprotected messages 195 to messages with end-to-end cryptographic protection needs to 196 consider how the user understands this transition. That said, the 197 primary goal of the user of an MUA is communication -- so interface 198 elements that get in the way of communication should be avoided where 199 possible. 201 Furthermore, it is likely is that the user will continue to encounter 202 unprotected messages, and may need to send unprotected messages (for 203 example, if a given recipient cannot handle cryptographic 204 protections). This means that the MUA needs to provide the user with 205 some guidance, so that they understand what protections any given 206 message or conversation has. But the user should not be overwhelmed 207 with choices or presented with unactionable information. 209 2.1. Simplicity 211 The end user (the operator of the MUA) is unlikely to understand 212 complex end-to-end cryptographic protections on any e-mail message, 213 so keep it simple. 215 For clarity to the user, any cryptographic protections should apply 216 to the message as a whole, not just to some subparts. 218 This is true for message composition: the standard message 219 composition user interface of an MUA should offer minimal controls 220 which indicate which types of protection to apply to the new message 221 as a whole. 223 This is also true for message interpretation: the standard message 224 rendering user interface of an MUA should offer a minimal, clear 225 indicator about the end-to-end cryptographic status of the message as 226 a whole. 228 2.2. E-mail Users Want a Familiar Experience 230 A person communicating over the Internet today often has many options 231 for reaching their desired correspondent, including web-based 232 bulletin boards, contact forms, and instant messaging services. 234 E-mail offers a few distinctions from these other systems, most 235 notably features like: 237 * Ubiquity: Most correspondents will have an e-mail address, while 238 not everyone is present on every alternate messaging service, 240 * Federation: interaction between users on distinct domains who have 241 not agreed on a common communications provider is still possible, 242 and 244 * User Control: the user can interact with the e-mail system using a 245 MUA of their choosing, including automation and other control over 246 their preferred and/or customized workflow. 248 Other systems (like some popular instant messaging applications, such 249 as WhatsApp and Signal Private Messenger) offer built-in end-to-end 250 cryptographic protections by default, which are simpler for the user 251 to understand. ("All the messages I see on Signal are confidential 252 and integrity-protected" is a clean user story) 254 A user of e-mail is likely using e-mail instead of other systems 255 because of the distinctions outlined above. When adding end-to-end 256 cryptographic protection to an e-mail endpoint, care should be taken 257 not to negate any of the distinct features of e-mail as a whole. If 258 these features are violated to provide end-to-end crypto, the user 259 may just as well choose one of the other systems that don't have the 260 drawbacks that e-mail has. Implmenters should try to provide end-to- 261 end protections that retain the familiar experience of e-mail itself. 263 Furthermore, an e-mail user is likely to regularly interact with 264 other e-mail correspondents who _cannot_ handle or produce end-to-end 265 cryptographic protections. Care should be taken that enabling 266 cryptography in a MUA does not inadvertently limit the ability of the 267 user to interact with legacy correspondents. 269 2.3. Warning About Failure vs. Announcing Success 271 Moving the web from http to https offers useful historical 272 similarities to adding end-to-end encryption to e-mail. 274 In particular, the indicators of what is "secure" vs. "insecure" for 275 web browsers have changed over time. For example, years ago the 276 default experience was http, and https sites were flagged with 277 "secure" indicators like a lock icon. In 2018, some browsers 278 reversed that process by downplaying https, and instead visibly 279 marking http as "not secure" (see [chrome-indicators]). 281 By analogy, when the user of a MUA first enables end-to-end 282 cryptographic protection, it's likely that they will want to see 283 which messages _have_ protection. But a user whose e-mail 284 communications are entirely end-to-end protected might instead want 285 to know which messages do _not_ have the expected protections. 287 Note also that some messages are expected to be confidential, but 288 other messages are expected to be public -- the types of protection 289 (see Section 3) that apply to each particular message will be 290 different. And the types of protection that are _expected_ to be 291 present in any context might differ (for example, by sender, by 292 thread, or by date). 294 It is out of scope for this document to define expectations about 295 protections for any given message, but an implementer who cares about 296 usable experience should be deliberate and judicious about the 297 expectations their interface assumes that the user has in a given 298 context. 300 3. Types of Protection 302 A given message might be: 304 * signed, 306 * encrypted, 308 * both signed and encrypted, or 310 * none of the above. 312 Given that many e-mail messages offer no cryptographic protections, 313 the user needs to be able to detect which protections are present for 314 any given message. 316 4. Cryptographic MIME Message Structure 318 Implementations use the structure of an e-mail message to protect the 319 headers. This section establishes some conventions about how to 320 think about message structure. 322 4.1. Cryptographic Layers 324 "Cryptographic Layer" refers to a MIME substructure that supplies 325 some cryptographic protections to an internal MIME subtree. The 326 internal subtree is known as the "protected part" though of course it 327 may itself be a multipart object. 329 In the diagrams below, "↧" (DOWNWARDS ARROW FROM BAR, U+21A7) 330 indicates "decrypts to", and "⇩" (DOWNWARDS WHITE ARROW, U+21E9) 331 indicates "unwraps to". 333 4.1.1. S/MIME Cryptographic Layers 335 For S/MIME [RFC8551], there are four forms of Cryptographic Layers: 336 multipart/signed, PKCS#7 signed-data, PKCS7 enveloped-data, PKCS7 337 authEnveloped-data. 339 4.1.1.1. S/MIME Multipart Signed Cryptographic Layer 341 └┬╴multipart/signed; protocol="application/pkcs7-signature" 342 ├─╴[protected part] 343 └─╴application/pkcs7-signature 345 This MIME layer offers authentication and integrity. 347 4.1.1.2. S/MIME PKCS7 signed-data Cryptographic Layer 349 └─╴application/pkcs7-mime; smime-type="signed-data" 350 ⇩ (unwraps to) 351 └─╴[protected part] 353 This MIME layer offers authentication and integrity. 355 4.1.1.3. S/MIME PKCS7 enveloped-data Cryptographic Layer 357 └─╴application/pkcs7-mime; smime-type="enveloped-data" 358 ↧ (decrypts to) 359 └─╴[protected part] 361 This MIME layer offers confidentiality. 363 4.1.1.4. S/MIME PKCS7 authEnveloped-data Cryptographic Layer 365 └─╴application/pkcs7-mime; smime-type="authEnveloped-data" 366 ↧ (decrypts to) 367 └─╴[protected part] 369 This MIME layer offers confidentiality and integrity. 371 Note that enveloped-data (Section 4.1.1.3) and authEnveloped-data 372 (Section 4.1.1.4) have identical message structure and semantics. 373 The only difference between the two is ciphertext malleability. 375 The examples in this document only include enveloped-data, but the 376 implications for that layer apply to authEnveloped-data as well. 378 4.1.1.5. PKCS7 Compression is NOT a Cryptographic Layer 380 The Cryptographic Message Syntax (CMS) provides a MIME compression 381 layer (smime-type="compressed-data"), as defined in [RFC3274]. While 382 the compression layer is technically a part of CMS, it is not 383 considered a Cryptographic Layer for the purposes of this document. 385 4.1.2. PGP/MIME Cryptographic Layers 387 For PGP/MIME [RFC3156] there are two forms of Cryptographic Layers, 388 signing and encryption. 390 4.1.2.1. PGP/MIME Signing Cryptographic Layer (multipart/signed) 392 └┬╴multipart/signed; protocol="application/pgp-signature" 393 ├─╴[protected part] 394 └─╴application/pgp-signature 396 This MIME layer offers authenticity and integrity. 398 4.1.2.2. PGP/MIME Encryption Cryptographic Layer (multipart/encrypted) 400 └┬╴multipart/encrypted 401 ├─╴application/pgp-encrypted 402 └─╴application/octet-stream 403 ↧ (decrypts to) 404 └─╴[protected part] 406 This MIME layer can offer any of: 408 * confidentiality (via a Symmetrically Encrypted Data Packet, see 409 Section 5.7 of [RFC4880]; a MUA MUST NOT generate this form due to 410 ciphertext malleability) 412 * confidentiality and integrity (via a Symmetrically Encrypted 413 Integrity Protected Data Packet (SEIPD), see section 5.13 of 414 [RFC4880]), or 416 * confidentiality, integrity, and authenticity all together (by 417 including an OpenPGP Signature Packet within the SEIPD). 419 4.2. Cryptographic Envelope 421 The Cryptographic Envelope is the largest contiguous set of 422 Cryptographic Layers of an e-mail message starting with the outermost 423 MIME type (that is, with the Content-Type of the message itself). 425 If the Content-Type of the message itself is not a Cryptographic 426 Layer, then the message has no cryptographic envelope. 428 "Contiguous" in the definition above indicates that if a 429 Cryptographic Layer is the protected part of another Cryptographic 430 Layer, the layers together comprise a single Cryptographic Envelope. 432 Note that if a non-Cryptographic Layer intervenes, all Cryptographic 433 Layers within the non-Cryptographic Layer _are not_ part of the 434 Cryptographic Envelope. They are Errant Cryptographic Layers (see 435 Section 4.5). 437 Note also that the ordering of the Cryptographic Layers implies 438 different cryptographic properties. A signed-then-encrypted message 439 is different than an encrypted-then-signed message. See Section 5.2. 441 4.3. Cryptographic Payload 443 The Cryptographic Payload of a message is the first non-Cryptographic 444 Layer -- the "protected part" -- within the Cryptographic Envelope. 446 4.4. Types of Cryptographic Envelope 448 4.4.1. Simple Cryptographic Envelopes 450 As described above, if the "protected part" identified in the sction 451 above is not itself a Cryptographic Layer, that part _is_ the 452 Cryptographic Payload. 454 If the application wants to generate a message that is both encrypted 455 and signed, it MAY use the simple MIME structure from Section 4.1.2.2 456 by ensuring that the [RFC4880] Encrypted Message within the 457 application/octet-stream part contains an [RFC4880] Signed Message 458 (the final option described in Section 4.1.2.2. 460 4.4.2. Multilayer Cryptographic Envelopes 462 It is possible to construct a Cryptographic Envelope consisting of 463 multiple layers with either S/MIME or PGP/MIME , for example using 464 the following structure: 466 A └─╴application/pkcs7-mime; smime-type="enveloped-data" 467 B ↧ (decrypts to) 468 C └─╴application/pkcs7-mime; smime-type="signed-data" 469 D ⇩ (unwraps to) 470 E └─╴[protected part] 471 When handling such a message, the properties of the Cryptographic 472 Envelope are derived from the series A, C. 474 As noted in Section 4.4.1, PGP/MIME applications also have a simpler 475 MIME construction available with the same cryptographic properties. 477 4.5. Errant Crytptographic Layers 479 Due to confusion, malice, or well-intentioned tampering, a message 480 may contain a Cryptographic Layer that is not part of the 481 Cryptographic Envelope. Such a layer is an Errant Cryptographic 482 Layer. 484 An Errant Cryptographic Layer SHOULD NOT contribute to the message's 485 overall cryptographic state. 487 Guidance for dealing with Errant Cryptographic Layers can be found in 488 Section 6.2. 490 4.5.1. Mailing List Wrapping 492 Some mailing list software will re-wrap a well-formed signed message 493 before re-sending to add a footer, resulting in the following 494 structure seen by recipients of the e-mail: 496 H └┬╴multipart/mixed 497 I ├┬╴multipart/signed 498 J │├─╴text/plain 499 K │└─╴application/pgp-signature 500 L └─╴text/plain 502 In this message, L is the footer added by the mailing list. I is now 503 an Errant Cryptographic Layer. 505 Note that this message has no Cryptographic Envelope at all. 507 It is NOT RECOMMENDED to produce e-mail messages with this structure, 508 because the data in part L may appear to the user as though it were 509 part of J, though they have different cryptographic properties. In 510 particular, if the user believes that the message is signed, but 511 cannot distinguish L from J then the author of L can effectively 512 tamper with content of the signed message, breaking the user's 513 expectation of integrity and authenticity. 515 4.5.2. A Baroque Example 517 Consider a message with the following overcomplicated structure: 519 M └┬╴multipart/encrypted 520 N ├─╴application/pgp-encrypted 521 O └─╴application/octet-stream 522 P ↧ (decrypts to) 523 Q └┬╴multipart/signed 524 R ├┬╴multipart/mixed 525 S │├┬╴multipart/signed 526 T ││├─╴text/plain 527 U ││└─╴application/pgp-signature 528 V │└─╴text/plain 529 W └─╴application/pgp-signature 531 The 3 Cryptographic Layers in such a message are rooted in parts M, 532 Q, and S. But the Cryptographic Envelope of the message consists 533 only of the properties derived from the series M, Q. The 534 Cryptographic Payload of the message is part R. Part S is an Errant 535 Cryptographic Layer. 537 Note that this message has both a Cryptographic Envelope _and_ an 538 Errant Cryptographic Layer. 540 It is NOT RECOMMENDED to generate messages with such complicated 541 structures. Even if a receiving MUA can parse this structure 542 properly, it is nearly impossible to render in a way that the user 543 can reason about the cryptographic properties of part T compared to 544 part V. 546 5. Message Composition 548 This section describes the ideal composition of an e-mail message 549 with end-to-end cryptographic protection. A message composed with 550 this form is most likely to achieve its end-to-end security goals. 552 5.1. Message Composition Algorithm 554 This section roughly describes the steps that a MUA should use to 555 compose a cryptographically-protected message that has a proper 556 cryptographic envelope and payload. 558 The message composition algorithm takes three parameters: 560 * origbody: the traditional unprotected message body as a well- 561 formed MIME tree (possibly just a single MIME leaf part). As a 562 well-formed MIME tree, origbody already has structural headers 563 present (see Section 1.2.1). 565 * origheaders: the intended non-structural headers for the message, 566 represented here as a list of (h,v) pairs, where h is a header 567 field name and v is the associated value. 569 * crypto: The series of cryptographic protections to apply (for 570 example, "sign with the secret key corresponding to X.509 571 certificate X, then encrypt to X.509 certificates X and Y"). This 572 is a routine that accepts a MIME tree as input (the Cryptographic 573 Payload), wraps the input in the appropriate Cryptographic 574 Envelope, and returns the resultant MIME tree as output. 576 The algorithm returns a MIME object that is ready to be injected into 577 the mail system: 579 * Apply crypto to origbody, yielding MIME tree output 581 * For each header name and value (h,v) in origheaders: 583 - Add header h of output with value v 585 * Return output 587 5.2. Encryption Outside, Signature Inside 589 Users expect any message that is both signed and encrypted to be 590 signed _inside_ the encryption, and not the other way around. 592 Putting the signature inside the encryption has two advantages: 594 * The details of the signature remain confidential, visible only to 595 the parties capable of decryption. 597 * Any mail transport agent that modifies the message is unlikely to 598 be able to accidentally break the signature. 600 A MUA SHOULD NOT generate an encrypted and signed message where the 601 only signature is outside the encryption. 603 5.3. Avoid Offering Encrypted-only Messages 605 When generating an e-mail, the user has options about what forms of 606 end-to-end cryptographic protections to apply to it. 608 In some cases, offering any end-to-end cryptographic protection is 609 harmful: it may confuse the recipient and offer no benefit. 611 In other cases, signing a message is useful (authenticity and 612 integrity are desirable) but encryption is either impossible (for 613 example, if the sender does not know how to encrypt to all 614 recipients) or meaningless (for example, an e-mail message to a 615 mailing list that is intended to be be published to a public 616 archive). 618 In other cases, full end-to-end confidentiality, authenticity, and 619 integrity are desirable. 621 It is unclear what the use case is for an e-mail message with end-to- 622 end confidentiality but without authenticity or integrity. 624 A reasonable MUA will keep its message composition interface simple, 625 so when presenting the user with a choice of cryptographic 626 protection, it SHOULD offer no more than three choices: 628 * no end-to-end cryptographic protection 630 * signing-only 632 * signed and encrypted 634 5.4. Composing a Reply Message 636 When replying to a message, most MUAs compose an initial draft of the 637 reply that contains quoted text from the original message. A 638 responsible MUA will take precautions to avoid leaking the cleartext 639 of an encrypted message in such a reply. 641 If the original message was end-to-end encrypted, the replying MUA 642 MUST either: 644 * compose the reply with end-to-end encryption, or 646 * avoid including quoted text from the original message. 648 In general, MUAs SHOULD prefer the first option: to compose an 649 encrypted reply. This is what users expect. 651 However, in some circumstances, the replying MUA cannot compose an 652 encrypted reply. For example, the MUA might not have a valid, 653 unexpired, encryption-capable certificate for all recipients. This 654 can also happen during composition when a user adds a new recipient 655 into the reply, or manually toggles the cryptographic protections to 656 remove encryption. 658 In this circumstance, the composing MUA SHOULD strip the quoted text 659 from the original message. 661 Note additional nuance about replies to malformed messages that 662 contain encryption in Section 6.2.2.1. 664 6. Message Interpretation 666 Despite the best efforts of well-intentioned senders to create e-mail 667 messages with well-formed end-to-end cryptographic protection, 668 receiving MUAs will inevitably encounter some messages with malformed 669 end-to-end cryptographic protection. 671 This section offers guidance on dealing with both well-formed and 672 malformed messages containing Cryptographic Layers. 674 6.1. Rendering Well-formed Messages 676 A message is well-formed when it has a Cryptographic Envelope, a 677 Cryptographic Payload, and no Errant Cryptographic Layers. Rendering 678 a well-formed message is straightforward. 680 The receiving MUA should evaluate and summarize the cryptographic 681 properties of the Cryptographic Envelope, and display that status to 682 the user in a secure, strictly-controlled part of the UI. In 683 particular, the part of the UI used to render the cryptographic 684 summary of the message MUST NOT be spoofable, modifiable, or 685 otherwise controllable by the received message itself. 687 Aside from this cryptographic summary, the message itself should be 688 rendered as though the Cryptographic Payload is the body of the 689 message. The Cryptographic Layers themselves SHOULD not be rendered 690 otherwise. 692 6.2. Errant Cryptographic Layers 694 If an incoming message has any Errant Cryptographic Layers, the 695 interpreting MUA SHOULD ignore those layers when rendering the 696 cryptographic summary of the message to the user. 698 6.2.1. Errant Signing Layer 700 When rendering a message with an Errant Cryptographic Layer that 701 provides authenticity and integrity (via signatures), the message 702 should be rendered by replacing the Cryptographic layer with the part 703 it encloses. 705 For example, a message with this structure: 707 A └┬╴multipart/mixed 708 B ├╴text/plain 709 C ├┬╴multipart/signed 710 D │├─╴image/jpeg 711 E │└─╴application/pgp-signature 712 F └─╴text/plain 714 Should be rendered identically to this: 716 A └┬╴multipart/mixed 717 B ├─╴text/plain 718 D ├─╴image/jpeg 719 F └─╴text/plain 721 In such a situation, an MUA SHOULD NOT indicate in the cryptographic 722 summary that the message is signed. 724 6.2.1.1. Exception: Mailing List Footers 726 The use case described in Section 4.5.1 is common enough in some 727 contexts, that a MUA MAY decide to handle it as a special exception. 729 If the MUA determines that the message comes from a mailing list (it 730 has a List-ID header), and it has a structure that appends a footer 731 to a signing-only Cryptographic Layer with a valid signature, such 732 as: 734 H └┬╴multipart/mixed 735 I ├┬╴multipart/signed 736 J │├─╴[protected part, may be arbitrary MIME subtree] 737 K │└─╴application/{pgp,pkcs7}-signature 738 L └─╴[footer, typically text/plain] 740 or: 742 H └┬╴multipart/mixed 743 I ├─╴application/pkcs7-mime; smime-type="signed-data" 744 │⇩ (unwraps to) 745 J │└─╴[protected part, may be an arbitrary MIME subtree] 746 L └─╴[footer, typically text/plain] 748 Then, the MUA MAY indicate to the user that this is a signed message 749 that has been wrapped by the mailing list. 751 In this case, the MUA MUST distinguish the footer (part L) from the 752 protected part (part J) when rendering any information about the 753 signature. 755 One way to do this is to offer the user two different views of the 756 message: the "mailing list" view, which hides any cryptographic 757 summary but shows the footer: 759 Cryptographic Protections: none 760 H └┬╴multipart/mixed 761 J ├─╴[protected part, may be arbitrary MIME subtree] 762 L └─╴[footer, typically text/plain] 764 or the "sender's view", which shows the cryptographic summary but 765 hides the footer: 767 Cryptographic Protections: signed [details from part I] 768 J └─╴[protected part, may be arbitrary MIME subtree] 770 6.2.2. Errant Encryption Layer 772 An MUA may encounter a message with an Errant Cryptographic Layer 773 that offers confidentiality (encryption), and the MUA is capable of 774 decrypting it. 776 The user wants to be able to see the contents of any message that 777 they receive, so an MUA in this situation SHOULD decrypt the part. 779 In this case, though, the MUA MUST NOT indicate in the message's 780 cryptographic summary that the message itself was encrypted. Such an 781 indication could be taken to mean that other (non-encrypted) parts of 782 the message arrived with cryptographic confidentiality. 784 6.2.2.1. Replying to a Message with an Errant Encryption Layer 786 Note that there is an asymmetry here between rendering and replying 787 to a message with an Errant Encryption Layer. 789 When rendering, the MUA does not indicate that the message was 790 encrypted, even if some subpart of it was decrypted for rendering. 792 But when composing a reply that contains quoted text from the 793 decrypted subpart, the reply message SHOULD be marked for encryption, 794 as noted in {#composing-reply}. 796 Alternately, if the reply message cannot be encrypted (or if the user 797 elects to not encrypt the reply), the composed reply MUST NOT include 798 any material from the decrypted subpart. 800 6.3. Forwarded Messages with Cryptographic Protection 802 An incoming e-mail message may include an attached forwarded message, 803 typically as a MIME subpart with Content-Type: message/rfc822 804 ([RFC5322]) or Content-Type: message/global ([RFC5355]). 806 Regardless of the cryptographic protections and structure of the 807 incoming message, the internal forwarded message may have its own 808 Cryptographic Envelope. 810 The Cryptographic Layers that are part of the Cryptographic Envelope 811 of the forwarded message are not Errant Cryptographic Layers of the 812 surrounding message -- they are simply layers that apply to the 813 forwarded message itself. 815 The rendering MUA MUST NOT conflate the cryptographic protections of 816 the forwarded message with the cryptographic protections of the 817 incoming message. 819 The rendering MUA MAY render a cryptograpic summary of the 820 protections afforded to the forwarded message by its own 821 Cryptographic Envelope, as long as that rendering is unambiguously 822 tied to the forwarded message itself. 824 6.4. Signature failures 826 A cryptographic signature may fail in multiple ways. A receiving MUA 827 that discovers a failed signature should treat the message as though 828 the signature did not exist. This is similar to the standard 829 guidance for about failed DKIM signatures (see section 6.1 of 830 [RFC6376]). 832 A MUA SHOULD NOT render a message with a failed signature as more 833 dangerous or more dubious than a comparable message without any 834 signature at all. 836 A MUA that encounters an encrypted-and-signed message where the 837 signature is invalid SHOULD treat the message the same way that it 838 would treat a message that is encryption-only. 840 Some different ways that a signature may be invalid on a given 841 message: 843 * the signature is not cryptographically valid (the math fails). 845 * the signature relies on suspect cryptographic primitives (e.g. 846 over a legacy digest algorithm, or was made by a weak key, e.g., 847 1024-bit R.SA) 849 * the signature is made by a certificate which the receiving MUA 850 does not have access to. 852 * the certificate that made the signature was revoked. 854 * the certificate that made the signature was expired at the time 855 that the signature was made. 857 * the certificate that made the signature does not correspond to the 858 author of the message. (for X.509, there is no subjectAltName of 859 type RFC822Name whose value matches an e-mail address found in 860 From: or Sender:) 862 * the certificate that made the signature was not issued by an 863 authority that the MUA user is willing to rely on for certifying 864 the sender's e-mail address. 866 * the signature indicates that it was made at a time much before or 867 much after from the date of the message itself. 869 A valid signature must pass all these tests, but of course invalid 870 signatures may be invalid in more than one of the ways listed above. 872 7. Reasoning about Message Parts 874 When generating or rendering messages, it is useful to know what 875 parts of the message are likely to be displayed, and how. This 876 section introduces some common terms that can be applied to parts 877 within the Cryptographic Payload. 879 7.1. Main Body Part 881 When an e-mail message is composed or rendered to the user there is 882 typically one main view that presents a (mostly textual) part of the 883 message. 885 While the message itself may be constructed of several distinct MIME 886 parts in a tree, but the part that is rendered to the user is the 887 "Main Body Part". 889 When rendering a message, one of the primary jobs of the recieving 890 MUA is identifying which part (or parts) is the Main Body Part. 891 Typically, this is found by traversing the MIME tree of the message 892 looking for a leaf node that has a primary content type of text (e.g. 893 text/plain or text/html) and is not Content-Disposition: attachment. 894 MIME tree traversal follows the first child of every multipart node, 895 with the exception of multipart/alternative. When traversing a 896 multipart/alternative node, all children should be scanned, with 897 preference given to the last child node with a MIME type that the MUA 898 is capable of rendering directly. A MUA MAY offer the user a 899 mechanism to prefer a particular MIME type within multipart/ 900 alternative instead of the last renderable child. For example, a 901 user may explicitly prefer a text/plain alternative part over text/ 902 html. 904 Note that due to uncertainty about the capabilities and configuration 905 of the receiving MUA, the composing MUA SHOULD consider that multiple 906 parts might be rendered as the Main Body Part when the message is 907 ultimately viewed. 909 When composing a message, an originating MUA operating on behalf of 910 an active user can identify which part (or parts) are the "main" 911 parts: these are the parts the MUA generates from the user's editor. 912 Tooling that automatically generates e-mail messages should also have 913 a reasonable estimate of which part (or parts) are the "main" parts, 914 as they can be programmatically identified by the message author. 916 For a filtering program that attempts to transform an outbound 917 message without any special knowledge about which parts are Main Body 918 Parts, it can identify the likely parts by following the same routine 919 as a receiving MUA. 921 7.2. Attachments 923 A message may contain one or more separated MIME parts that are 924 intended for download or extraction. Such a part is commonly called 925 an "attachment", and is commonly identified by having Content- 926 Disposition: attachment, and is a subpart of a multipart/mixed or 927 multipart/related container. 929 An MUA MAY identify a subpart as an attachment, or permit extraction 930 of a subpart even when the subpart does not have Content-Disposition: 931 attachment. 933 For end-to-end encrypted messages, attachments _MUST_ be included 934 within the Cryptographic Payload. If an attachment is found outside 935 the Cryptographic Payload, then the message is not well-formed (see 936 Section 6.1). 938 Some MUAs have tried to compose messages where each attachment is 939 placed in its own cryptographic envelope. Such a message is 940 problematic for several reasons: 942 * The attachments can be stripped, replaced, or reordered without 943 breaking any cryptographic integrity mechanism. 945 * The resulting message may have a mix of cryptographic statuses 946 (e.g. if a signature on one part fails but another succeeds, or if 947 one part is encrypted and another is not). This mix of statuses 948 is difficult to represent to the user in a comprehensible way. 950 7.3. MIME Part Examples 952 Consider a common message with the folloiwing MIME structure: 954 M └─╴application/pkcs7-mime 955 ↧ (decrypts to) 956 N └─╴application/pkcs7-mime 957 ⇩ (unwraps to) 958 O └┬╴multipart/mixed 959 P ├┬╴multipart/alternative 960 Q │├─╴text/plain 961 R │└─╴text/html 962 S └─╴image/png 964 Parts M and N comprise the Cryptographic Envelope. 966 Parts Q and R are both Main Body Parts. 968 If part S is Content-Disposition: attachment, then it is an 969 attachment. If part S has no Content-Disposition header, it is 970 potentially ambiguous whether it is an attachment or not. 972 Consider also this alternate structure: 974 M └─╴application/pkcs7-mime 975 ↧ (decrypts to) 976 N └─╴application/pkcs7-mime 977 ⇩ (unwraps to) 978 O └┬╴multipart/alternative 979 P ├─╴text/plain 980 Q └┬╴multipart/related 981 R ├─╴text/html 982 S └─╴image/png 984 In this case, parts M and N are still the Cryptographic Envelope. 986 Parts P and R (the first two leaf nodes within each subtree of part 987 O) are the Main Body Parts. 989 Part S is more likely not to be an attachment, as the subtree layout 990 suggests that it is only relevant for the HTML version of the 991 message. For example, it might be rendered as an image within the 992 HTML alternative. 994 8. Certificate Management 996 A cryptographically-capable MUA typically maintains knowledge about 997 certificates for the user's own account(s), as well as certificates 998 for the peers that it communicates with. 1000 8.1. Peer Certificates 1002 Most certificates that a cryptographically-capable MUA will use will 1003 be certificates belonging to the parties that the user communicates 1004 with through the MUA. This section discusses how to manage the 1005 certificates that belong to such a peer. 1007 The MUA will need to be able to discover X.509 certificates for each 1008 peer, cache them, and select among them when composing an encrypted 1009 message. 1011 8.1.1. Cert Discovery from Incoming Messages 1013 TODO: incoming PKCS#7 messages tend to have a bundle of certificates 1014 in them. How should these certs be handled? 1016 TODO: point to Autocrypt certificate discovery mechanism 1018 TODO: point to OpenPGP embedded certificate subpacket proposal 1020 TODO: compare mechanisms, explain where each case is useful. 1022 8.1.2. Certificate Directories 1024 Some MUAs may have the capability to look up peer certificates in a 1025 directory. 1027 TODO: more information here about X.509 directories -- LDAP? 1029 TODO: mention WKD for OpenPGP certificates? 1031 8.1.3. Peer Certificate Selection 1033 When composing an encrypted message, the MUA needs to select a 1034 certificate for each recipient that is capable of encryption. 1036 To select such a certificate for a given destination e-mail address, 1037 the MUA should look through all of its known certificates and verify 1038 that _all_ of the conditions below are met: 1040 * The certificate must be valid, not expired or revoked. 1042 * It must have a subjectAltName of type rFC822Name whose contents 1043 exactly match the destination address. 1045 * The algorithm OID in the certificate's SPKI is known to the MUA 1046 and capable of encryption. Examples include (TODO: need OIDs) 1048 - RSA, with keyUsage present and the "key encipherment" bit set 1050 - EC Public Key, with keyUsage present and the "key agreement" 1051 bit set 1053 - EC DH, with keyUsage present and the "key agreement" bit set 1055 * If extendedKeyUsage is present, it contains at least one of the 1056 following OIDs: e-mail protection, anyExtendedKeyUsage. 1058 TODO: If OID is EC Public Key and keyUsage is absent, what should 1059 happen? 1061 TODO: what if multiple certificates meet all of these criteria for a 1062 given recipient? 1064 8.1.4. Checking for Revocation 1066 TODO: discuss how/when to check for peer certificate revocation 1068 TODO: privacy concerns: what information leaks to whom when checking 1069 peer cert revocations? 1071 8.2. Local Certificates 1073 The MUA also needs to know about one or more certificates associated 1074 with the user's e-mail account. It is typically expected to have 1075 access to the secret key material associated with the public keys in 1076 those certificates. 1078 8.2.1. Getting a Certificate for the User 1080 TODO: mention ACME SMIME? 1082 TODO: mention automatic self-signed certs e.g. OpenPGP? 1084 TODO: SHOULD generate secret key material locally, and MUST NOT 1085 accept secret key material from an untrusted third party as the basis 1086 for the user's certificate. 1088 8.2.2. Local Certificate Maintenance 1090 The MUA should warn the user when/if: 1092 * The user's own certificate set does not include a valid, unexpired 1093 encryption-capable X.509 certificate, and a valid, unexpired 1094 signature-capable X.509 certificate. 1096 * Any of the user's own certificates is due to expire soon (TODO: 1097 what is "soon"?) 1099 * Any of the user's own certificates does not match the e-mail 1100 address associated with the user's account. 1102 * Any of the user's own certificates does not have a keyUsage 1103 section 1105 * Any of the user's own certificates does not contain an 1106 extendedKeyUsage extension 1108 TODO: how does the MUA do better than warning in the cases above? 1109 What can the MUA actually _do_ here to fix problems before they 1110 happen? 1112 TODO: discuss how/when to check for own certificate revocation, and 1113 what to do if it (or any intermediate certificate authority) is found 1114 to be revoked. 1116 8.2.3. Shipping Certificates in Outbound Messages 1118 TODO: What certificates should the MUA include in an outbound message 1119 so that peers can discover them? 1121 * local signing certificate so that signature can be validated 1123 * local encryption-capable certificate(s) so that incoming messages 1124 can be encypted. 1126 * On an encrypted message to multiple recipients, the encryption- 1127 capable peer certs of the other recipients (to enable "reply 1128 all")? 1130 * intermediate certificates to chain all of the above to some set of 1131 root authorities? 1133 8.3. Certificate Authorities 1135 TODO: how should the MUA select root certificate authorities? 1137 TODO: should the MUA cache intermediate CAs? 1139 TODO: should the MUA share such a cache with other PKI clients (e.g., 1140 web browsers)? Are there distinctions between a CA for S/MIME and 1141 for the web? 1143 9. Common Pitfalls and Guidelines 1145 This section highlights a few "pitfalls" and guidelines based on 1146 these discussions and lessons learned. 1148 FIXME: some possible additional commentary on: 1150 * indexing and search of encrypted messages 1152 * managing access to cryptographic secret keys that require user 1153 interaction 1155 * secure deletion 1157 * inline PGP, ugh 1159 * storage of composed/sent messages 1161 * encrypt-to-self during composition 1163 * cached signature validation 1165 * interaction between encryption and Bcc 1167 * aggregated cryptographic status of threads/conversations ? 1169 * Draft messages 1171 * copies to the Sent folder 1173 10. IANA Considerations 1175 MAYBE: provide an indicator in the IANA header registry for which 1176 headers are "structural" ? This is probably unnecessary. 1178 11. Security Considerations 1180 This entire document addresses security considerations about end-to- 1181 end cryptographic protections for e-mail messages. 1183 12. Acknowledgements 1185 The set of constructs and recommendations in this document are 1186 derived from discussions with many different implementers, including 1187 Alexey Melnikov, Bernie Hoeneisen, Bjarni Runar Einarsson, David 1188 Bremner, Deb Cooley, Holger Krekel, Jameson Rollins, Jonathan 1189 Hammell, juga, Patrick Brunschwig, Santosh Chokhani, and Vincent 1190 Breitmoser. 1192 13. References 1194 13.1. Normative References 1196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1197 Requirement Levels", BCP 14, RFC 2119, 1198 DOI 10.17487/RFC2119, March 1997, 1199 . 1201 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1202 "MIME Security with OpenPGP", RFC 3156, 1203 DOI 10.17487/RFC3156, August 2001, 1204 . 1206 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 1207 Extensions (MIME) Part Four: Registration Procedures", 1208 BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005, 1209 . 1211 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1212 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1213 May 2017, . 1215 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1216 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1217 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 1218 April 2019, . 1220 13.2. Informative References 1222 [chrome-indicators] 1223 Schechter, E., "Evolving Chrome's security indicators", 1224 May 2018, . 1227 [EFAIL] "EFAIL", n.d., . 1229 [I-D.draft-bre-openpgp-samples-01] 1230 Einarsson, B. R., "juga", and D. K. Gillmor, "OpenPGP 1231 Example Keys and Certificates", Work in Progress, 1232 Internet-Draft, draft-bre-openpgp-samples-01, 20 December 1233 2019, . 1236 [I-D.draft-ietf-lamps-samples-05] 1237 Gillmor, D. K., "S/MIME Example Keys and Certificates", 1238 Work in Progress, Internet-Draft, draft-ietf-lamps- 1239 samples-05, 5 August 2021, 1240 . 1243 [RFC3274] Gutmann, P., "Compressed Data Content Type for 1244 Cryptographic Message Syntax (CMS)", RFC 3274, 1245 DOI 10.17487/RFC3274, June 2002, 1246 . 1248 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1249 Thayer, "OpenPGP Message Format", RFC 4880, 1250 DOI 10.17487/RFC4880, November 2007, 1251 . 1253 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1254 DOI 10.17487/RFC5322, October 2008, 1255 . 1257 [RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Sengodan, S., 1258 and M. Holdrege, "Threats Introduced by Reliable Server 1259 Pooling (RSerPool) and Requirements for Security in 1260 Response to Threats", RFC 5355, DOI 10.17487/RFC5355, 1261 September 2008, . 1263 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1264 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1265 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1266 . 1268 Appendix A. Test Vectors 1270 FIXME: This document should contain examples of well-formed and 1271 malformed messages using cryptographic key material and certificates 1272 from [I-D.draft-bre-openpgp-samples-01] and 1273 [I-D.draft-ietf-lamps-samples-05]. 1275 It may also include example renderings of these messages. 1277 Appendix B. Document Considerations 1279 [ RFC Editor: please remove this section before publication ] 1281 This document is built from markdown using ruby-kramdown-rfc2629 1282 (https://rubygems.org/gems/kramdown-rfc2629), and tracked using git 1283 (https://git-scm.com/). The markdown source under development can be 1284 found in the file e2e-mail-guidance.md in the main branch of the git 1285 repository (https://gitlab.com/dkg/e2e-mail-guidance). 1287 You may also be interested in the latest editor's copy 1288 (https://dkg.gitlab.io/e2e-mail-guidance/). 1290 Minor editorial changes can be suggested via merge requests at 1291 https://gitlab.com/dkg/e2e-mail-guidance or by e-mail to the editor. 1292 Please direct all significant commentary to the public IETF LAMPS 1293 mailing list, spasm@ietf.org (https://www.ietf.org/mailman/listinfo/ 1294 spasm). 1296 B.1. Document History 1298 B.1.1. Substantive changes from draft-ietf-...-00 to draft-ietf-...-01 1300 * Added section about distinguishing Main Body Parts and Attachments 1302 * Updated document considerations section, including reference to 1303 auto-built editor's copy 1305 B.1.2. Substantive changes from draft-dkg-...-01 to draft-ietf-...-00 1307 * WG adopted draft 1309 * moved Document History and Document Considerations sections to end 1310 of appendix, to avoid section renumbering when removed 1312 B.1.3. Substantive changes from draft-dkg-...-00 to draft-dkg-...-01 1314 * consideration of success/failure indicators for usability 1316 * clarify extendedKeyUsage and keyUsage algorithm-specific details 1318 * initial section on certificate management 1320 * added more TODO items 1322 Author's Address 1324 Daniel Kahn Gillmor (editor) 1325 American Civil Liberties Union 1326 125 Broad St. 1327 New York, NY, 10004 1328 United States of America 1330 Email: dkg@fifthhorseman.net