idnits 2.17.00 (12 Aug 2021) /tmp/idnits31734/draft-autocrypt-lamps-protected-headers-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 80 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 date (4 November 2019) is 929 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-bre-openpgp-samples-00 -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 openpgp B.R. Einarsson 3 Internet-Draft Mailpile ehf 4 Intended status: Informational . juga 5 Expires: 7 May 2020 Independent 6 D.K. Gillmor 7 ACLU 8 4 November 2019 10 Protected Headers for Cryptographic E-mail 11 draft-autocrypt-lamps-protected-headers-01 13 Abstract 15 This document describes a common strategy to extend the end-to-end 16 cryptographic protections provided by PGP/MIME, etc. to protect 17 message headers in addition to message bodies. In addition to 18 protecting the authenticity and integrity of headers via signatures, 19 it also describes how to preserve the confidentiality of the Subject 20 header. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 7 May 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.2.1. User-Facing Headers . . . . . . . . . . . . . . . . . 5 59 1.2.2. Structural Headers . . . . . . . . . . . . . . . . . 6 60 2. Protected Headers Summary . . . . . . . . . . . . . . . . . . 6 61 3. Cryptographic MIME Message Structure . . . . . . . . . . . . 7 62 3.1. Cryptographic Layers . . . . . . . . . . . . . . . . . . 7 63 3.1.1. PGP/MIME Signing Cryptographic Layer (multipart/ 64 signed) . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1.2. PGP/MIME Encryption Cryptographic Layer 66 (multipart/encrypted) . . . . . . . . . . . . . . . . 7 67 3.2. Cryptographic Envelope . . . . . . . . . . . . . . . . . 8 68 3.3. Cryptographic Payload . . . . . . . . . . . . . . . . . . 8 69 3.3.1. Simple Cryptographic Payloads . . . . . . . . . . . . 8 70 3.3.2. Multilayer Cryptographic Envelopes . . . . . . . . . 8 71 3.3.3. A Baroque Example . . . . . . . . . . . . . . . . . . 9 72 3.4. Exposed Headers are Outside . . . . . . . . . . . . . . . 9 73 4. Message Composition . . . . . . . . . . . . . . . . . . . . . 10 74 4.1. Copying All Headers . . . . . . . . . . . . . . . . . . . 10 75 4.2. Confidential Subject . . . . . . . . . . . . . . . . . . 10 76 4.3. Obscured Headers . . . . . . . . . . . . . . . . . . . . 10 77 4.4. Message Composition without Protected Headers . . . . . . 10 78 4.5. Message Composition with Protected Headers . . . . . . . 11 79 5. Legacy Display . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.1. Message Generation: Including a Legacy Display 81 Part . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 5.1.1. Legacy Display Transformation . . . . . . . . . . . . 14 83 5.1.2. When to Generate Legacy Display . . . . . . . . . . . 14 84 5.2. Message Rendering: Omitting a Legacy Display Part . . . . 14 85 5.2.1. Legacy Display Detection Algorithm . . . . . . . . . 15 86 5.3. Legacy Display is Decorative and Transitional . . . . . . 15 87 6. Message Interpretation . . . . . . . . . . . . . . . . . . . 16 88 6.1. Reverse-Copying . . . . . . . . . . . . . . . . . . . . . 16 89 6.2. Signature Invalidation . . . . . . . . . . . . . . . . . 16 90 6.3. The Legacy Display Part . . . . . . . . . . . . . . . . . 17 91 6.4. Replying to a Message with Obscured Headers . . . . . . . 17 92 7. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 17 93 7.1. Misunderstood Obscured Subjects . . . . . . . . . . . . . 17 94 7.2. Reply/Forward Losing Subjects . . . . . . . . . . . . . . 18 95 7.3. Usability Impact of Reduced Metadata . . . . . . . . . . 18 96 7.4. Usability Impact of Obscured Message-ID . . . . . . . . . 19 97 7.5. Usability Impact of Obscured From/To/Cc . . . . . . . . . 19 98 7.6. Mailing List Header Modifications . . . . . . . . . . . . 20 99 8. Comparison with Other Header Protection Schemes . . . . . . . 20 100 8.1. S/MIME 3.1 Header Protection . . . . . . . . . . . . . . 20 101 8.2. The Content-Type Property "forwarded=no" 102 {forwarded=no} . . . . . . . . . . . . . . . . . . . . . 21 103 8.3. pEp Header Protection . . . . . . . . . . . . . . . . . . 21 104 8.4. DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . 22 105 8.5. S/MIME "Secure Headers" . . . . . . . . . . . . . . . . . 22 106 8.6. Triple-Wrapping . . . . . . . . . . . . . . . . . . . . . 22 107 9. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 23 108 9.1. Signed Message with Protected Headers . . . . . . . . . . 23 109 9.2. Signed and Encrypted Message with Protected 110 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 24 111 9.3. Signed and Encrypted Message with Protected Headers and 112 Legacy Display Part . . . . . . . . . . . . . . . . . . . 27 113 9.4. Multilayer Message with Protected Headers . . . . . . . . 30 114 9.5. Multilayer Message with Protected Headers and Legacy 115 Display Part . . . . . . . . . . . . . . . . . . . . . . 34 116 9.6. An Unfortunately Complex Example . . . . . . . . . . . . 36 117 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 118 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 119 11.1. Subject Leak . . . . . . . . . . . . . . . . . . . . . . 41 120 11.2. Signature Replay . . . . . . . . . . . . . . . . . . . . 42 121 11.3. Participant Modification . . . . . . . . . . . . . . . . 42 122 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43 123 13. Document Considerations . . . . . . . . . . . . . . . . . . . 43 124 13.1. Document History . . . . . . . . . . . . . . . . . . . . 43 125 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 126 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 127 15.1. Normative References . . . . . . . . . . . . . . . . . . 44 128 15.2. Informative References . . . . . . . . . . . . . . . . . 44 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 131 1. Introduction 133 E-mail end-to-end security with OpenPGP and S/MIME standards can 134 provide integrity, authentication, non-repudiation and 135 confidentiality to the body of a MIME e-mail message. However, PGP/ 136 MIME ([RFC3156]) alone does not protect message headers. And the 137 structure to protect headers defined in S/MIME 3.1 ([RFC3851]) has 138 not seen widespread adoption. 140 This document defines a scheme, "Protected Headers for Cryptographic 141 E-mail", which has been adopted by multiple existing e-mail clients 142 in order to extend the cryptographic protections provided by PGP/MIME 143 to also protect the message headers. 145 This document describes how these protections can be applied to 146 cryptographically signed messages, and also discusses some of the 147 challenges of encrypting many transit-oriented headers. 149 It offers guidance for protecting the confidentiality of non-transit- 150 oriented headers like Subject, and also offers a means to preserve 151 backwards compatibility so that an encrypted Subject remains 152 available to recipients using software that does not implement 153 support for the Protected Headers scheme. 155 The document also discusses some of the compatibility constraints and 156 usability concerns which motivated the design of the scheme, as well 157 as limitations and a comparison with other proposals. 159 While the document (and the authors') focus is primarily PGP/MIME, we 160 believe the technique is broadly applicable and would also apply to 161 other MIME-compatible cryptographic e-mail systems, including S/MIME 162 ([RFC8551]). Furthermore, this technique has already proven itself 163 as a useful building block for other improvements to cryptographic 164 e-mail, such as the Autocrypt Level 1.1 ([Autocrypt]) "Gossip" 165 mechanism. 167 1.1. Requirements Language 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in BCP 172 14 [RFC2119] [RFC8174] when, and only when, they appear in all 173 capitals, as shown here. 175 1.2. Terminology 177 For the purposes of this document, we define the following concepts: 179 * _MUA_ is short for Mail User Agent; an e-mail client. 181 * _Protection_ of message data refers to cryptographic encryption 182 and/or signatures, providing confidentiality, authenticity or 183 both. 185 * _Cryptographic Layer_, _Cryptographic Envelope_ and _Cryptographic 186 Payload_ are defined in Section 3 188 * _Original Headers_ are the [RFC5322] message headers as known to 189 the sending MUA at the time of message composition. 191 * _Protected Headers_ are any headers protected by the scheme 192 described in this document. 194 * _Exposed Headers_ are any headers outside the Cryptographic 195 Payload (protected or not). 197 * _Obscured Headers_ are any Protected Headers which have been 198 modified or removed from the set of Exposed Headers. 200 * _Legacy Display Part_ is a MIME construct which provides 201 visibility for users of legacy clients of data from the Original 202 Headers which may have been removed or obscured from the Exposed 203 Headers. It is defined in Section 5. 205 * _User-Facing Headers_ are explained and enumerated in 206 Section 1.2.1. 208 * _Structural Headers_ are documented in Section 1.2.2. 210 1.2.1. User-Facing Headers 212 Of all the headers that an e-mail message may contain, only a handful 213 are typically presented directly to the user. The user-facing 214 headers are: 216 * "Subject" 218 * "From" 220 * "To" 222 * "Cc" 224 * "Date" 226 * "Reply-To" 228 * "Followup-To" 230 The above is a complete list. No other headers are considered "user- 231 facing". 233 Other headers may affect the visible rendering of the message (e.g., 234 "References" and "In-Reply-To" may affect the placement of a message 235 in a threaded discussion), but they are not directly displayed to the 236 user and so are not considered "user-facing" for the purposes of this 237 document. 239 1.2.2. Structural Headers 241 A message header whose name begins with "Content-" is referred to in 242 this document as a "structural" header. 244 These headers indicate something about the specific MIME part they 245 are attached to, and cannot be transferred or copied to other parts 246 without endangering the readability of the message. 248 This includes (but is not limited to): 250 * "Content-Type" 252 * "Content-Transfer-Encoding" 254 * "Content-Disposition" 256 Note that no "user-facing" headers (Section 1.2.1) are also 257 "structural" headers. Of course, many headers are neither "user- 258 facing" nor "structural". 260 FIXME: are there any non-"Content-*" headers we should consider as 261 structural? 263 2. Protected Headers Summary 265 The Protected Headers scheme relies on three backward-compatible 266 changes to a cryptographically-protected e-mail message: 268 * Headers known to the composing MUA at message composition time are 269 (in addition to their typical placement as Exposed Headers on the 270 outside of the message) also present in the MIME header of the 271 root of the Cryptographic Payload. These Protected Headers share 272 cryptographic properties with the rest of the Cryptographic 273 Payload. 275 * When the Cryptographic Envelope includes encryption, any Exposed 276 Header MAY be _obscured_ by a transformation (including deletion). 278 * If the composing MUA intends to obscure any user-facing headers, 279 it MAY add a decorative "Legacy Display" MIME part to the 280 Cryptographic Payload which additionally duplicates the original 281 values of the obscured user-facing headers. 283 When a composing MUA encrypts a message, it SHOULD obscure the 284 "Subject:" header, by using the literal string "..." (three U+002E 285 FULL STOP characters) as the value of the exposed "Subject:" header. 287 When a receiving MUA encounters a message with a Cryptographic 288 Envelope, it treats the headers of the Cryptographic Payload as 289 belonging to the message itself, not just the subpart. In 290 particular, when rendering a header for any such message, the 291 renderer SHOULD prefer the header's Protected value over its Exposed 292 value. 294 A receiving MUA that understands Protected Headers and discovers a 295 Legacy Display part SHOULD hide the Legacy Display part when 296 rendering the message. 298 The following sections contain more detailed discussion. 300 3. Cryptographic MIME Message Structure 302 Implementations use the structure of an e-mail message to protect the 303 headers. This section establishes some conventions about how to 304 think about message structure. 306 3.1. Cryptographic Layers 308 "Cryptographic Layer" refers to a MIME substructure that supplies 309 some cryptographic protections to an internal MIME subtree. The 310 internal subtree is known as the "protected part" though of course it 311 may itself be a multipart object. 313 For PGP/MIME [RFC3156] there are two forms of Cryptographic Layers, 314 signing and encryption. 316 In the diagrams below, "↧" (DOWNWARDS ARROW FROM BAR, U+21A7) 317 indicates "decrypts to". 319 3.1.1. PGP/MIME Signing Cryptographic Layer (multipart/signed) 321 └┬╴multipart/signed 322 ├─╴[protected part] 323 └─╴application/pgp-signature 325 3.1.2. PGP/MIME Encryption Cryptographic Layer (multipart/encrypted) 327 └┬╴multipart/encrypted 328 ├─╴application/pgp-encrypted 329 └─╴application/octet-stream 330 ↧ (decrypts to) 331 └─╴[protected part] 333 3.2. Cryptographic Envelope 335 The Cryptographic Envelope is the largest contiguous set of 336 Cryptographic Layers of an e-mail message starting with the outermost 337 MIME type (that is, with the Content-Type of the message itself). 339 If the Content-Type of the message itself is not a Cryptographic 340 Layer, then the message has no cryptographic envelope. 342 "Contiguous" in the definition above indicates that if a 343 Cryptographic Layer is the protected part of another Cryptographic 344 Layer, the layers together comprise a single Cryptographic Envelope. 346 Note that if a non-Cryptographic Layer intervenes, all Cryptographic 347 Layers within the non-Cryptographic Layer _are not_ part of the 348 Cryptographic Envelope (see the example in Section 3.3.3). 350 Note also that the ordering of the Cryptographic Layers implies 351 different cryptographic properties. A signed-then-encrypted message 352 is different than an encrypted-then-signed message. 354 3.3. Cryptographic Payload 356 The Cryptographic Payload of a message is the first non-Cryptographic 357 Layer - the "protected part" - within the Cryptographic Envelope. 358 Since the Cryptographic Payload itself is a MIME part, it has its own 359 set of headers. 361 Protected headers are placed on (and read from) the Cryptographic 362 Payload, and should be considered to have the same cryptographic 363 properties as the message itself. 365 3.3.1. Simple Cryptographic Payloads 367 As described above, if the "protected part" identified in 368 Section 3.1.1 or Section 3.1.2 is not itself a Cryptographic Layer, 369 that part _is_ the Cryptographic Payload. 371 If the application wants to generate a message that is both encrypted 372 and signed, it MAY use the simple MIME structure from Section 3.1.2 373 by ensuring that the [RFC4880] Encrypted Message within the 374 "application/octet-stream" part contains an [RFC4880] Signed Message. 376 3.3.2. Multilayer Cryptographic Envelopes 378 It is possible to construct a Cryptographic Envelope consisting of 379 multiple layers for PGP/MIME, typically of the following structure: 381 A └┬╴multipart/encrypted 382 B ├─╴application/pgp-encrypted 383 C └─╴application/octet-stream 384 D ↧ (decrypts to) 385 E └┬╴multipart/signed 386 F ├─╴[Cryptographic Payload] 387 G └─╴application/pgp-signature 389 When handling such a message, the properties of the Cryptographic 390 Envelope are derived from the series "A", "E". 392 As noted in Section 3.3.1, PGP/MIME applications also have a simpler 393 MIME construction available with the same cryptographic properties. 395 3.3.3. A Baroque Example 397 Consider a message with the following overcomplicated structure: 399 H └┬╴multipart/encrypted 400 I ├─╴application/pgp-encrypted 401 J └─╴application/octet-stream 402 K ↧ (decrypts to) 403 L └┬╴multipart/signed 404 M ├┬╴multipart/mixed 405 N │├┬╴multipart/signed 406 O ││├─╴text/plain 407 P ││└─╴application/pgp-signature 408 Q │└─╴text/plain 409 R └─╴application/pgp-signature 411 The 3 Cryptographic Layers in such a message are rooted in parts "H", 412 "L", and "N". But the Cryptographic Envelope of the message consists 413 only of the properties derived from the series "H", "L". The 414 Cryptographic Payload of the message is part "M". 416 It is NOT RECOMMENDED to generate messages with such complicated 417 structures. Even if a receiving MUA can parse this structure 418 properly, it is nearly impossible to render in a way that the user 419 can reason about the cryptographic properties of part "O" compared to 420 part "Q". 422 3.4. Exposed Headers are Outside 424 The Cryptographic Envelope fully encloses the Cryptographic Payload, 425 whether the message is signed or encrypted or both. The Exposed 426 Headers are considered to be outside of both. 428 4. Message Composition 430 This section describes the composition of a cryptographically- 431 protected message with Protected Headers. 433 We document legacy composition of cryptographically-protected 434 messages (without protected headers) in Section 4.4, and then 435 describe a revised version of that algorithm in Section 4.5 that 436 produces conformant Protected Headers. 438 4.1. Copying All Headers 440 All non-structural headers known to the composing MUA are copied to 441 the MIME header of the Cryptographic Payload. The composing MUA 442 SHOULD protect all known non-structural headers in this way. 444 If the composing MUA omits protection for some of the headers, the 445 receiving MUA will have difficulty reasoning about the integrity of 446 the headers (see Section 11.2). 448 4.2. Confidential Subject 450 When a message is encrypted, the Subject should be obscured by 451 replacing the Exposed Subject with three periods: "..." 453 This value ("...") was chosen because it is believed to be language 454 agnostic and avoids communicating any potentially misleading 455 information to the recipient (see Section 7.1 for a more detailed 456 discussion). 458 4.3. Obscured Headers 460 Due to compatibility and usability concerns, a Mail User Agent SHOULD 461 NOT obscure any of: "From", "To", "Cc", "Message-ID", "References", 462 "Reply-To", "In-Reply-To", (FIXME: MORE?) unless the user has 463 indicated they have security constraints which justify the potential 464 downsides (see Section 7 for a more detailed discussion). 466 Aside from that limitation, this specification does not at this time 467 define or limit the methods a MUA may use to convert Exposed Headers 468 into Obscured Headers. 470 4.4. Message Composition without Protected Headers 472 This section roughly describes the steps that a legacy MUA might use 473 to compose a cryptographically-protected message _without_ Protected 474 Headers. 476 The message composition algorithm takes three parameters: 478 * "origbody": the traditional unprotected message body as a well- 479 formed MIME tree (possibly just a single MIME leaf part). As a 480 well-formed MIME tree, "origbody" already has structural headers 481 present (see Section 1.2.2). 483 * "origheaders": the intended non-structural headers for the 484 message, represented here as a table mapping from header names to 485 header values.. For example, "origheaders['From']" refers to the 486 value of the "From" header that the composing MUA would typically 487 place on the message before sending it. 489 * "crypto": The series of cryptographic protections to apply (for 490 example, "sign with the secret key corresponding to OpenPGP 491 certificate X, then encrypt to OpenPGP certificates X and Y"). 492 This is a routine that accepts a MIME tree as input (the 493 Cryptographic Payload), wraps the input in the appropriate 494 Cryptographic Envelope, and returns the resultant MIME tree as 495 output, 497 The algorithm returns a MIME object that is ready to be injected into 498 the mail system: 500 * Apply "crypto" to "origbody", yielding MIME tree "output" 502 * For header name "h" in "origheaders": 504 - Set header "h" of "output" to "origheaders[h]" 506 * Return "output" 508 4.5. Message Composition with Protected Headers 510 A reasonable sequential algorithm for composing a message _with_ 511 protected headers takes two more parameters in addition to 512 "origbody", "origheaders", and "crypto": 514 * "obscures": a table of headers to be obscured during encryption, 515 mapping header names to their obscuring values. For example, this 516 document recommends only obscuring the subject, so that would be 517 represented by the single-entry table "obscures = {'Subject': 518 '...'}". If header "Foo" is to be deleted entirely, 519 "obscures['Foo']" should be set to the special value "null". 521 * "legacy": a boolean value, indicating whether any recipient of the 522 message is believed to have a legacy client (that is, a MUA that 523 is capable of decryption, but does not understand protected 524 headers). 526 The revised algorithm for applying cryptographic protection to a 527 message is as follows: 529 * if "crypto" contains encryption, and "legacy" is "true", and 530 "obscures" contains any user-facing headers (see Section 1.2.1), 531 wrap "orig" in a structure that carries a Legacy Display part: 533 - Create a new MIME leaf part "legacydisplay" with header 534 "Content-Type: text/rfc822-headers; protected-headers="v1"" 536 - For each obscured header name "obh" in "obscures": 538 o If "obh" is user-facing: 540 + Add "obh: origheaders[ob]" to the body of 541 "legacydisplay". For example, if 542 "origheaders['Subject']" is "lunch plans?", then add the 543 line "Subject: lunch plans?" to the body of 544 "legacydisplay" 546 - Construct a new MIME part "wrapper" with "Content-Type: 547 multipart/mixed" 549 - Give "wrapper" exactly two subarts: "legacydisplay" and 550 "origbody", in that order. 552 - Let "payload" be MIME part "wrapper" 554 * Otherwise: 556 - Let "payload" be MIME part "origbody" 558 * For each header name "h" in "origheaders": 560 - Set header "h" of MIME part "payload" to "origheaders[h]" 562 * FIXME: Enigmail adds "protected-headers="v1"" parameter to 563 "payload" here. Is this necessary? 565 * Apply "crypto" to "payload", producing MIME tree "output" 567 * If "crypto" contains encryption: 569 - For each obscured header name "obh" in "obscures": 571 o If "obscures[obh]" is "null": 573 + Drop "obh" from "origheaders" 575 o Else: 577 + Set "origheaders[obh]" to "obscures[obh]" 579 * For each header name "h" in "origheaders": 581 - Set header "h" of "output" to "origheaders[h]" 583 * return "output" 585 Note that both new parameters, "obscured" and "legacy", are 586 effectively ignored if "crypto" does not contain encryption. This is 587 by design, because they are irrelevant for signed-only cryptographic 588 protections. 590 5. Legacy Display 592 MUAs typically display user-facing headers (Section 1.2.1) directly 593 to the user. An encrypted message may be read by a decryption- 594 capable legacy MUA that is unaware of this standard. The user of 595 such a legacy client risks losing access to any obscured headers. 597 This section presents a workaround to mitigate this risk by 598 restructuring the Cryptographic Payload before encrypting to include 599 a "Legacy Display" part. 601 5.1. Message Generation: Including a Legacy Display Part 603 A generating MUA that wants to make an Obscured Subject (or any other 604 user-facing header) visible to a recipient using a legacy MUA SHOULD 605 modify the Cryptographic Payload by wrapping the intended body of the 606 message in a "multipart/mixed" MIME part that prefixes the intended 607 body with a Legacy Display part. 609 The Legacy Display part MUST be of Content-Type "text/ 610 rfc822-headers", and MUST contain a "protected-headers" parameter 611 whose value is "v1". It SHOULD be marked with "Content-Disposition: 612 inline" to encourage recipients to render it. 614 The contents of the Legacy Display part MUST be only the user-facing 615 headers that the sending MUA intends to obscure after encryption. 617 The original body (now a subpart) SHOULD also be marked with 618 "Content-Disposition: inline" to discourage legacy clients from 619 presenting it as an attachment. 621 5.1.1. Legacy Display Transformation 623 Consider a message whose Cryptographic Payload, before encrypting, 624 that would have a traditional "multipart/alternative" structure: 626 X └┬╴multipart/alternative 627 Y ├─╴text/plain 628 Z └─╴text/html 630 When adding a Legacy Display part, this structure becomes: 632 V └┬╴multipart/mixed 633 W ├─╴text/rfc822-headers ("Legacy Display" part) 634 X └┬╴multipart/alternative ("original body") 635 Y ├─╴text/plain 636 Z └─╴text/html 638 Note that with the inclusion of the Legacy Display part, the 639 Cryptographic Payload is the "multipart/mixed" part (part "V" in the 640 example above), so Protected Headers should be placed at that part. 642 5.1.2. When to Generate Legacy Display 644 A MUA SHOULD transform a Cryptographic Payload to include a Legacy 645 Display part only when: 647 * The message is going to be encrypted, and 649 * At least one user-facing header (see Section 1.2.1) is going to be 650 obscured 652 Additionally, if the sender knows that the recipient's MUA is capable 653 of interpreting Protected Headers, it SHOULD NOT attempt to include a 654 Legacy Display part. (Signalling such a capability is out of scope 655 for this document) 657 5.2. Message Rendering: Omitting a Legacy Display Part 659 A MUA that understands Protected Headers may receive an encrypted 660 message that contains a Legacy Display part. Such an MUA SHOULD 661 avoid rendering the Legacy Display part to the user at all, since it 662 is aware of and can render the actual Protected Headers. 664 If a Legacy Display part is detected, the Protected Headers should 665 still be pulled from the Cryptographic Payload (part "V" in the 666 example above), but the body of message SHOULD be rendered as though 667 it were only the original body (part "X" in the example above). 669 5.2.1. Legacy Display Detection Algorithm 671 A receiving MUA acting on a message SHOULD detect the presence of a 672 Legacy Display part and the corresponding "original body" with the 673 following simple algorithm: 675 * Check that all of the following are true for the message: 677 * The Cryptographic Envelope must contain an encrypting 678 Cryptographic Layer 680 * The Cryptographic Payload must have a "Content-Type" of 681 "multipart/mixed" 683 * The Cryptographic Payload must have exactly two subparts 685 * The first subpart of the Cryptographic Payload must have a 686 "Content-Type" of "text/rfc822-headers" 688 * The first subpart of the Cryptographic Payload's "Content-Type" 689 must contain a property of "protected-headers", and its value must 690 be "v1". 692 * If all of the above are true, then the first subpart is the Legacy 693 Display part, and the second subpart is the "original body". 694 Otherwise, the message does not have a Legacy Display part. 696 5.3. Legacy Display is Decorative and Transitional 698 As the above makes clear, the Legacy Display part is strictly 699 decorative, for the benefit of legacy decryption-capable MUAs that 700 may handle the message. As such, the existence of the Legacy Display 701 part and its "multipart/mixed" wrapper are part of a transition plan. 703 As the number of decryption-capable clients that understand Protected 704 Headers grows in comparison to the number of legacy decryption- 705 capable clients, it is expected that some senders will decide to stop 706 generating Legacy Display parts entirely. 708 A MUA developer concerned about accessiblity of the Subject header 709 for their users of encrypted mail when Legacy Display parts are 710 omitted SHOULD implement the Protected Headers scheme described in 711 this document. 713 6. Message Interpretation 715 This document does not currently provide comprehensive 716 recommendations on how to interpret Protected Headers. This is 717 deliberate; research and development is still ongoing. We also 718 recognize that the tolerance of different user groups for false 719 positives (benign conditions misidentified as security risks), vs. 720 their need for strong protections varies a great deal and different 721 MUAs will take different approaches as a result. 723 Some common approaches are discussed below. 725 6.1. Reverse-Copying 727 One strategy for interpreting Protected Headers on an incoming 728 message is to simply ignore any Exposed Header for which a Protected 729 counterpart is available. This is often implemented as a copy 730 operation (copying header back out of the Cryptographic Payload into 731 the main message header) within the code which takes care of parsing 732 the message. 734 A MUA implementing this strategy should pay special attention to any 735 user facing headers (Section 1.2.1). If a message has Protected 736 Headers, and a user-facing header is among the Exposed Headers but 737 missing from the Protected Headers, then an MUA implementing this 738 strategy SHOULD delete the identified Exposed Header before 739 presenting the message to the user. 741 This strategy does not risk raising a false alarm about harmless 742 deviations, but conversely it does nothing to inform the user if they 743 are under attack. This strategy does successfully mitigate and 744 thwart some attacks, including signature replay attacks 745 (Section 11.2) and participant modification attacks (Section 11.3). 747 6.2. Signature Invalidation 749 An alternate strategy for interpreting Protected Headers is to 750 consider the cryptographic signature on a message to be invalid if 751 the Exposed Headers deviate from their Protected counterparts. 753 This state should be presented to the user using the same interface 754 as other signature verification failures. 756 A MUA implementing this strategy MAY want to make a special exception 757 for the "Subject:" header, to avoid invalidating the signature on any 758 signed and encrypted message with a confidential subject. 760 Note that simple signature invalidation may be insufficient to defend 761 against a participant modification attack (Section 11.3). 763 6.3. The Legacy Display Part 765 This part is purely decorative, for the benefit of any recipient 766 using a legacy decryption-capable MUA. See Section 5.2 for details 767 and recommendations on how to handle the Legacy Display part. 769 6.4. Replying to a Message with Obscured Headers 771 When replying to a message, many MUAs copy headers from the original 772 message into their reply. 774 When replying to an encrypted message, users expect the replying MUA 775 to generate an encrypted message if possible. If encryption is not 776 possible, and the reply will be cleartext, users typically want the 777 MUA to avoid leaking previously-encrypted content into the cleartext 778 of the reply. 780 For this reason, an MUA replying to an encrypted message with 781 Obscured Headers SHOULD NOT leak the cleartext of any Obscured 782 Headers into the cleartext of the reply, whether encrypted or not. 784 In particular, the contents of any Obscured Protected Header from the 785 original message SHOULD NOT be placed in the Exposed Headers of the 786 reply message. 788 7. Common Pitfalls and Guidelines 790 Among the MUA authors who already implemented most of this 791 specification, several alternative or more encompasing specifications 792 were discussed and sometimes tried out in practice. This section 793 highlights a few "pitfalls" and guidelines based on these discussions 794 and lessons learned. 796 7.1. Misunderstood Obscured Subjects 798 There were many discussions around what text phrase to use to obscure 799 the "Subject:". Text phrases such as "Encrypted Message" were tried 800 but resulted in both localization problems and user confusion. 802 If the natural language phrase for the obscured "Subject:" is not 803 localized (e.g. just English "Encrypted Message"), then it may be 804 incomprehensible to a non-English-speaking recipient who uses a 805 legacy MUA that renders the obscured "Subject:" directly. 807 On the other hand, if it is localized based on the sender's MUA 808 language settings, there is no guarantee that the recipient prefers 809 the same language as the sender (consider a German speaker sending 810 English text to an Anglophone). There is no standard way for a 811 sending MUA to infer the language preferred by the recipient (aside 812 from statistical inference of language based on the composed message, 813 which would in turn leak information about the supposedly- 814 confidential message body). 816 Furthermore, implementors found that the phrase "Encrypted Message" 817 in the subject line was sometimes understood by users to be an 818 indication from the MUA that the message was actually encrypted. In 819 practice, when some MUA failed to encrypt a message in a thread that 820 started off with an obscured "Subject:", the value "Re: Encrypted 821 Message" was retained even on those cleartext replies, resulting in 822 user confusion. 824 In contrast, using "..." as the obscured "Subject:" was less likely 825 to be seen as an indicator from the MUA of message encryption, and it 826 also neatly sidesteps the localization problems. 828 7.2. Reply/Forward Losing Subjects 830 When the user of a legacy MUA replies to or forwards a message where 831 the Subject has been obscured, it is likely that the new subject will 832 be "Fwd: ..." or "Re: ..." (or the localized equivalent). This 833 breaks an important feature: people are used to continuity of subject 834 within a thread. It is especially unfortunate when a new participant 835 is added to a conversation who never saw the original subject. 837 At this time, there is no known workaround for this problem. The 838 only solution is to upgrade the MUA to support Protected Headers. 840 The authors consider this to be only a minor concern in cases where 841 encryption is being used because confidentiality is important. 842 However, in more opportunistic cases, where encryption is being used 843 routinely regardless of the sensitivity of message contents, this 844 cost becomes higher. 846 7.3. Usability Impact of Reduced Metadata 848 Many mail user agents maintain an index of message metadata 849 (including header data), which is used to rapidly construct mailbox 850 overviews and search result listings. If the process which generates 851 this index does not have access to the encrypted payload of a 852 message, or does not implement Protected Headers, then the index will 853 only contain the obscured versions Exposed Headers, in particular an 854 obscured Subject of "...". 856 For sensitive message content, especially in a hosted MUA-as- 857 a-service situation ("webmail") where the metadata index is 858 maintained and stored by a third party, this may be considered a 859 feature as the subject is protected from the third-party. However, 860 for more routine communications, this harms usability and goes 861 against user expectations. 863 Two simple workarounds exist for this use case: 865 1. If the metadata index is considered secure enough to handle 866 confidential data, the protected content may be stored directly 867 in the index once it has been decrypted. 869 2. If the metadata index is not trusted, the protected content could 870 be re-encrypted and encrypted versions stored in the index 871 instead, which are then decrypted by the client at display time. 873 In both cases, the process which decrypts the message and processes 874 the Protected Headers must be able to update the metadata index. 876 FIXME: add notes about research topics and other non-simple 877 workarounds, like oblivious server-side indexing, or searching on 878 encrypted data. 880 7.4. Usability Impact of Obscured Message-ID 882 Current MUA implementations rely on the outermost Message-ID for 883 message processing and indexing purposes. This processing often 884 happens before any decryption is even attempted. Attempting to send 885 a message with an obscured Message-ID header would result in several 886 MUAs not correctly processing the message, and would likely be seen 887 as a degradation by users. 889 Furthermore, a legacy MUA replying to a message with an obscured 890 "Message-ID:" would be likely to produce threading information 891 ("References:", "In-Reply-To:") that would be misunderstood by the 892 original sender. Implementors generally disapprove of breaking 893 threads. 895 7.5. Usability Impact of Obscured From/To/Cc 897 The impact of obscuring "From:", "To:", and "Cc:" headers has similar 898 issues as discussed with obscuring the "Message-ID:" header in 899 Section 7.4. 901 In addition, obscuring these headers is likely to cause difficulties 902 for a legacy client attempting formulate a correct reply (or "reply 903 all") to a given message. 905 7.6. Mailing List Header Modifications 907 Some popular mailing-list implementations will modify the Exposed 908 Headers of a message in specific, benign ways. In particular, it is 909 common to add markers to the "Subject" line, and it is also common to 910 modify either "From" or "Reply-To" in order to make sure replies go 911 to the list instead of directly to the author of an individual post. 913 Depending on how the MUA resolves discrepancies between the Protected 914 Headers and the Exposed Headers of a received message, these mailing 915 list "features" may either break or the MUA may incorrectly interpret 916 them as a security breach. 918 Implementors may for this reason choose to implement slightly 919 different strategies for resolving discrepancies, if a message is 920 known to come from such a mailing list. MUAs should at the very 921 least avoid presenting false alarms in such cases. 923 8. Comparison with Other Header Protection Schemes 925 Other header protection schemes have been proposed (in the IETF and 926 elsewhere) that are distinct from this mechanism. This section 927 documents the differences between those earlier mechanisms and this 928 one, and hypothesizes why it has seen greater interoperable adoption. 930 The distinctions include: 932 * backward compatibility with legacy clients 934 * compatibility across PGP/MIME and S/MIME 936 * protection for both confidentiality and signing 938 8.1. S/MIME 3.1 Header Protection 940 S/MIME 3.1 ([RFC3851]) introduces header protection via "message/ 941 rfc822" header parts. 943 The problem with this mechanism is that many legacy clients 944 encountering such a message were likely to interpret it as either a 945 forwarded message, or as an unreadable substructure. 947 For signed messages, this is particularly problematic - a message 948 that would otherwise have been easily readable by a client that knows 949 nothing about signed messages suddenly shows up as a message-within- 950 a-message, just by virtue of signing. This has an impact on _all_ 951 clients, whether they are cryptographically-capable or not. 953 For encrypted messages, whose interpretation only matters on the 954 smaller set of cryptographically-capable legacy clients, the 955 resulting message rendering is awkward at best. 957 Furthermore, Formulating a reply to such a message on a legacy client 958 can also leave the user with badly-structured quoted and attributed 959 content. 961 Additionally, a message deliberately forwarded in its own right 962 (without preamble or adjacent explanatory notes) could potentially be 963 confused with a message using the declared structure. 965 The mechanism described here allows cryptographically-incapable 966 legacy MUAs to read and handle cleartext signed messages without any 967 modifications, and permits cryptographically-capable legacy MUAs to 968 handle encrypted messages without any modifications. 970 In particular, the Legacy Display part described in {#legacy-display} 971 makes it feasible for a conformant MUA to generate messages with 972 obscured Subject lines that nonetheless give access to the obscured 973 Subject header for recipients with legacy MUAs. 975 8.2. The Content-Type Property "forwarded=no" {forwarded=no} 977 Section A.1.2 of 978 [I-D.draft-ietf-lamps-header-protection-requirements-01] refers to a 979 proposal that attempts to mitigate one of the drawbacks of the scheme 980 described in S/MIME 3.1 (Section 8.1). 982 In particular, using the Content-Type property "forwarded="no"" 983 allows _non-legacy_ clients to distinguish between deliberately 984 forwarded messages and those intended to use the defined structure 985 for header protection. 987 However, this fix has no impact on the confusion experienced by 988 legacy clients. 990 8.3. pEp Header Protection 992 [I-D.draft-luck-lamps-pep-header-protection-03] is applicable only to 993 signed+encrypted mail, and does not contemplate protection of signed- 994 only mail. 996 In addition, the pEp header protection involved for "pEp message 997 format 2" has an additional "multipart/mixed" layer designed to 998 facilitate transfer of OpenPGP Transferable Public Keys, which seems 999 orthogonal to the effort to protect headers. 1001 Finally, that draft suggests that the exposed Subject header be one 1002 of "=?utf-8?Q?p=E2=89=A1p?=", "pEp", or "Encrypted message". "pEp" is 1003 a mysterious choice for most users, and see Section 7.1 for more 1004 commentary on why "Encrypted message" is likely to be problematic. 1006 8.4. DKIM 1008 [RFC6736] offers DKIM, which is often used to sign headers associated 1009 with a message. 1011 DKIM is orthogonal to the work described in this document, since it 1012 is typically done by the domain operator and not the end user 1013 generating the original message. That is, DKIM is not "end-to-end" 1014 and does not represent the intent of the entity generating the 1015 message. 1017 Furthermore, a DKIM signer does not have access to headers inside an 1018 encrypted Cryptographic Layer, and a DKIM verifier cannot effectively 1019 use DKIM to verify such confidential headers. 1021 8.5. S/MIME "Secure Headers" 1023 [RFC7508] describes a mechanism that embeds message header fields in 1024 the S/MIME signature using ASN.1. 1026 The mechanism proposed in that draft is undefined for use with PGP/ 1027 MIME. While all S/MIME clients must be able to handle CMS and ASN.1 1028 as well as MIME, a standard that works at the MIME layer itself 1029 should be applicable to any MUA that can work with MIME, regardess of 1030 whether end-to-end security layers are provided by S/MIME or PGP/ 1031 MIME. 1033 That mechanism also does not propose a means to provide 1034 confidentiality protection for headers within an encrypted-but-not- 1035 signed message. 1037 Finally, that mechanism offers no equivalent to the Legacy Display 1038 described in Section 5. Instead, sender and receiver are expected to 1039 negotiate in some unspecified way to ensure that it is safe to remove 1040 or modify Exposed Headers in an encrypted message. 1042 8.6. Triple-Wrapping 1044 [RFC2634] defines "Triple Wrapping" as a means of providing cleartext 1045 signatures over signed and encrypted material. This can be used in 1046 combination with the mechanism described in [RFC7508] to authenticate 1047 some headers for transport using S/MIME. 1049 But it does not offer confidentiality protection for the protected 1050 headers, and the signer of the outer layer of a triple-wrapped 1051 message may not be the originator of the message either. 1053 In practice on today's Internet, DKIM ([RFC6736] provides a more 1054 widely-accepted cryptographic header-verification-for-transport 1055 mechanism than triple-wrapped messages. 1057 9. Test Vectors 1059 The subsections below provide example messages that implement the 1060 Protected Header scheme. 1062 The secret keys and OpenPGP certificates from 1063 [I-D.draft-bre-openpgp-samples-00] can be used to decrypt and verify 1064 them. 1066 They are provided in textual source form as [RFC5322] messages. 1068 9.1. Signed Message with Protected Headers 1070 This shows a clearsigned message. Its MIME message structure is: 1072 └┬╴multipart/signed 1073 ├─╴text/plain ← Cryptographic Payload 1074 └─╴application/pgp-signature 1076 Note that if this message had been generated without Protected 1077 Headers, then an attacker with access to it could modify the Subject 1078 without invalidating the signature. Such an attacker could cause Bob 1079 to think that Alice wanted to cancel the contract with BarCorp 1080 instead of FooCorp. 1082 Received: from localhost (localhost [127.0.0.1]); 1083 Sun, 20 Oct 2019 09:18:28 -0400 (UTC-04:00) 1084 MIME-Version: 1.0 1085 Content-Type: multipart/signed; boundary="1790868a14"; 1086 protocol="application/pgp-signature"; micalg="pgp-sha512" 1087 From: Alice Lovelace 1088 To: Bob Babbage 1089 Date: Sun, 20 Oct 2019 09:18:11 -0400 1090 Subject: The FooCorp contract 1091 Message-ID: 1093 --1790868a14 1094 Content-Type: text/plain; charset="us-ascii" 1095 From: Alice Lovelace 1096 To: Bob Babbage 1097 Date: Sun, 20 Oct 2019 09:18:11 -0400 1098 Subject: The FooCorp contract 1099 Message-ID: 1101 Bob, we need to cancel this contract. 1103 Please start the necessary processes to make that happen today. 1105 Thanks, Alice 1106 -- 1107 Alice Lovelace 1108 President 1109 OpenPGP Example Corp 1111 --1790868a14 1112 content-type: application/pgp-signature 1114 -----BEGIN PGP SIGNATURE----- 1116 wnUEARYKAB0FAl2sXpMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj 1117 jq3uAP4/K66bZXT4jFsmKLztz2Ihxjftgf3TaeD2uL05yWdJAQEAjRdWIh35C6MP 1118 utqkLnFeLpkTwrMnncdF/G+so/yXvQA= 1119 =UMd4 1120 -----END PGP SIGNATURE----- 1122 --1790868a14-- 1124 9.2. Signed and Encrypted Message with Protected Headers 1126 This shows a simple encrypted message with protected headers. The 1127 encryption also contains an signature in the OpenPGP Message 1128 structure. Its MIME message structure is: 1130 └┬╴multipart/encrypted 1131 ├─╴application/pgp-encrypted 1132 └─╴application/octet-stream 1133 ↧ (decrypts to) 1134 └─╴text/plain ← Cryptographic Payload 1136 The "Subject:" header is successfully obscured. 1138 Note that if this message had been generated without Protected 1139 Headers, then an attacker with access to it could have read the 1140 Subject. Such an attacker would know details about Alice and Bob's 1141 business that they wanted to keep confidential. 1143 The protected headers also protect the authenticity of subject line 1144 as well. 1146 The session key for this message's crypto layer is an AES-256 key 1147 with value 1148 "8df4b2d27d5637138ac6de46415661be0bd01ed12ecf8c1db22a33cf3ede82f2" 1149 (in hex). 1151 If Bob's MUA is capable of interpreting these protected headers, it 1152 should render the "Subject:" of this message as "BarCorp contract 1153 signed, let's go!". 1155 Received: from localhost (localhost [127.0.0.1]); 1156 Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00) 1157 MIME-Version: 1.0 1158 Content-Type: multipart/encrypted; boundary="bcde3ce988"; 1159 protocol="application/pgp-encrypted" 1160 From: Alice Lovelace 1161 To: Bob Babbage 1162 Date: Mon, 21 Oct 2019 07:18:11 -0700 1163 Message-ID: 1164 Subject: ... 1166 --bcde3ce988 1167 content-type: application/pgp-encrypted 1169 Version: 1 1171 --bcde3ce988 1172 content-type: application/octet-stream 1174 -----BEGIN PGP MESSAGE----- 1176 wV4DR2b2udXyHrYSAQdAifmSGlN6dUG8WjtsDsVf3RoFUu69cEhUQyVMaUBEaSAw 1177 EAtGxmoM2YY6y/87UXI2USJMj9PiFn7RuV0pAFVT6NwMAY1JgLX5qoSdKXuLZ9CA 1178 wcDMA3wvqk35PDeyAQv9HNVhvGMSyCXZjsu5LlLGPF/6XHnk3PtunCo8GpUd7Mg9 1179 zVDS0zK+dtePYHNgKZ47KLDBgu6XInVBWeeSkImaWjFirTmqp/GP20urKQ/phSkC 1180 vI88cEH+fCqeFxDcL5tb0RLm3/iv707CHvoOM2qCbV8WDSSvNY2FGlJZqqGO3mkE 1181 VhZFytVop12c/L5+PltIS0/P25KMoSuIIb9xenAncyLZ1a2M/NsgZjBqWeXFfQnZ 1182 ssMK1xOvNIYNxUzEws+U6un74OE5sBZeZCvM/nIf50iXvEQMxoc/MX2XFUA9Scid 1183 +bmy9nZCit0KQNk4ikrshgtxmG6xJfMv1IpnscQwMy9KfOAhnrVWFVHpzr+K7mXb 1184 yHHF4Ov1Cl2FvwHU6DujaoApkn/xg5BjbRZxfRfVF7LvZ3UJJ/v1XzGLv5LTL8Fr 1185 1S+Ql69M8yvftMiZ799dNgOT7jc4CY5yN7P2YQn5Z3Nm/gUWcGwuqwQecw0hs/87 1186 yCQzkDHAC62LL6+zHqc20sHbAeuQHcGttI9Vu8rEO+5OeDr3WjTB/UXvLKr/G9ty 1187 LUpaYYwFtNgMaRAg0niMV9xfwTFjLBmNkq/8N0mAOsZSO9lMZyUIfBiFbw5yWNzx 1188 TuKxZymZ3ts6ywvKOgzLNgF+AdtTQk5nkNIsh7Fd02RSl9heF3t47FXVSvBSo5KI 1189 FXuznjzK7VNl8fTp9MpBwp00Dai3jtKGQ3/XGiD4l/wa/QxfffojPAZ9UZpgA2Xx 1190 Uw3W4+zCNZNJ35QME6I2ysKwbgAQGFeKM57lLXrmIJWU7KEIDnc1MCBwsSt50yB8 1191 kIdSPXxK/Jon2wbATUN8Uuo3oLA2dpH8XncjrkqTooNjkK3uPrGNphDBVSMA5W5Z 1192 deHc9NmzETXLBPysc0LHWMUO8g4YnWB4sLq9ZBxTYYX9CYRJvdB8EZN4Dq+IUDVK 1193 W7Hu8oFkPRqU7oVa+utiZq5YvTXbIMJBWdUa8r8zlwz0jVsUJGBIPDWhs8Yse2JX 1194 54dNJRAy2X5M3KM1S2Aat1gHl35cft5pLYLp5/gs7GYgybhYfgXbcbBHE6/XTAtg 1195 L7ZbzN+AEDu24uPQaTN5jUA8MfQIkksRgIhZN3N8NBVltv4t+tbtIiaLLaQ/7Wdd 1196 X0BINwZxhBZHEtjljqf4VE4RlWpMriW+ezcrPU3zEcM62knjeCLCh9iseAuz1J1o 1197 R1o4DKwlVY9dJZigguO9kzz+K9n1/mpn8orV9kn5FyH9vs9ZF+RQiSHgpoZ3TKER 1198 iy4T7WPV1WzyPSTmlKktOGjgJ5nszKw8YarMjtXYiPNOShBWuBTxBeSyjCLhZ85m 1199 YAhS1znrJ9CzX3jjaZTHTd/5gYN7wVByUlw9OkyN2QQRFl6fg1xN6Tb79oGxDqh/ 1200 BHb6PBgDtwnGmHdDmw== 1201 =rTjd 1202 -----END PGP MESSAGE----- 1204 --bcde3ce988-- 1206 Unwrapping the Cryptographic Layer yields the following content: 1208 Content-Type: text/plain; charset="us-ascii" 1209 From: Alice Lovelace 1210 To: Bob Babbage 1211 Date: Mon, 21 Oct 2019 07:18:11 -0700 1212 Subject: BarCorp contract signed, let's go! 1213 Message-ID: 1215 Hi Bob! 1217 I just signed the contract with BarCorp and they've set us up with 1218 an account on their system for testing. 1220 The account information is: 1222 Site: https://barcorp.example/ 1223 Username: examplecorptest 1224 Password: correct-horse-battery-staple 1226 Please get the account set up and apply the test harness. 1228 Let me know when you've got some results. 1230 Thanks, Alice 1231 -- 1232 Alice Lovelace 1233 President 1234 OpenPGP Example Corp 1236 9.3. Signed and Encrypted Message with Protected Headers and Legacy 1237 Display Part 1239 If Alice's MUA wasn't sure whether Bob's MUA would know to render the 1240 obscured "Subject:" header correctly, it might include a legacy 1241 display part in the cryptographic payload. 1243 This message is structured in the following way: 1245 └┬╴multipart/encrypted 1246 ├─╴application/pgp-encrypted 1247 └─╴application/octet-stream 1248 ↧ (decrypts to) 1249 └┬╴multipart/mixed ← Cryptographic Payload 1250 ├─╴text/rfc822-headers ← Legacy Display Part 1251 └─╴text/plain 1253 The example below shows the same message as Section 9.2. 1255 If Bob's MUA is capable of handling protected headers, the two 1256 messages should render in the same way as the message in Section 9.2, 1257 because it will know to omit the Legacy Display part as documented in 1258 Section 5.2. 1260 But if Bob's MUA is capable of decryption but is unaware of protected 1261 headers, it will likely render the Legacy Display part for him so 1262 that he can at least see the originally-intended "Subject:" line. 1264 For this message, the session key is an AES-256 key with value 1265 "95a71b0e344cce43a4dd52c5fd01deec5118290bfd0792a8a733c653a12d223e" 1266 (in hex). 1268 Received: from localhost (localhost [127.0.0.1]); 1269 Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00) 1270 MIME-Version: 1.0 1271 Content-Type: multipart/encrypted; boundary="8f1c37571f"; 1272 protocol="application/pgp-encrypted" 1273 From: Alice Lovelace 1274 To: Bob Babbage 1275 Date: Mon, 21 Oct 2019 07:18:11 -0700 1276 Message-ID: 1277 Subject: ... 1279 --8f1c37571f 1280 content-type: application/pgp-encrypted 1282 Version: 1 1284 --8f1c37571f 1285 content-type: application/octet-stream 1287 -----BEGIN PGP MESSAGE----- 1289 wV4DR2b2udXyHrYSAQdARLfz+1WBB1rOgBFbyrPQXZkCoiK/aA7SpG8mY39S8Tow 1290 cuEVQ1/a4B0VfwiKMyXomehg4GMo7akIAd7nh1LIG26eW+JeEjOJLhjrcg4x5Cg/ 1291 wcDMA3wvqk35PDeyAQv9Hu30CZtCMGeHCVyvPeZZuYUWtHDADt4Wo3rg5va5bUu1 1292 nZCV/7vo9worPUvhN+qqLP0t4l0KbdklNofLKggJt/+LgJ/IvJv4KhwK6PR10Cba 1293 Lu2uyzUJK33WKCnvPzqsgEuE4OmbGcIZki3Bo+hKLgr0wS1sNi5okybM5JMmrqTw 1294 GXEmHdtohx4/YFsAJ++b4WEWb26jflBbj7NwyXdAESb/lcxi5ZKqXerRJiaN2X/x 1295 O/CiwZwSw3LA7VlCwN8Jb9AR4KjjFHIi6pUOp5S7Iz0Hs0juA6862gsuOrfGN8q8 1296 1KkTUPwAw0lQSnSpMxsnRS3+zv1aeWnm8K+bt1Q0E/Nl1E0GYtwiEBLVWX1ZQYCr 1297 DgrgFBl3/kvx8e+L+b6bEF9GVckZSGrkzJJeMx1JzGaR5MtkEJThsZAlyrJVpMuf 1298 un4N1Xy11G3IWNMCl8SfvPdnaSrytVej2s3ItL+0sxy3wi4hhCXle/YJuFwPTbEP 1299 G8jkjJknuVd/6kxf85mT0sI1AfS//hCeieoyi9cjeBVGh39z7bonD2bSp5RfYKI5 1300 ANj5ANV+hWeB8TGmI7Ka6OOU/43MuilIRAu79M+XnFjMqDQWmRLhydgkThdc63+l 1301 LTt4jZRnUI2IjxsZ5Bgc13agpWzsStJcjRYz8QWOoANc+A74MCX75gsFn8NbQknR 1302 xa/rXpMEF6TulvgCtV/tDCXOv2hnpu+JhIqwLgKIspJih60R8oSIr5qzX3B4AAcc 1303 8Lr3cGrlohVtMDUYUkQF81+KsBWKJZWEvhZdQZC2nSzJSx5hgmw0D6ybYSGuCh9Z 1304 MyZbH38HJnwkZQWUYPyg4ui8XFi0PVY1WignaF6l0D0DhklzgkzO0Ey1BvEu4Zdg 1305 jkfUjYD4VnXNd4UyIwycfo8myrx3fqd5WcZRJmX9Njhlwn3a4l0adZlTIG9S0ytP 1306 VW9jijjGQ+IhizH+Q4jErcEuHJhNDCD0xOIpjQz68/NDm94BDmI2dyr07YOrQEQa 1307 ahDl7vMfMFQVncGp4zY0kYmNDOPSG3djCU5OhKA6dRz8cmigxvW0/CzMrOArMso3 1308 oW+EjldvkQIgeDwodARO8OLKKdQBQhcWIV4G3R8oaLXDxbP/3XAx7eU53jPi0ahW 1309 PbcD7IfHdrVVTyKLcolb0MqnP12gtnCmOwqWSA3D0aeuRGxIKCLnMVMID3I7OVjb 1310 1PMpXs4EsgIuVxWbm0qibVrw9yYd/4xRKKdZqYP+PCSo4aQEMzW7U+mWiZUmDE07 1311 4xzZlTd1qBRUgBKdteNjOcZ859hPZGREuG++JKBrL5Yr/kVBf8UFGLPES+8vslg3 1312 zMQ9K2FO50o4LxYyaKZEW9ihk2BbGB60+hiimtbpWjqZ79qZZ3PJqzd2Au7da7x4 1313 jKhOSvFAoLyze+8l2m+8uzGAQTh/1k6e3O6UcwdrV5Z4i41LZp2qdD7WBSfZD1tv 1314 IdvtbwnZ7YlLr/X0ESERPW4WWrDlHq4SDt5H16hgAbXVfYwmHxgAPawnIRLYVqZ6 1315 ViIf7Hfaqg== 1316 =QAR/ 1317 -----END PGP MESSAGE----- 1319 --8f1c37571f-- 1321 Unwrapping the Cryptographic Layer yields the following content: 1323 Content-Type: multipart/mixed; boundary="6ae0cc9247" 1324 From: Alice Lovelace 1325 To: Bob Babbage 1326 Date: Mon, 21 Oct 2019 07:18:11 -0700 1327 Subject: BarCorp contract signed, let's go! 1328 Message-ID: 1330 --6ae0cc9247 1331 content-type: text/rfc822-headers; protected-headers="v1" 1332 Content-Disposition: inline 1334 Subject: BarCorp contract signed, let's go! 1336 --6ae0cc9247 1337 Content-Type: text/plain; charset="us-ascii" 1339 Hi Bob! 1341 I just signed the contract with BarCorp and they've set us up with 1342 an account on their system for testing. 1344 The account information is: 1346 Site: https://barcorp.example/ 1347 Username: examplecorptest 1348 Password: correct-horse-battery-staple 1350 Please get the account set up and apply the test harness. 1352 Let me know when you've got some results. 1354 Thanks, Alice 1355 -- 1356 Alice Lovelace 1357 President 1358 OpenPGP Example Corp 1360 --6ae0cc9247-- 1362 9.4. Multilayer Message with Protected Headers 1364 Some mailers may generate signed and encrypted messages with a 1365 multilayer cryptographic envelope. We show here how such a mailer 1366 might generate the same message as Section 9.2. 1368 A typical message like this has the following structure: 1370 └┬╴multipart/encrypted 1371 ├─╴application/pgp-encrypted 1372 └─╴application/octet-stream 1373 ↧ (decrypts to) 1374 └┬╴multipart/signed 1375 ├─╴text/plain ← Cryptographic Payload 1376 └─╴application/pgp-signature 1378 For this message, the session key is an AES-256 key with value 1379 "5e67165ed1516333daeba32044f88fd75d4a9485a563d14705e41d31fb61a9e9" 1380 (in hex). 1382 Received: from localhost (localhost [127.0.0.1]); 1383 Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00) 1384 MIME-Version: 1.0 1385 Content-Type: multipart/encrypted; boundary="15d01ebd43"; 1386 protocol="application/pgp-encrypted" 1387 From: Alice Lovelace 1388 To: Bob Babbage 1389 Date: Mon, 21 Oct 2019 07:18:11 -0700 1390 Message-ID: 1391 Subject: ... 1393 --15d01ebd43 1394 content-type: application/pgp-encrypted 1396 Version: 1 1398 --15d01ebd43 1399 content-type: application/octet-stream 1401 -----BEGIN PGP MESSAGE----- 1403 wV4DR2b2udXyHrYSAQdAOgQDEkyc6EDXP9maqDSnaxSKQ5Cli2idlkJr/fiRJUkw 1404 FBc7t5vaz9x2HIE1M87W8fljvfK9HQIcLRxLo4kba3ZI7wLbDUSQP5SXzV2agnf5 1405 wcDMA3wvqk35PDeyAQv7BFf4oXdwgK7+GaFykpweiQV9PtdzyQUyAZKTjblmH53S 1406 bURXXxQaJVs1v5sqM85WMwgBbCQw2Gjs2K9l4JBWubC/ROO2AKG8odPaj1XA+FW4 1407 cW3jP1G/hoHRhTsWFOYQm/+1lfa7DRt5WVPkIBSHECHP7NW5slLB0uGJaeopU4bY 1408 ZY+65r3ZV3ieTkexwEVkcAdLHGzgpCXyYfj1JwLWWHAuJv96K137Q37J36g9T8wR 1409 hlkIDRqIorY2IexI2lv/PsEHXrzUw4RT4HllriGmHmRJA45QoijnFA3ei+IuhIPm 1410 OcQmlyICZL40fznOaRWYHqp2oLaJ8OVHTU/ZAYurVj+0vsc7qcfxF69S9LvTSInu 1411 CtcamqybdH56wd575OdFKKcng75M19ttIXNguejwMJR0ERL/4xh0y5oN9v5fYzUM 1412 LiK1HIBTjY9JW/jbeqr+InuwTAEvh7Vfzjg+8bMhJMVnTgjea3FSdcfxsrnsZp30 1413 JY6SC70on74Di/zmBg1Z0sIxAVYh7Vc++W0eUIeEj+Azc4mIfaDZ5U3hHk1OV8Lt 1414 XCJz6r/KzUuy3bogwhVUL76kMvuKw/3zQ5zI2YYDpAybsXtUhVA6hg6Zy4JTtJEU 1415 +Z0H0a2EU3CYPBG+ic0PzxAdTz7iDb9AvwpRgWJrgBQmZ5J8bWjgvRTKdt7e2cz8 1416 0ESrfetg+VSEJLWWipNZNzNGaHlUO7ypgwjYYKfX0VAq5rhWCk8079/n4Xzcn9mt 1417 9UaqfjvaV6FuRDFTW1YVkVJdndnC9vQzkHVb6MPFA4fp5H3aY/j3yvMa5YaePv1v 1418 3zA70nuFbe6j1RQO6KhiJBJA7x+MtnZFt6xByhdImVloSr7c9kfuRaFQ83YbwM5I 1419 vjrz29jB8+jG9msFeJ75ajFKpUiN1yVOltTQg+WS28osD3irb461X5YtJCCuD8+d 1420 i6EA7W9P/Hr1YJsaH1wFxYqEpvSClpHWUD/nMbUUWmhvTQ75yJyF1BDfEPmaHhsd 1421 vRBVkZgKdSUo8uNRsSakVWe+4D0U92P0kPyZog6LOOq5EILXnmtZpri6zGt0evgV 1422 qEc316nfQeWRism2KJot83TXIov6KIliB4THBo1Chnp/eCs634B4KF2Z1K2N4AHf 1423 8nIIfpJw60VqPrmOzUUvyabiqrebEkhJ7ZHesZJI+OL8UbaAFklaHMHv6PYWDyBl 1424 7XEwRV8MxqMADd094p5sPXOhj4kbCvHCAY08NFPGIPFVUuwE0YRvRhtVaqMVwf/o 1425 AHO6lGMdQqw1NhmRHkcdLK9qVdZvg5MPwm5w6n8/JvvsHkAVDpsBmvX9jeajI1pq 1426 X6b2cn/G9uNCM1K8zsYIbM/RMM1ILmTh1rgQjFc8S1xE2pQNydegk0JaQz/IqbAa 1427 GZy153vaUNzWSku5Ef3AjFP7YTyB+WRR+AHkAg2UawJq8FXR+KYMjWkg0BPBmhE+ 1428 TXXt8IYUE0uudIAHplt4RWXfr1dfZH2UODdl2ZNyQExtPfTE4VUYtpCIrgSAERKD 1429 QBjq 1430 =ME+d 1431 -----END PGP MESSAGE----- 1433 --15d01ebd43-- 1435 Unwrapping the encryption Cryptographic Layer yields the following 1436 content: 1438 Content-Type: multipart/signed; boundary="a6b911f1d1"; 1439 protocol="application/pgp-signature"; micalg="pgp-sha512" 1441 --a6b911f1d1 1442 Content-Type: text/plain; charset="us-ascii" 1443 From: Alice Lovelace 1444 To: Bob Babbage 1445 Date: Mon, 21 Oct 2019 07:18:11 -0700 1446 Subject: BarCorp contract signed, let's go! 1447 Message-ID: 1449 Hi Bob! 1451 I just signed the contract with BarCorp and they've set us up with 1452 an account on their system for testing. 1454 The account information is: 1456 Site: https://barcorp.example/ 1457 Username: examplecorptest 1458 Password: correct-horse-battery-staple 1460 Please get the account set up and apply the test harness. 1462 Let me know when you've got some results. 1464 Thanks, Alice 1465 -- 1466 Alice Lovelace 1467 President 1468 OpenPGP Example Corp 1470 --a6b911f1d1 1471 content-type: application/pgp-signature 1473 -----BEGIN PGP SIGNATURE----- 1475 wnUEARYKAB0FAl2tviMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj 1476 jv/lAP95zG/boihWaRRYusB5KInnMqz8DM9CrxCO/Z67FoZvQAD/WJKfIW/UaBaG 1477 TvwLcfdYDnHVFi/sLCPzP7/+Rp/prQU= 1478 =X47R 1479 -----END PGP SIGNATURE----- 1481 --a6b911f1d1-- 1483 Note the placement of the Protected Headers on the Cryptographic 1484 Payload specifically, which is not the immediate child of the 1485 encryption Cryptographic Layer. 1487 9.5. Multilayer Message with Protected Headers and Legacy Display Part 1489 And, a mailer that generates a multilayer cryptographic envelope 1490 might want to provide a Legacy Display part, if it is unsure of the 1491 capabilities of the recipient's MUA. We show here how sucha mailer 1492 might generate the same message as Section 9.2. 1494 Such a message might have the following structure: 1496 └┬╴multipart/encrypted 1497 ├─╴application/pgp-encrypted 1498 └─╴application/octet-stream 1499 ↧ (decrypts to) 1500 └┬╴multipart/signed 1501 ├┬╴multipart/mixed ← Cryptographic Payload 1502 │├─╴text/rfc822-headers ← Legacy Display Part 1503 │└─╴text/plain 1504 └─╴application/pgp-signature 1506 For this message, the session key is an AES-256 key with value 1507 "b346a2a50fa0cf62895b74e8c0d2ad9e3ee1f02b5d564c77d879caaee7a0aa70" 1508 (in hex). 1510 Received: from localhost (localhost [127.0.0.1]); 1511 Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00) 1512 MIME-Version: 1.0 1513 Content-Type: multipart/encrypted; boundary="750bb87f7c"; 1514 protocol="application/pgp-encrypted" 1515 From: Alice Lovelace 1516 To: Bob Babbage 1517 Date: Mon, 21 Oct 2019 07:18:11 -0700 1518 Message-ID: 1519 Subject: ... 1521 --750bb87f7c 1522 content-type: application/pgp-encrypted 1524 Version: 1 1526 --750bb87f7c 1527 content-type: application/octet-stream 1529 -----BEGIN PGP MESSAGE----- 1531 wV4DR2b2udXyHrYSAQdAl9YvLLNZzswNHPuBf0LHXgrp7l6MvJ4bc1tgPZD8XGww 1532 mbzTgolXvZe/1NewcfrKpEr2dxQikm9XqvzdODcunsca++c+6sgDGNMNEzSgivaO 1533 wcDMA3wvqk35PDeyAQv/ZKJLN7S79WnezPjzy6RKJi6qPQgKR3X8zfZsnGCw7ooA 1534 Bx5zk+sO2XHM+ho8YJ0HAULkBvzXbDgRoe4VO1kn06nwYBzMnyotNcNf7p6KSfkB 1535 ypiBZ3Orr/0fVaXoStNZfTFp+UqPNw0fVtbTyZRZ0AXmmxVbGPjxjb6m/qRWj26k 1536 0sNb/ruYPzpBEkBdMlK+wYlJHtwyV9gyXU7U33o0UrSf/CcnQcXmJ+OkJbEjUNW/ 1537 MHN69jVY8WC9nOgL98qGLtqQwFaxBEemRCoh3PU4Qw52HHpSJBRJuWb/WjACQ9Ds 1538 wGjg5Q2lBUosnaFUvIFg+eP+aqshSEtSYMXHmERysA7hY91R9YSncPpAjTeb298N 1539 XTKlBmvM6JCT21Ur3y2mi8NmQdmn6J3Pa88MwNpUnJ3yWjNPJZVvbFUkseD3+sDL 1540 oLmxil75U8GoB1YxHoX7TTrkkkHPEJ6jlz3sjOXWByOEfuarSjlwn+QiFFGCMpSJ 1541 0TMye28sCTMs4X6eJSqi0sJ9AU7ecIHNwq9IhMtYcK+6xnY9C9uBoNfnHpigzHj/ 1542 vq0mBnpvEMf9GkUNbkrzwwMu6wFaTSrcvAQjPN+llgvfI1B+lFhOloQJU3Rpuqop 1543 aOoj7LWoocdeCNQINUkflbX0nFf3sLs4lOT/RwfHauwr2PMb2umBNi4ML0gKfj+D 1544 eSoHqiKhDT2USVt1Kt/KnRC1KSd7lAf6U9rvyWA++w8V/gqt7PNVBREem9Ek8AEA 1545 o9uM37nBJuyJSlA6Tqo2GDw603izKbz8A+JlvWyUQWE106nqBX/LMkkm8zhl045+ 1546 EUfKJGIMHFhEWaayPtLFtU1cDvFh2OeZftF1qN451RpWRDwEIVeA6IngotWAaejU 1547 QPLXtDvXKC8O2vIcdI95M+x9yq3or40KS0stZVQAgLZWiXFvvqwyTc+fiby2LYzv 1548 /JPVH3f+F3Vz229u/iob6mgLe3O1Xa2bhcwFqFG1AlpMx2f/ZJsBvYUJ4MMBM/S9 1549 xJ4QPna6oHilBfs72Y2pyCrG6KIBIeWkVd6XhLKaFq5QtKM/rO8IOFtgU7iiJYwD 1550 ZIyVqaV8weaRSF5uGWH2Mc+6/hSeQ+yx8h4sa26KkIwooHbSnx3sjefAB29h013G 1551 8n7u/T375w5Y3J3bHpM888BXUNJh0J+Yiey9PNIEljp577PLBv8sKP0FVpxxfxPO 1552 BFaSoJGiba1GqjJfLRsf3ExeA+ocrnuFfo6x+kyZ7zd0+4+jIQ6fQtF5dnoBbHLA 1553 iTyFZm24994qSOoOoZGEBA5DFsGktAEDfrD8mNYQR9ubY14zlhcOZblQ34w4WsTS 1554 C7olDgoWjos3UQggh+HN+ulp5BO+xTwCVCB85VoVH6pEIZ2IWcAo+R21OMIjyX5d 1555 aE8p3tcqQAGbdPsDR/WRTd/fvNLmEzLDv18ZuglY6b+f0qErG5ce1AJpEhsFZuiX 1556 2oCxVpmURf0T7j7EdrCC8Bhjaq5fw1PPp9Azqv7csYidhmeAw9NetwVo2+fg0H1z 1557 m7sB3QI2qqw4/5ErrKZ1CV109eMOUFMuM+fiJEu+vuXBayvviCPkz0pWHUmjexWS 1558 ISKPpt8ok3hLpojbNf96lDxChlpqaILSL6SopTicnw== 1559 =h5ce 1560 -----END PGP MESSAGE----- 1562 --750bb87f7c-- 1564 Unwrapping the encryption Cryptographic Layer yields the following 1565 content: 1567 Content-Type: multipart/signed; boundary="4e3b9ccaba"; 1568 protocol="application/pgp-signature"; micalg="pgp-sha512" 1570 --4e3b9ccaba 1571 Content-Type: multipart/mixed; boundary="6ae0cc9247" 1572 From: Alice Lovelace 1573 To: Bob Babbage 1574 Date: Mon, 21 Oct 2019 07:18:11 -0700 1575 Subject: BarCorp contract signed, let's go! 1576 Message-ID: 1578 --6ae0cc9247 1579 content-type: text/rfc822-headers; protected-headers="v1" 1580 Content-Disposition: inline 1582 Subject: BarCorp contract signed, let's go! 1583 --6ae0cc9247 1584 Content-Type: text/plain; charset="us-ascii" 1586 Hi Bob! 1588 I just signed the contract with BarCorp and they've set us up with 1589 an account on their system for testing. 1591 The account information is: 1593 Site: https://barcorp.example/ 1594 Username: examplecorptest 1595 Password: correct-horse-battery-staple 1597 Please get the account set up and apply the test harness. 1599 Let me know when you've got some results. 1601 Thanks, Alice 1602 -- 1603 Alice Lovelace 1604 President 1605 OpenPGP Example Corp 1607 --6ae0cc9247-- 1609 --4e3b9ccaba 1610 content-type: application/pgp-signature 1612 -----BEGIN PGP SIGNATURE----- 1614 wnUEARYKAB0FAl2tviMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj 1615 jj/AAQDqeRa+AaS9dHoYHE4sSGhnXfuTlB9WPbtI/3uLmpX4wgD/boo2TFUJ4VYs 1616 KPDOt/ekjp079bvvfcSjpLNEI1sfSwA= 1617 =Otfk 1618 -----END PGP SIGNATURE----- 1620 --4e3b9ccaba-- 1622 9.6. An Unfortunately Complex Example 1624 For all of the potential complexity of the Cryptographic Envelope, 1625 the Cryptographic Payload itself can be complex. The Cryptographic 1626 Envelope in this example is the same as the previous example 1627 (Section 9.5). The Cryptographic Payload has protected headers and a 1628 legacy display part (also the same as Section 9.5), but in addition 1629 Alice's MUA composes a message with both plaintext and HTML variants, 1630 and Alice includes a single attachment as well. 1632 While this message is complex, a modern MUA could also plausibly 1633 generate such a structure based on reasonable commands from the user 1634 composing the message (e.g., Alice composes the message with a rich 1635 text editor, and attaches a file to the message). 1637 The key takeaway of this example is that the complexity of the 1638 Cryptographic Payload (which may contain a Legacy Display part) is 1639 independent of and distinct from the complexity of the Cryptographic 1640 Envelope. 1642 This message has the following structure: 1644 └┬╴multipart/encrypted 1645 ├─╴application/pgp-encrypted 1646 └─╴application/octet-stream 1647 ↧ (decrypts to) 1648 └┬╴multipart/signed 1649 ├┬╴multipart/mixed ← Cryptographic Payload 1650 │├─╴text/rfc822-headers ← Legacy Display Part 1651 │└┬╴multipart/mixed 1652 │ ├┬╴multipart/alternative 1653 │ │├─╴text/plain 1654 │ │└─╴text/html 1655 │ └─╴text/x-diff ← attachment 1656 └─╴application/pgp-signature 1658 For this message, the session key is an AES-256 key with value 1659 "1c489cfad9f3c0bf3214bf34e6da42b7f64005e59726baa1b17ffdefe6ecbb52" 1660 (in hex). 1662 Received: from localhost (localhost [127.0.0.1]); 1663 Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00) 1664 MIME-Version: 1.0 1665 Content-Type: multipart/encrypted; boundary="241c1d8182"; 1666 protocol="application/pgp-encrypted" 1667 From: Alice Lovelace 1668 To: Bob Babbage 1669 Date: Mon, 21 Oct 2019 07:18:11 -0700 1670 Message-ID: 1671 Subject: ... 1673 --241c1d8182 1674 content-type: application/pgp-encrypted 1676 Version: 1 1678 --241c1d8182 1679 content-type: application/octet-stream 1680 -----BEGIN PGP MESSAGE----- 1682 wV4DR2b2udXyHrYSAQdAp4ZrYIrBddsWr41zuxkG+58YgQDeKk1h+gHTz1BmVFMw 1683 oLGI9dIR1LEgCm7FGTB61oXa4JqxSM1+h6q+UFGHjypGMj0/E+BABTgoC7CuYrAr 1684 wcDMA3wvqk35PDeyAQv9EHLWRWMLLSkSJSEqNuywgnAN2I+i6WaCou7t/vP0Looz 1685 /VePnARGcwi6b4RSQYaClf95SOiqzqD56hiXW5yb+2r057HSvAVZ78r0ymCFN83Y 1686 nu9Byy3vulvqueP1PgqJmBY0u5eJjgtCGQs2YM1bb++hyPFHPNsgJuAkB8YwSmqk 1687 aIrFRi2YZXd61Zhvdl58f/ECFMkpmSQRROxddFSXjt/nFXXimWQFP4Jp/m1VjCBF 1688 ne5bQpOdrBjWXWds7zUnFspCtj4RinFI7UjyLR9VelOkezyc58nAIgTdjD0wrp+g 1689 RBdNBGSpoBMBj4t6gVCNMFQL04/UhwQmwl+R0gFDwd2XdJPa9ijCyxROFP9CNcNN 1690 x1Jq+SgkdJMJLbsyWlF8GvioNOMg0cgSEoyXtwCBZV3IpXdMt1SmMAhEv6mmWR4t 1691 zI6BJ3i0dX/y+djz93uj0Ty2fmd/h//OaI5JMn+muhNss4tRRHhNistqyjFO6qaj 1692 cadwj/QetMWVAR8e8lDc0sPeASPx9QMDzFWI+joVIKZ7oAvHw6WArpS+Gu9rhIB6 1693 aa9Xn0dn4l/xYDzFvZqSgVasL7+BFj1NZtdgvdgvLd/ACfAW4G5XvrQ+dEHW/p2n 1694 oVP58W7jKMJNwDxZva1fwNb+6eWwkGVhzI11uX6n0mtL6UpfFYLfirSD/Z/IpMos 1695 sJ1RCnox60W1JardwXIkx5rFgtHgFb9hUyyZKC6VXstuIoSAtlc7NCRsSwuP5PGY 1696 f0g3ttgivLMZOV9Oankqijol6jFDUrNAZJrLZKYYs0AhIkWoDlwhsK4bWSyEk7Zc 1697 BPR033MgGpY4CCadEWPZL4n5vhUsYnBr9LihKDzDWZzdU/5YQpM8OuLqqk9mxsuo 1698 Oim8HPkJ2z1Itw58UIW23cqVXz8uKtEsywNSv8VlM2IVG9jHvhmnK4laZN2U+1bp 1699 KIY9giBFlCqxSjyx2Knq2C7HaBelWjqaGUkH1YOdsnCKEj/JRJYo4ogOLy4xSHEz 1700 8gaDQZjyHLICvsrL84RzDfxx+yWid0Gzzzf69/ux0bATkUXN5tMy4h2p15Fm8LtK 1701 9IAQjiByqf0FKvfQLt8SleNMDPvBfscTCNb+N7aLoJARto2oLHyes8AxM18c4Qb+ 1702 ihNpDwtIvXUN9dn6moylna0Y2eo6zjGWK/bxKVvlNakwxtVOLHxpj1xuNiQC5LJR 1703 n0rHsHOUZQUWTfgp+N8vdwMOJhLyD1yTiCbzrtuw+QYRCXBNBSkc1Jtr6yCESKr/ 1704 1ef03Ygtb0G/H0I6KDLVdrrc0TjjkD98hjILMc953coF4a3yKJOWoLGOWrWup+IX 1705 kiax2FlJ3b13PZODENVfdhQ4ACKUTrl3eZNepZmwzVK8z8CPlQbRYEo7sET0IEBp 1706 Vo7VnLeeUZzNOqwZkyipRNRfkQzMmTjbNZeKvsCQsoZx2goo1Pm7XG093z34RcK8 1707 HHsrEvY7kymXoU1xS2gQYQcoiq4LBY42HJ/+mXcEKqSUuwINYVhlwutFL23T1uvp 1708 9/eY6jyn5cc+QSCZMIf5MRKKruc13xzs/WaxVFd2NfLAghtlqqZj1ziKZ3XRLlwc 1709 pesR9415yGakbBC2C5HwUOhHvv5NMuX4S2UHOiRX+XQzzEOafBekRCHAOXPfbTEm 1710 Xj7wPJVSXS7vCV3K+2scAZopuOJMIOkegcJAsuata2GiHr2TbcRbMAZSQzrQ/wSe 1711 GbkgLHSthKEXVEbkYMTHSDPClpThppfD40mBIHyhw3BbC8j3lVgEZ1EeXyJuhZDu 1712 VzPeRxYD9Yun6UOYYbjBSiWNe59DylN1ZBTICgymnff+utfW94UXs93FGRGgSpNB 1713 c8Jc3tlKd7VP+FlEKBmqFHRzE7fdnabQ3BUBnPdBwjkFqImVOLwwKEZ8MRowDjfu 1714 tcjpUEvROWi/FORqmkZHik7AqfuCO4cB3g5AePYfweIEONXxK7yjjpGlmfNgVLBa 1715 uHlSSNl7/oIRP1ivCNEUmmMbqvKnjrTx7i/0XKdHeyGMpVSaksH4Nj+Wz7jA+65K 1716 iEhVOC2QoKSlI5W7v9fAQXCtNfXWlrrVSAqxk74rpIErdip8SpJloGOvtVtApi19 1717 =p3e5 1718 -----END PGP MESSAGE----- 1720 --241c1d8182-- 1722 Unwrapping the encryption Cryptographic Layer yields the following 1723 content: 1725 Content-Type: multipart/signed; boundary="c72d4fa142"; 1726 protocol="application/pgp-signature"; micalg="pgp-sha512" 1728 --c72d4fa142 1729 Content-Type: multipart/mixed; boundary="6ae0cc9247" 1730 From: Alice Lovelace 1731 To: Bob Babbage 1732 Date: Mon, 21 Oct 2019 07:18:11 -0700 1733 Subject: BarCorp contract signed, let's go! 1734 Message-ID: 1736 --6ae0cc9247 1737 content-type: text/rfc822-headers; protected-headers="v1" 1738 Content-Disposition: inline 1740 Subject: BarCorp contract signed, let's go! 1742 --6ae0cc9247 1743 Content-Type: multipart/mixed; boundary="8dfc0e9ecf" 1745 --8dfc0e9ecf 1746 Content-Type: multipart/alternative; boundary="32c4d5a901" 1748 --32c4d5a901 1749 Content-Type: text/plain; charset="us-ascii" 1751 Hi Bob! 1753 I just signed the contract with BarCorp and they've set us up with 1754 an account on their system for testing. 1756 The account information is: 1758 Site: https://barcorp.example/ 1759 Username: examplecorptest 1760 Password: correct-horse-battery-staple 1762 Please get the account set up and apply the test harness. 1764 Let me know when you've got some results. 1766 Thanks, Alice 1767 -- 1768 Alice Lovelace 1769 President 1770 OpenPGP Example Corp 1772 --32c4d5a901 1773 Content-Type: text/html; charset="us-ascii" 1775

Hi Bob! 1776

1777 I just signed the contract with BarCorp and they've set us up with 1778 an account on their system for testing. 1779

1780 The account information is: 1781

1782
Site
1783 https://barcorp.example/ 1784
1785
Username
examplecorptest
1786
Password
correct-horse-battery-staple
1787

1788 Please get the account set up and apply the test harness. 1789

1790 Let me know when you've got some results. 1791

1792 Thanks, Alice
1793 --
1794 Alice Lovelace
1795 President
1796 OpenPGP Example Corp
1797

1799 --32c4d5a901-- 1801 --8dfc0e9ecf 1802 Content-Type: text/x-diff; charset="us-ascii" 1803 Content-Disposition: inline; filename="testharness-config.diff" 1805 diff -ruN a/testharness.cfg b/testharness.cfg 1806 --- a/testharness.cfg 1807 +++ b/testharness.cfg 1808 @@ -13,3 +13,8 @@ 1809 endpoint = https://openpgp.example/test/ 1810 username = testuser 1811 password = MJVMZlHR75mILg 1812 + 1813 +[barcorp] 1814 +endpoint = https://barcorp.example/ 1815 +username = examplecorptest 1816 +password = correct-horse-battery-staple 1818 --8dfc0e9ecf-- 1820 --6ae0cc9247-- 1821 --c72d4fa142 1822 content-type: application/pgp-signature 1824 -----BEGIN PGP SIGNATURE----- 1826 wnUEARYKAB0FAl2tviMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj 1827 jrR3AP9H2o1HBGLwkz5qzBgGmXsXLrc2xbluWtYmiDQcnq3e9QEA+DaBG1gEXasg 1828 7OfAEqT4DrOivtNo18CxpIPrskgOXws= 1829 =Ul2/ 1830 -----END PGP SIGNATURE----- 1832 --c72d4fa142-- 1834 10. IANA Considerations 1836 FIXME: register content-type parameter for legacy-display part 1838 MAYBE: provide a list of user-facing headers, or a new "user-facing" 1839 column in some table of known RFC5322 headers? 1841 MAYBE: provide a comparable indicator for which headers are 1842 "structural" ? 1844 11. Security Considerations 1846 This document describes a technique that can be used to defend 1847 against two security vulnerabilities in traditional end-to-end 1848 encrypted e-mail. 1850 11.1. Subject Leak 1852 While e-mail structure considers the Subject header to be part of the 1853 message metadata, nearly all users consider the Subject header to be 1854 part of the message content. 1856 As such, a user sending end-to-end encrypted e-mail may inadvertently 1857 leak sensitive material in the Subject line. 1859 If the user's MUA uses Protected Headers and obscures the Subject 1860 header as described in Section 4.2 then they can avoid this breach of 1861 confidentiality. 1863 11.2. Signature Replay 1865 A message without Protected Headers may be subject to a signature 1866 replay attack, which attempts to violate the recipient's expectations 1867 about message authenticity and integrity. Such an attack works by 1868 taking a message delivered in one context (e.g., to someone else, at 1869 a different time, with a different subject, in reply to a different 1870 message), and replaying it with different message headers. 1872 A MUA that generates all its signed messages with Protected Headers 1873 gives recipients the opportunity to avoid falling victim to this 1874 attack. 1876 Guidance for how a message recipient can use Protected Headers to 1877 defend against a signature replay attack are out of scope for this 1878 document. 1880 11.3. Participant Modification 1882 A trivial (if detectable) attack by an active network adversary is to 1883 insert an additional e-mail address in a "To" or "Cc" or "Reply-To" 1884 or "From" header. This is a staging attack against message 1885 confidentiality - it relies on followup action by the recipient. 1887 For an encrypted message that is part of an ongoing discussion where 1888 users are accustomed to doing "reply all", such an insertion would 1889 cause the replying MUA to encrypt the replying message to the 1890 additional party, giving them access to the conversation. If the 1891 replying MUA quotes and attributes cleartext from the original 1892 message within the reply, then the attacker learns the contents of 1893 the encrypted message. 1895 As certificate discovery becomes more automated and less noticeable 1896 to the end user, this is an increasing risk. 1898 An MUA that rejects Exposed Headers in favor of Protected Headers 1899 should be able to avoid this attack when replying to a signed 1900 message. 1902 12. Privacy Considerations 1904 This document only explicitly contemplates confidentiality protection 1905 for the Subject header, but not for other headers which may leak 1906 associational metadata. For example, "From" and "To" and "Cc" and 1907 "Reply-To" and "Date" and "Message-Id" and "References" and "In- 1908 Reply-To" are not explicitly necessary for messages in transit, since 1909 the SMTP envelope carries all necessary routing information, but an 1910 encrypted [RFC5322] message as described in this document will 1911 contain all this associational metadata in the clear. 1913 Although this document does not provide guidance for protecting the 1914 privacy of this metadata directly, it offers a platform upon which 1915 thoughtful implementations may experiment with obscuring additional 1916 e-mail headers. 1918 13. Document Considerations 1920 [ RFC Editor: please remove this section before publication ] 1922 This document is currently edited as markdown. Minor editorial 1923 changes can be suggested via merge requests at 1924 https://github.com/autocrypt/protected-headers or by e-mail to the 1925 authors. Please direct all significant commentary to the public IETF 1926 LAMPS mailing list: spasm@ietf.org 1928 13.1. Document History 1930 Changes between version -00 and -01: 1932 * Credit Randall for "correct horse battery staple". 1934 * Adjust test vectors to ensure no line in the generated .txt format 1935 exceeds 72 chars. 1937 * Minor formatting cleanup to appease idnits. 1939 * Update references to more recent documents (RFC 2822 -> 5322, -00 1940 to -01 of draft-ietf-lamps-header-protection-requirements). 1942 14. Acknowledgements 1944 The set of constructs and algorithms in this document has a previous 1945 working title of "Memory Hole", but that title is no longer used as 1946 different implementations gained experience in working with it. 1948 These ideas were tested and fine-tuned in part by the loose 1949 collaboration of MUA developers known as [Autocrypt]. 1951 Additional feedback and useful guidance was contributed by attendees 1952 of the OpenPGP e-mail summit ([OpenPGP-Email-Summit-2019]). 1954 The following people have contributed implementation experience, 1955 documentation, critique, and other feedback: 1957 * Holger Krekel 1959 * Patrick Brunschwig 1961 * Vincent Breitmoser 1963 The password example used in Section 9 comes from [xkcd936]. 1965 15. References 1967 15.1. Normative References 1969 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1970 Requirement Levels", BCP 14, RFC 2119, 1971 DOI 10.17487/RFC2119, March 1997, 1972 . 1974 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1975 "MIME Security with OpenPGP", RFC 3156, 1976 DOI 10.17487/RFC3156, August 2001, 1977 . 1979 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1980 Thayer, "OpenPGP Message Format", RFC 4880, 1981 DOI 10.17487/RFC4880, November 2007, 1982 . 1984 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1985 DOI 10.17487/RFC5322, October 2008, 1986 . 1988 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1989 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1990 May 2017, . 1992 15.2. Informative References 1994 [Autocrypt] 1995 "Autocrypt Specification 1.1", 13 October 2019, 1996 . 1998 [I-D.draft-bre-openpgp-samples-00] 1999 Einarsson, B., juga, j., and D. Gillmor, "OpenPGP Example 2000 Keys and Certificates", Work in Progress, Internet-Draft, 2001 draft-bre-openpgp-samples-00, 15 October 2019, 2002 . 2005 [I-D.draft-ietf-lamps-header-protection-requirements-01] 2006 Melnikov, A. and B. Hoeneisen, "Problem Statement and 2007 Requirements for Header Protection", Work in Progress, 2008 Internet-Draft, draft-ietf-lamps-header-protection- 2009 requirements-01, 29 October 2019, . 2013 [I-D.draft-luck-lamps-pep-header-protection-03] 2014 Luck, C., "pretty Easy privacy (pEp): Progressive Header 2015 Disclosure", Work in Progress, Internet-Draft, draft-luck- 2016 lamps-pep-header-protection-03, 5 July 2019, 2017 . 2020 [OpenPGP-Email-Summit-2019] 2021 "OpenPGP Email Summit 2019", 13 October 2019, 2022 . 2024 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 2025 RFC 2634, DOI 10.17487/RFC2634, June 1999, 2026 . 2028 [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 2029 Extensions (S/MIME) Version 3.1 Message Specification", 2030 RFC 3851, DOI 10.17487/RFC3851, July 2004, 2031 . 2033 [RFC6736] Brockners, F., Bhandari, S., Singh, V., and V. Fajardo, 2034 "Diameter Network Address and Port Translation Control 2035 Application", RFC 6736, DOI 10.17487/RFC6736, October 2036 2012, . 2038 [RFC7508] Cailleux, L. and C. Bonatti, "Securing Header Fields with 2039 S/MIME", RFC 7508, DOI 10.17487/RFC7508, April 2015, 2040 . 2042 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 2043 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 2044 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 2045 April 2019, . 2047 [xkcd936] Munroe, R., "xkcd: Password Strength", 10 August 2011, 2048 . 2050 Authors' Addresses 2052 Bjarni Rúnar Einarsson 2053 Mailpile ehf 2054 Baronsstigur 2055 Iceland 2057 Email: bre@mailpile.is 2059 juga 2060 Independent 2062 Email: juga@riseup.net 2064 Daniel Kahn Gillmor 2065 American Civil Liberties Union 2066 125 Broad St. 2067 New York, NY, 10004 2068 United States of America 2070 Email: dkg@fifthhorseman.net