idnits 2.17.00 (12 Aug 2021) /tmp/idnits33589/draft-autocrypt-lamps-protected-headers-00.txt: -(316): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 37 characters in excess of 72. 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 ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) == Outdated reference: A later version (-01) exists of draft-bre-openpgp-samples-00 == Outdated reference: A later version (-01) exists of draft-ietf-lamps-header-protection-requirements-00 -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 2 errors (**), 0 flaws (~~), 4 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-00 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 . . . . . . . . . . . . . . . . . . . . 41 121 11.3. Participant Modification . . . . . . . . . . . . . . . . 42 122 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 123 13. Document Considerations . . . . . . . . . . . . . . . . . . . 43 124 13.1. Document History . . . . . . . . . . . . . . . . . . . . 43 125 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 126 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 127 15.1. Normative References . . . . . . . . . . . . . . . . . . 43 128 15.2. Informative References . . . . . . . . . . . . . . . . . 44 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 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 [RFC2822] 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) is used 317 to indicate "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 [I-D.draft-ietf-lamps-header-protection-requirements-00] contains a 978 proposal that attempts to mitigate one of the drawbacks of the scheme 979 described in S/MIME 3.1 (Section 8.1). 981 In particular, it allows _non-legacy_ clients to distinguish between 982 deliberately forwarded messages and those intended to use the defined 983 structure for header protection. 985 However, this fix has no impact on the confusion experienced by 986 legacy clients. 988 8.3. pEp Header Protection 990 [I-D.draft-luck-lamps-pep-header-protection-03] is applicable only to 991 signed+encrypted mail, and does not contemplate protection of signed- 992 only mail. 994 In addition, the pEp header protection involved for "pEp message 995 format 2" has an additional "multipart/mixed" layer designed to 996 facilitate transfer of OpenPGP Transferable Public Keys, which seems 997 orthogonal to the effort to protect headers. 999 Finally, that draft suggests that the exposed Subject header be one 1000 of "=?utf-8?Q?p=E2=89=A1p?=", "pEp", or "Encrypted message". "pEp" is 1001 a mysterious choice for most users, and see Section 7.1 for more 1002 commentary on why "Encrypted message" is likely to be problematic. 1004 8.4. DKIM 1006 [RFC6736] offers DKIM, which is often used to sign headers associated 1007 with a message. 1009 DKIM is orthogonal to the work described in this document, since it 1010 is typically done by the domain operator and not the end user 1011 generating the original message. That is, DKIM is not "end-to-end" 1012 and does not represent the intent of the entity generating the 1013 message. 1015 Furthermore, a DKIM signer does not have access to headers inside an 1016 encrypted Cryptographic Layer, and a DKIM verifier cannot effectively 1017 use DKIM to verify such confidential headers. 1019 8.5. S/MIME "Secure Headers" 1021 [RFC7508] describes a mechanism that embeds message header fields in 1022 the S/MIME signature using ASN.1. 1024 The mechanism proposed in that draft is undefined for use with PGP/ 1025 MIME. While all S/MIME clients must be able to handle CMS and ASN.1 1026 as well as MIME, a standard that works at the MIME layer itself 1027 should be applicable to any MUA that can work with MIME, regardess of 1028 whether end-to-end security layers are provided by S/MIME or PGP/ 1029 MIME. 1031 That mechanism also does not propose a means to provide 1032 confidentiality protection for headers within an encrypted-but-not- 1033 signed message. 1035 Finally, that mechanism offers no equivalent to the Legacy Display 1036 described in Section 5. Instead, sender and receiver are expected to 1037 negotiate in some unspecified way to ensure that it is safe to remove 1038 or modify Exposed Headers in an encrypted message. 1040 8.6. Triple-Wrapping 1042 [RFC2634] defines "Triple Wrapping" as a means of providing cleartext 1043 signatures over signed and encrypted material. This can be used in 1044 combination with the mechanism described in [RFC7508] to authenticate 1045 some headers for transport using S/MIME. 1047 But it does not offer confidentiality protection for the protected 1048 headers, and the signer of the outer layer of a triple-wrapped 1049 message may not be the originator of the message either. 1051 In practice on today's Internet, DKIM ([RFC6736] provides a more 1052 widely-accepted cryptographic header-verification-for-transport 1053 mechanism than triple-wrapped messages. 1055 9. Test Vectors 1057 The subsections below provide example messages that implement the 1058 Protected Header scheme. 1060 The secret keys and OpenPGP certificates from 1061 [I-D.draft-bre-openpgp-samples-00] can be used to decrypt and verify 1062 them. 1064 They are provided in textual source form as [RFC2822] messages. 1066 9.1. Signed Message with Protected Headers 1068 This shows a clearsigned message. Its MIME message structure is: 1070 └┬╴multipart/signed 1071 ├─╴text/plain ← Cryptographic Payload 1072 └─╴application/pgp-signature 1074 Note that if this message had been generated without Protected 1075 Headers, then an attacker with access to it could modify the Subject 1076 without invalidating the signature. Such an attacker could cause Bob 1077 to think that Alice wanted to cancel the contract with BarCorp 1078 instead of FooCorp. 1080 Received: from localhost (localhost [127.0.0.1]); 1081 Sun, 20 Oct 2019 09:18:28 -0400 (UTC-04:00) 1082 MIME-Version: 1.0 1083 Content-Type: multipart/signed; boundary="904b809781"; 1084 protocol="application/pgp-signature"; micalg="pgp-sha512" 1085 From: Alice Lovelace 1086 To: Bob Babbage 1087 Date: Sun, 20 Oct 2019 09:18:11 -0400 1088 Subject: The FooCorp contract 1089 Message-ID: 1091 --904b809781 1092 Content-Type: text/plain; charset="us-ascii" 1093 From: Alice Lovelace 1094 To: Bob Babbage 1095 Date: Sun, 20 Oct 2019 09:18:11 -0400 1096 Subject: The FooCorp contract 1097 Message-ID: 1099 Bob, we need to cancel this contract. 1101 Please start the necessary processes to make that happen today. 1103 Thanks, Alice 1104 -- 1105 Alice Lovelace 1106 President 1107 OpenPGP Example Corp 1109 --904b809781 1110 content-type: application/pgp-signature 1112 -----BEGIN PGP SIGNATURE----- 1114 wnUEARYKAB0FAl2sXpMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj 1115 jjvKAPwOVIBTcSVKcji7kBw0ljyBwpOgoQ7UGaY6cINfhGg5HAEA4jjbHaEuGZ29 1116 WDTKxW/exLlcW1WqY0fva3t6jbniyQI= 1117 =IsHn 1118 -----END PGP SIGNATURE----- 1120 --904b809781-- 1122 9.2. Signed and Encrypted Message with Protected Headers 1124 This shows a simple encrypted message with protected headers. The 1125 encryption also contains an signature in the OpenPGP Message 1126 structure. Its MIME message structure is: 1128 └┬╴multipart/encrypted 1129 ├─╴application/pgp-encrypted 1130 └─╴application/octet-stream 1131 ↧ (decrypts to) 1132 └─╴text/plain ← Cryptographic Payload 1134 The "Subject:" header is successfully obscured. 1136 Note that if this message had been generated without Protected 1137 Headers, then an attacker with access to it could have read the 1138 Subject. Such an attacker would know details about Alice and Bob's 1139 business that they wanted to keep confidential. 1141 The protected headers also protect the authenticity of subject line 1142 as well. 1144 The session key for this message's crypto layer is an AES-256 key 1145 with value 1146 "8df4b2d27d5637138ac6de46415661be0bd01ed12ecf8c1db22a33cf3ede82f2" 1147 (in hex). 1149 If Bob's MUA is capable of interpreting these protected headers, it 1150 should render the "Subject:" of this message as "BarCorp contract 1151 signed, let's go!". 1153 Received: from localhost (localhost [127.0.0.1]); 1154 Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00) 1155 MIME-Version: 1.0 1156 Content-Type: multipart/encrypted; boundary="bcde3ce988"; 1157 protocol="application/pgp-encrypted" 1158 From: Alice Lovelace 1159 To: Bob Babbage 1160 Date: Mon, 21 Oct 2019 07:18:11 -0700 1161 Message-ID: 1162 Subject: ... 1164 --bcde3ce988 1165 content-type: application/pgp-encrypted 1167 Version: 1 1169 --bcde3ce988 1170 content-type: application/octet-stream 1172 -----BEGIN PGP MESSAGE----- 1174 wV4DR2b2udXyHrYSAQdAk4rw/q9TK6dtIBm42jF6Z7z34KmNIDAKF4v4f09n5l0w 1175 OAgtdmIHyUu3ZOHSb8cFRbjAGQ3RcgIAe4DdsZIy/m9eLEDXEzf9yMSufBtap6xb 1176 wcDMA3wvqk35PDeyAQwAgFIzERxgt1aZlcA29Ds10pv0Y3oZ5yKvMNxd+WEEZNcT 1177 rJBOFNlhek5/9/nkATGiDBaKOsu5o9VyDfKMAV0TYwZxuMgUNtvVpf0XL21dghYt 1178 KVqEHeOTXzprUBdztG4Lp4e0vsG0jPZS+CvTLjbcvO+/lzb314mwN8s8vZiQ7Vlj 1179 DxubIqKypY3jL66U0Acwk85IsXdK4CB4nousr2JFK3Y3zv7cQBtPKHEG8HkmvT0R 1180 tl0QoAkdHfw0q4rpc6183FA9e8EUV88XRJrKIYn86IaTPuMkp8ULWSsboalkJH3J 1181 rSq8kzAFFd/A6G8wSj/hVpH6U+NBGW3Z/DQnRmwHqSJfu/Tnue6TFLdDN1EYzk/L 1182 Nlr4YsH6eIB8v3H4u6kY/SwhHCv/F0jItHYVSsIeJz81L0vh28H6hLIMvSDFofJP 1183 fBgIJfZIJ8nzgFpLphVpk0mcI7jHElxEPRg/M5Lmlav9srYHbKbJ0LT67Z9AFnZB 1184 LHRa/p1eZnjpTxrYU2qZ0sHaAS0MB1TwpiucDRH2VN1z8vSKb1qizJ6ZH3qT3zQ8 1185 EAf6Lar5B6l3v/WwhjMPgu/pLlvZgDAo0cWkBYqzWpOcwviAeC7OwqnZY9/BFm/F 1186 RefFysUIu7fWpvBbKtdch9lhb3baetWKI9uAwsaublwgSGZ4dBR2hfVaX72/8oDW 1187 3oJoUvlw59J1r5Ai1l1YtyU8ctNGT2CqbKp6OgVzqm8BOhyQS1ayjMNU0VJs0s3N 1188 BJ0B1rctk5QykDAu3rVf+sgyqzQ7ohFqlG0W/7haocAQqW++Wy9PW/n0oNAuwugv 1189 W4zisCSB916z7whso00e1Ee3Fl7xgubzrGCHU3JNO5X73+gQHZ+jzuyGdBM5NTxd 1190 UcT89ekkd9XqfR2kJrhgiUOe15znWks5JB6VGKWfz2kp2wu1AVxSkbii1Qk/tRhX 1191 PUpHGwkin41WCPlUFA6xMLk9RmLjer2Wkg9zYosnzEIHdPj+WisWY86NRSZ/tJiw 1192 qZvzNwIgkzvqs1T/8aU5Z5rUOqI1l0Kd+tVjlkPyLrZOrvEeYwOwbAzlCdLxsCdq 1193 pY4ckpU/kMbfXXk21YWYFKDCopT7iRkuzDYlyGN4w/LPKQCMZrQxSms9uPNU5XG7 1194 Au4yYdZVMkCLuLQ0kktuLe/CCX4bX82eF/AJ5DEFxWB3CT8FbVhdKrQ2RrLKwE7b 1195 0jBdmT3NoJMtCbq68TBJO3MmOu6AaW7cD4INREbiD+Vr8ukqsnWkFiJ3NigQiT/4 1196 PppJ2bAABRy9Gloa434PN3zgoWzmv80EfyNbZNfY7nGAOhAzBs8FqhrOY2WIBTp+ 1197 YEkvEjS5YOwgEj1/zcHts1pOWczY/AfVi2sLkCT8FqsNlfPPebdR4Oq+CEav/M52 1198 A+CS0s7j1gklNfNd 1199 =87qA 1200 -----END PGP MESSAGE----- 1202 --bcde3ce988-- 1204 Unwrapping the Cryptographic Layer yields the following content: 1206 Content-Type: text/plain; charset="us-ascii" 1207 From: Alice Lovelace 1208 To: Bob Babbage 1209 Date: Mon, 21 Oct 2019 07:18:11 -0700 1210 Subject: BarCorp contract signed, let's go! 1211 Message-ID: 1213 Hi Bob! 1215 I just signed the contract with BarCorp and they've set us up with an account 1216 on their system for testing. 1218 The account information is: 1220 Site: https://barcorp.example/ 1221 Username: examplecorptest 1222 Password: correct-horse-battery-staple 1224 Please get the account set up and apply the test harness. 1226 Let me know when you've got some results. 1228 Thanks, Alice 1229 -- 1230 Alice Lovelace 1231 President 1232 OpenPGP Example Corp 1234 9.3. Signed and Encrypted Message with Protected Headers and Legacy 1235 Display Part 1237 If Alice's MUA wasn't sure whether Bob's MUA would know to render the 1238 obscured "Subject:" header correctly, it might include a legacy 1239 display part in the cryptographic payload. 1241 This message is structured in the following way: 1243 └┬╴multipart/encrypted 1244 ├─╴application/pgp-encrypted 1245 └─╴application/octet-stream 1246 ↧ (decrypts to) 1247 └┬╴multipart/mixed ← Cryptographic Payload 1248 ├─╴text/rfc822-headers ← Legacy Display Part 1249 └─╴text/plain 1251 The example below shows the same message as Section 9.2. 1253 If Bob's MUA is capable of handling protected headers, the two 1254 messages should render in the same way as the message in Section 9.2, 1255 because it will know to omit the Legacy Display part as documented in 1256 Section 5.2. 1258 But if Bob's MUA is capable of decryption but is unaware of protected 1259 headers, it will likely render the Legacy Display part for him so 1260 that he can at least see the originally-intended "Subject:" line. 1262 For this message, the session key is an AES-256 key with value 1263 "95a71b0e344cce43a4dd52c5fd01deec5118290bfd0792a8a733c653a12d223e" 1264 (in hex). 1266 Received: from localhost (localhost [127.0.0.1]); 1267 Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00) 1268 MIME-Version: 1.0 1269 Content-Type: multipart/encrypted; boundary="73c8655345"; 1270 protocol="application/pgp-encrypted" 1271 From: Alice Lovelace 1272 To: Bob Babbage 1273 Date: Mon, 21 Oct 2019 07:18:11 -0700 1274 Message-ID: 1275 Subject: ... 1277 --73c8655345 1278 content-type: application/pgp-encrypted 1280 Version: 1 1282 --73c8655345 1283 content-type: application/octet-stream 1285 -----BEGIN PGP MESSAGE----- 1287 wV4DR2b2udXyHrYSAQdAS0G0tRGi0cGe2INISDT7xS8b5e1iezXzXuFOrAa1fWgw 1288 JK32KLaTpnHegkEVB/cdMLMEEq56BkktxtC94YNSoeKJOTmNPhR+YWLruWRmZoAk 1289 wcDMA3wvqk35PDeyAQv6Ag30fne2jVFaH+oStUEoX/BEaclWJfpIgu9Ex5SYLmEg 1290 tNHJtLMbKWYKQHhpMiyONeVvfgkus8cPZMtpc+eZEP9FaEdQ69CqkB9Cmqt4Hs2q 1291 yNk14ec0KtL9/b5IPx4rVBrBuFSqxxiS0r0bMsTvKss1p4UGgPN9UPhJSj4dsmDP 1292 w+gLkxsUKL6i37QJIOmarMawS4iK7/MN+GbjzlMduw/VuLV80DYgIt4l96E9xJ+1 1293 u7S6/TKXyUSuxG1Wo+3tCEpy+hTKeS8mYnjD8OYVF5To+TCMnznCiEEwebd44ild 1294 54Bt4QS/G+x/s/aSFRM8pN2O8qz5D5sy+Mzp4dG6w/9fAhIt9mp8W/6Vn+Cgy8kD 1295 0dHy3pN5dVavmsBqzy0uaf4xAoLLJZQBzyR+0UWygUyfc2N6VHkXo+S30LhSfkJO 1296 BMNKqkCaUoLFlHQLstZXETfXMJzpuUySH99ZTeyVnfB/eiEr9CByQqTeN9Uqtu0R 1297 QYWEpTvvYei/vJCNDBqT0sIxAftxmF/H2K4hCW2qD3eE/zSe2PpabgStHmfdZrcx 1298 X1sdOYZ7nOE0L3J/zE3jASEyQUZHr5rdt/RI5qwD2a7zirp8RNAyvk93InQuseX7 1299 mgHADtk9LdNTWumiUd8pvm/ChXoRKvqjSV7mHpdBil0D4JKpZTGAQieP4fF71IYw 1300 4E+VwiZZKIDSiYMUEljA3U7+M9siELlvKRACrrPZKr6OE58JywlIgRdewzroMWIO 1301 HoNJ4EOzij5rJfd6fAF4A3lH3wRu8dcuqrKwK2DhL+as1Zc/AABZD9Ov8t97/A/t 1302 b6jWJqVAVWilgarv9wwI4icN6q9hdwPZF5OaLgvpskGAtG3z51vkJuAiMogWP2Iv 1303 T0GuamZb5177yH5ShtowlTZN6D5WR7ShYbdHAPKRWFcYz4S9b7UZiWH1Ts2lHglJ 1304 5mUbpTI1EvJFO1nwUcVLTuqB2N7lwVvD0oM9lSDcgUmrS04lqBDEax1V+PoKXYAi 1305 Q0z3eH6EDzw0xYWZhiBjgvor2qmGuIEqjBa+5qIOMrzBZK+7y0KOlkgaPik0BeYB 1306 jC/107Us+5i7c3EfQXj4K5XP72/SR0KC9cr//q9tRBOGki8yVicyOGbtSGsNgul/ 1307 5T0VlrTecw+3ZOH4mQRGCJmxkes1amdDeklISfBeOe+LBx/tjkyixeXeh05i1doy 1308 n9VY/utOqu3Oo6XnTWktxajuhfvwSA2wNB/JnRFqu8QEVmqVzD/jwNvsvETQC83j 1309 GPKYo+P1PpAHeqRs4tMq18JQzzytXzr5llLp26qT4Sgul+8tqafkfS6zGL1xShMQ 1310 V1uMtoAt5KBfO4nfiGUAiZeR2RqRrT4YLHEZvpblIE8y7l3y8WV8gdiFfOXZ21mg 1311 gGntqnxU0hrC0IggGVBBY7zHVrcQxJOGsnAsqhQJpVBSnP0YgyrKCEVgDF4ibPBz 1312 y2bRxKP4es0advuEVKGAHULhzoV26Siz8h9MkeI6o+d28vestHng++2DsmCrdpSv 1313 EatA 1314 =MxXQ 1315 -----END PGP MESSAGE----- 1317 --73c8655345-- 1319 Unwrapping the Cryptographic Layer yields the following content: 1321 Content-Type: multipart/mixed; boundary="6ae0cc9247" 1322 From: Alice Lovelace 1323 To: Bob Babbage 1324 Date: Mon, 21 Oct 2019 07:18:11 -0700 1325 Subject: BarCorp contract signed, let's go! 1326 Message-ID: 1328 --6ae0cc9247 1329 Content-Type: text/rfc822-headers; charset="us-ascii"; protected-headers="v1" 1330 Content-Disposition: inline 1332 Subject: BarCorp contract signed, let's go! 1334 --6ae0cc9247 1335 Content-Type: text/plain; charset="us-ascii" 1337 Hi Bob! 1339 I just signed the contract with BarCorp and they've set us up with an account 1340 on their system for testing. 1342 The account information is: 1344 Site: https://barcorp.example/ 1345 Username: examplecorptest 1346 Password: correct-horse-battery-staple 1348 Please get the account set up and apply the test harness. 1350 Let me know when you've got some results. 1352 Thanks, Alice 1353 -- 1354 Alice Lovelace 1355 President 1356 OpenPGP Example Corp 1358 --6ae0cc9247-- 1360 9.4. Multilayer Message with Protected Headers 1362 Some mailers may generate signed and encrypted messages with a 1363 multilayer cryptographic envelope. We show here how such a mailer 1364 might generate the same message as Section 9.2. 1366 A typical message like this has the following structure: 1368 └┬╴multipart/encrypted 1369 ├─╴application/pgp-encrypted 1370 └─╴application/octet-stream 1371 ↧ (decrypts to) 1372 └┬╴multipart/signed 1373 ├─╴text/plain ← Cryptographic Payload 1374 └─╴application/pgp-signature 1376 For this message, the session key is an AES-256 key with value 1377 "5e67165ed1516333daeba32044f88fd75d4a9485a563d14705e41d31fb61a9e9" 1378 (in hex). 1380 Received: from localhost (localhost [127.0.0.1]); 1381 Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00) 1382 MIME-Version: 1.0 1383 Content-Type: multipart/encrypted; boundary="15d01ebd43"; 1384 protocol="application/pgp-encrypted" 1385 From: Alice Lovelace 1386 To: Bob Babbage 1387 Date: Mon, 21 Oct 2019 07:18:11 -0700 1388 Message-ID: 1389 Subject: ... 1391 --15d01ebd43 1392 content-type: application/pgp-encrypted 1394 Version: 1 1396 --15d01ebd43 1397 content-type: application/octet-stream 1399 -----BEGIN PGP MESSAGE----- 1401 wV4DR2b2udXyHrYSAQdArQ8apKY0ciE47ZyBKgbOditGO6OBizW/VeQItRdCxA0w 1402 KaoRJewLgRnuvwaEisHWjiA0IHB9+0BSja+GFIh6gBWCFqzAfJQxoywAZMHznn6k 1403 wcDMA3wvqk35PDeyAQv/X3CYHUgNH81gAKZK/Cb7+WDbjmHcgskkvtceANQbEBEr 1404 /yVoou5BSlXsEni2wn1dtrIsrkhj6OF+B1mwGELw/3qcXdhT46iIrjn547b8Wycp 1405 saey8JqqX8FdfrxEYyOeBJn9CMDm0Dawfv+kNEdbfZtZ2IUONRgigKfcs+Pvrv3e 1406 hoY3KUe47cbiqKvw11VFTu2e4+rIPXW4sB3/95Epvo+RSo58p62kbvJDmBPt5E06 1407 mEykcvyd6GP0eyTTbtaHNcNWd8jvGUobfikwibADcmjXmbPwTJefMCBbsYov86bK 1408 72QOWbp39JcmwUWdo850+sU0XoCHmqditFfZqEdcKRFJOl+Rt+pMSrDixHb8Thdi 1409 WcxUXetpDvACrmjsipKHbxBZAgEU0K71zvbUPk930jOqJgsyXKX0WI8u32gNZDfc 1410 enHAAnALKvwoTGU3EM6do0XRMUKYL6+ON1F1L9S1Rm9Fa+WQKcO04ZvdeHbQXkt3 1411 Fx6ZvZT/Bn3fcIWBpHfs0sI0AfeSpGjSejaZvZQ8qoOTQkOqrjuRnpU8232/ngsC 1412 46mObydGJZ5qEMnmdDOfQB6L1LR9dQTCzA6swlG4U62MoO0n6yILCxLZTPVKYm7c 1413 6r4KnQcvrGk1pgozdW1QjFBOjiDXbitHnqGorxKUcVVorXSEU919wKm11tGGyZ7/ 1414 2sta4WQq9ILVvPqB2I1hLfbteBUYWgB/rJcc6JsZyRItEKjSSXZoanYyuCPf0m5r 1415 rpzf18kz8gYk92RTLzefALgMiIuU9CXFtd673/MalsZ2DRYjnI3tC9AXEdV9yVVa 1416 KYX/ECbFPHNxxulu/HU7hL7QQbgxA1E41RM2KjEzmwUEA8EomuNN7eQ5AJjDP0qk 1417 EIjIxIsW8at8FB4vB4sxh95OiF3hHFZj8q6/VZW8K8LspERCdrKmtu46xt2g7uKx 1418 8ifdwqMT5OPu4VD5EPuOZLJRnSnYskTBwjZnX+ZqRdz/7z7XdUhvn4CjjiFt804a 1419 4uunVgTeVXQay97a7oz+SCrNc+Gvv7K0dt7oUt512+0hQAJ3W9J3Chlht4UKs759 1420 QymPx4smS8kY7c57OWpab481cqeQZLMIftBconhzSzAGl1LZhc5MVoc7l3dEABcx 1421 G+zcTIiRT+io8PwaBvnUg3nE0xP201s5vpK2vbBBMDh3O3titYMBDJp3riyp81AR 1422 Rm6tymUZaRMxq17T6BJ0b0fXyQ2fiz5vuudK5L/zDBvkOSIlhvaV2zxJqMhlSS54 1423 W2RrwNjxkgBCiz1u1Yzi/HQ+jUwO/p8uGn0hyyIEEDIX50gPe2IQjgEjGteIBrDF 1424 sfi9jCEhK/Y0xANG4Mt01Ukt6cgGQhrKuBnyy9KRG+US7aaPdMQuPLfOlhPZOjIQ 1425 Bytek3JyT/QCsKPSjcGiNinllYk+Za8gL6SCNfZam1y/E802xX4z30t7Z6EBSRLi 1426 +qwzOCu7wTkJkoOPLfZFLY41OrVaR8lyBG1eZmtJXbER1GuuRv/7IC2xcDZv/2VO 1427 ahdnPLy7 1428 =rOD1 1429 -----END PGP MESSAGE----- 1431 --15d01ebd43-- 1433 Unwrapping the encryption Cryptographic Layer yields the following 1434 content: 1436 Content-Type: multipart/signed; boundary="a6b911f1d1"; 1437 protocol="application/pgp-signature"; micalg="pgp-sha512" 1439 --a6b911f1d1 1440 Content-Type: text/plain; charset="us-ascii" 1441 From: Alice Lovelace 1442 To: Bob Babbage 1443 Date: Mon, 21 Oct 2019 07:18:11 -0700 1444 Subject: BarCorp contract signed, let's go! 1445 Message-ID: 1447 Hi Bob! 1449 I just signed the contract with BarCorp and they've set us up with an account 1450 on their system for testing. 1452 The account information is: 1454 Site: https://barcorp.example/ 1455 Username: examplecorptest 1456 Password: correct-horse-battery-staple 1458 Please get the account set up and apply the test harness. 1460 Let me know when you've got some results. 1462 Thanks, Alice 1463 -- 1464 Alice Lovelace 1465 President 1466 OpenPGP Example Corp 1468 --a6b911f1d1 1469 content-type: application/pgp-signature 1471 -----BEGIN PGP SIGNATURE----- 1473 wnUEARYKAB0FAl2tviMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj 1474 jk5oAQCUL+lTDVp2pMOgcDuwnYtYCU9XMRxLgG4bZERZaYf1jQEAj85xO9Cjd7dZ 1475 jBU3m8KYcHe5P5QtOYMw8snpliWXXgA= 1476 =Vh3K 1477 -----END PGP SIGNATURE----- 1479 --a6b911f1d1-- 1481 Note the placement of the Protected Headers on the Cryptographic 1482 Payload specifically, which is not the immediate child of the 1483 encryption Cryptographic Layer. 1485 9.5. Multilayer Message with Protected Headers and Legacy Display Part 1487 And, a mailer that generates a multilayer cryptographic envelope 1488 might want to provide a Legacy Display part, if it is unsure of the 1489 capabilities of the recipient's MUA. We show here how sucha mailer 1490 might generate the same message as Section 9.2. 1492 Such a message might have the following structure: 1494 └┬╴multipart/encrypted 1495 ├─╴application/pgp-encrypted 1496 └─╴application/octet-stream 1497 ↧ (decrypts to) 1498 └┬╴multipart/signed 1499 ├┬╴multipart/mixed ← Cryptographic Payload 1500 │├─╴text/rfc822-headers ← Legacy Display Part 1501 │└─╴text/plain 1502 └─╴application/pgp-signature 1504 For this message, the session key is an AES-256 key with value 1505 "b346a2a50fa0cf62895b74e8c0d2ad9e3ee1f02b5d564c77d879caaee7a0aa70" 1506 (in hex). 1508 Received: from localhost (localhost [127.0.0.1]); 1509 Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00) 1510 MIME-Version: 1.0 1511 Content-Type: multipart/encrypted; boundary="750bb87f7c"; 1512 protocol="application/pgp-encrypted" 1513 From: Alice Lovelace 1514 To: Bob Babbage 1515 Date: Mon, 21 Oct 2019 07:18:11 -0700 1516 Message-ID: 1517 Subject: ... 1519 --750bb87f7c 1520 content-type: application/pgp-encrypted 1522 Version: 1 1524 --750bb87f7c 1525 content-type: application/octet-stream 1527 -----BEGIN PGP MESSAGE----- 1529 wV4DR2b2udXyHrYSAQdAQL6ivBlSduqtPTk/Y3+ijcQ+N5NYfDl+o474FT/BUBIw 1530 iZzmY+CQgrHf2iRPm2GuOoN+XuZtFYk4cIhwe0gAK7+p/44osZGipnzcw0NDbMC3 1531 wcDMA3wvqk35PDeyAQwAtPLguH2X/uqQupJWoF5bnpcxogM2hr+7W5FSFNCiTh6L 1532 ZWYY9B1M+qQqOsTSqpA9mhOoqlnUGiRWYFU164mla3KmMu4rDKSrP761E9ozQl4k 1533 o7+xjvWEBsVeU6KZLPpi9r5KDxwiGO8PT7qsNHv+OTSvJbOv1azLcSo4g67J03uU 1534 rSbMDjPD1BAZDyf7TwKpg4MXVmJtnuHURjzIQ/VtS6eZ0FYzvPZX0rMo00G4bNkR 1535 t1w06hEUemFRtEI/JhD8H3hDkx4Xo/XBWuiVD/UWrlXh1rGjTCfezd4p7F74/+t+ 1536 VHxLWWkyeNXnQqFZX6nIclvoW/ZQr2RycA8j7L/BSYEeINxE4gau+Mh/9IN460G5 1537 Aabjok1FIv8D3inMDI9MgxHYOkAReCMJ4btObtLlzQy+f6aE3BPihIvAYlRzCBel 1538 9Cl604BDGmVug+UeYJ7+1S55HB5vbWzx88IwELw4FCFaYwiK2FOB53tXSc/sGkBQ 1539 Eh7hf2RLSq0c17fMBuNa0sKDAY5PKwukRG+RDz/TeM0e2Y42hPsVm6rOPKNIjygd 1540 oGHLfXw/vYtpxVcdipa9LRAnoJ4JNSaB3vOLz54yxeXuOJrg6nT9JvSRuQ1AlZHq 1541 7Sf2i0kbYkNYZOig54PVJ1/ESkzyrNlmxlRrmo/I9tCr7Wa5bMlgh0S7wm5wPUm4 1542 sEEf+WeqU9cAQKGz4gmY87/ErvPUnudcl21SKyFZ6SlgXdo1GEAUagf3YPL/eOaW 1543 KSG/c69L3K2nBr8NnsTH054AokKOEJKM0+Tu+z8dSRFfa8vJt+fbaV/wL3xK9yEQ 1544 KxJurGTCQ3uKyaeVEyyc5oscv005iaaS9cskkU2eArjAoXNcS7dFMuNXJBbn9WZc 1545 vDmlUSnpob6ZEVySNiQLKyVPsd50VQALv9ySsVT/LNx1N+QR4PSg7uX029itcXbp 1546 zuJgBg8hnpZxKD1vWPzWslmyaC6iS4Q0qiD4XL669NEmtrSpXjX1xFv5SGLWO7IE 1547 TQttUOUgH2tarrFESGOV+354h8kW/CewMO3yR/rTV19HsZfBbuzCLMiURPmK51gb 1548 diZCD9mxd+LPuMPKo0nnoKgloFMgiono9bimJonGNKdfwhoRFFP8tIHZhkue9zqb 1549 AnjZazfsI6YyfGsshfjQ2xHUuT8tTXtNCA/yhhld3yp1b2LfWdWdGxcGrVugFhy3 1550 fUBgeiL2cIf09cn10Y19cIISwa++LpkVWLWuINORu+d2z5Yi9E2I3Tqoi7kt3PvA 1551 GVfKK+Vpytf5f19vm53gfYPGHeF+V9fLZq2JrD4ewSzHSzbSf0Lo2uIUCRv9gTXV 1552 scKiRvA7O0tjQHKFQKcrZLcUd1YE3uRcLqL4GMlHZMdRIQ2SfEvZe8Ad5ZxoacTW 1553 nthYxDipYMheaLmXmePyTGXV0yo/btUe9q0vErhxIrWxnonhQxronVR2go9695Ia 1554 w/b1FdihjhBvVmymHdYXxCsbIKIPsE7MeAt0YXEmOly2MsqlbYv+XVwFpw9gYa6E 1555 QwMRS3Kd1bJgpuqZ4nOnHgZ1Qewhi1WbF9M3Kz6EryAgQJ6Sgy7syHqdYh4MzVOE 1556 +VMThZ5Q92DIQcJsPpEKpDIfnbEYm7N6Icfmz6fj1L9s7X1oew== 1557 =KH2Q 1558 -----END PGP MESSAGE----- 1560 --750bb87f7c-- 1562 Unwrapping the encryption Cryptographic Layer yields the following 1563 content: 1565 Content-Type: multipart/signed; boundary="4e3b9ccaba"; 1566 protocol="application/pgp-signature"; micalg="pgp-sha512" 1568 --4e3b9ccaba 1569 Content-Type: multipart/mixed; boundary="6ae0cc9247" 1570 From: Alice Lovelace 1571 To: Bob Babbage 1572 Date: Mon, 21 Oct 2019 07:18:11 -0700 1573 Subject: BarCorp contract signed, let's go! 1574 Message-ID: 1576 --6ae0cc9247 1577 Content-Type: text/rfc822-headers; charset="us-ascii"; protected-headers="v1" 1578 Content-Disposition: inline 1580 Subject: BarCorp contract signed, let's go! 1581 --6ae0cc9247 1582 Content-Type: text/plain; charset="us-ascii" 1584 Hi Bob! 1586 I just signed the contract with BarCorp and they've set us up with an account 1587 on their system for testing. 1589 The account information is: 1591 Site: https://barcorp.example/ 1592 Username: examplecorptest 1593 Password: correct-horse-battery-staple 1595 Please get the account set up and apply the test harness. 1597 Let me know when you've got some results. 1599 Thanks, Alice 1600 -- 1601 Alice Lovelace 1602 President 1603 OpenPGP Example Corp 1605 --6ae0cc9247-- 1607 --4e3b9ccaba 1608 content-type: application/pgp-signature 1610 -----BEGIN PGP SIGNATURE----- 1612 wnUEARYKAB0FAl2tviMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj 1613 jgzVAQCXwrEyApDaRBeUX1kQOCbb3RVpXcSO+BdROF1T5K3FxAEAs4hYWZXJD1lp 1614 UBe7D64qKa+fyQE1akkIWgoqoaTSlgk= 1615 =zdtG 1616 -----END PGP SIGNATURE----- 1618 --4e3b9ccaba-- 1620 9.6. An Unfortunately Complex Example 1622 For all of the potential complexity of the Cryptographic Envelope, 1623 the Cryptographic Payload itself can be complex. The Cryptographic 1624 Envelope in this example is the same as the previous example 1625 (Section 9.5). The Cryptographic Payload has protected headers and a 1626 legacy display part (also the same as Section 9.5), but in addition 1627 Alice's MUA composes a message with both plaintext and HTML variants, 1628 and Alice includes a single attachment as well. 1630 While this message is complex, a modern MUA could also plausibly 1631 generate such a structure based on reasonable commands from the user 1632 composing the message (e.g., Alice composes the message with a rich 1633 text editor, and attaches a file to the message). 1635 The key takeaway of this example is that the complexity of the 1636 Cryptographic Payload (which may contain a Legacy Display part) is 1637 independent of and distinct from the complexity of the Cryptographic 1638 Envelope. 1640 This message has the following structure: 1642 └┬╴multipart/encrypted 1643 ├─╴application/pgp-encrypted 1644 └─╴application/octet-stream 1645 ↧ (decrypts to) 1646 └┬╴multipart/signed 1647 ├┬╴multipart/mixed ← Cryptographic Payload 1648 │├─╴text/rfc822-headers ← Legacy Display Part 1649 │└┬╴multipart/mixed 1650 │ ├┬╴multipart/alternative 1651 │ │├─╴text/plain 1652 │ │└─╴text/html 1653 │ └─╴text/x-diff ← attachment 1654 └─╴application/pgp-signature 1656 For this message, the session key is an AES-256 key with value 1657 "1c489cfad9f3c0bf3214bf34e6da42b7f64005e59726baa1b17ffdefe6ecbb52" 1658 (in hex). 1660 Received: from localhost (localhost [127.0.0.1]); 1661 Mon, 21 Oct 2019 07:18:39 -0700 (UTC-07:00) 1662 MIME-Version: 1.0 1663 Content-Type: multipart/encrypted; boundary="241c1d8182"; 1664 protocol="application/pgp-encrypted" 1665 From: Alice Lovelace 1666 To: Bob Babbage 1667 Date: Mon, 21 Oct 2019 07:18:11 -0700 1668 Message-ID: 1669 Subject: ... 1671 --241c1d8182 1672 content-type: application/pgp-encrypted 1674 Version: 1 1676 --241c1d8182 1677 content-type: application/octet-stream 1678 -----BEGIN PGP MESSAGE----- 1680 wV4DR2b2udXyHrYSAQdA6Hrr6FR4JVEu7eJP/tRMX/kaargXF/e5wrUW2Et3Ty8w 1681 HbZhbIWW4vt9reojwemfCX99j9s6zmKCEaAYVwyDZTZd+28AJNIScDgUVD9346cA 1682 wcDMA3wvqk35PDeyAQwAlCnRuVFh7GjzxzLpu6he63MNsKNKFFDKz/mXp5i0O7Je 1683 EUzUd1Hbrmn4OP/fznXrgPoi62DGlJkH/Al31EF5SqkxR71A9v9S3DnJ3PEjNAM9 1684 lrOgEmJnKLGMoFy3wkDDs6c/qQqjLZTtdTrfteQtH9rlLqrPLqV+wbfxGi6qBh07 1685 mUBqbdidqOpBKRs3k5vTXDrsAhGuKK0vTZd5yYJ0emBLtEnKm6MpJdaGWgO7CVnq 1686 8/i4UoMV1lKEQQMB2gnrZ2wGXBD24jkaPefpPhLYa6WSOwL9E49fuo4AJy1CDxm8 1687 aN2PQa+8VsBovsavh2BF50Auy0dGmjdru1O0t8hD1KyFrogeGJ/JgEJFkX5kK0M6 1688 jgW+UZDws0ex3b7ikxM2Gboq2WeOoWqrP7Q09vPUo7fabR74ngj1VpjAdnY5v+cO 1689 HVG+hdAB5dgxXXzI8xYIP7z3bm2refQ1dbomlc8cXb7UJwKhpVgTPdwjcheZDeE9 1690 RVLwradRXPmTqGfWTWSS0sPcAXU5DkOUxi7PiRObKeCAmw2sUnwh9t6vTq+ZFIqQ 1691 JmvsI++VftKg5hiqnPV88pF5fvjDbbcTvHNEAMtMFXLFjGHtcz1dRNwAn8DOXj5F 1692 JpBwGGtY19JZrHPP98gFioqwTQja+7M6b7KTuWKx9+bZ0JjsALxSFW+1taZN0+SB 1693 Ox60tfD0kTp3Wq+W13IYBqSniFkFkWRoua5ta9LUrVPHAnG1d8utycGsroXK/9sl 1694 /dshobLC3qmrInLh6VeryVZBFBOcOW7w5FzxZbAt6xuEvU/ooRepBwIbYkfc66OD 1695 3yEXh6OJmMX6Cqs/HpN66lDRlm4IHD6y88j+Ot9Pwxid1GcEH6Y89rnNqCcoTRDf 1696 94tIXtLb7a1JZlOBOLcM5B/0Qlk3YtuSw945jynqYWJ9sOG+jX0sZ0ZwwRY/gIAz 1697 vPzGzO5UDUiusL5Go1xiJjXvbXW+LKSzgzjOLkUlz1SP5OEkntigMQvsFsKRtE6K 1698 sPeHf8b5INp8tOaHiYX9tnbS8Ozok+BBQTvT0f1tYSlQkGLfvLDFyat1f7ChdTpo 1699 tZBKX+VBycblXzbIo8+BlVRIT0CiNIZwujN50IBfXGbBrxJqbNcA0GQwtLIgZSHG 1700 +1k6nGLPaHJjgN44AfH9JREZD3pMTih9zjfDnOA/dij8XOSIwuQkS0wVrkcvnT9v 1701 ByMn5QYUMUxajAMthP7YLd3uBjvhpqtYPhi8pXB6PuTsLk2nHMIWoKh/WqckZcjx 1702 pccjLia74y+O06XHI2SPG/BtjF7S9s71VcXdmQwzpJ7BP6hCHJ/AIb9W1+UdCCSX 1703 7DHgn7wHqmbQ+LVQDMw2qvBLAXL2D2hn5uXcVMzvL9XuS00UnaKUoYILmhmkBdgl 1704 EVqW/ZeKYv5erZUkTB1f179aXrtoQ4cMRoZfE4S7+j2yCiee8tJRvOQBQjg8KsdZ 1705 b0gR1v8rkEHC9KhURsDmCGaZuFYyl5e4pne2jHDwkyEmTAygdcJpMqbdLb+KGw0V 1706 pacv7pOQj0U0oaEn6JQuiZD1fTjsyNqSVS3whHe/wf5LKeIFNrTqVXi0GwKiZBrp 1707 pvsr4I4H/luVqSg7QKJGpt/tmXY+RPAMts+8FnHBN0SrON2yuVZh3oXv/j8L1qBV 1708 BeUGnA2FYMfCpJti5UBQThZjFieNRT3xVzezGSnhQHeLAB08weAqEOfXP9HBcRng 1709 yNTRKTCfA7NCYHpqjT7+A9d83PEmbX9dAeJxVbIgwkqVVmeW0LmLJi3Lh9qilOJ+ 1710 66xTQQtreq2GUHY5jHapu1mTB2FRmbLftQ+yPsooNVvtzAroEwo2+NKNsHZdyqma 1711 28ECmCbHbCkoVkDyyZDwx9HF8V+0vVxWlW2feYI5IfEbsRlo00s5gMT6e+NZ7lLt 1712 OmwxtPM9UZk6HxoCb+ZaqQDiZljp6NypFhz4rxbgZHU4oUgQ0QndLk9NlipCKj2Q 1713 FX7WBggqXtjMPUHCR6xH2+VPNOQN5O3exT1TCnrT9k2t+8IXB/hgVP/OQSHiI+og 1714 AZQrFl2jObo6CvsOOojsy4rxfawiTo5HafaFBz8GpqQuUt4IGHZIofGIMLU1OQ== 1715 =XtUM 1716 -----END PGP MESSAGE----- 1718 --241c1d8182-- 1720 Unwrapping the encryption Cryptographic Layer yields the following 1721 content: 1723 Content-Type: multipart/signed; boundary="c72d4fa142"; 1724 protocol="application/pgp-signature"; micalg="pgp-sha512" 1726 --c72d4fa142 1727 Content-Type: multipart/mixed; boundary="6ae0cc9247" 1728 From: Alice Lovelace 1729 To: Bob Babbage 1730 Date: Mon, 21 Oct 2019 07:18:11 -0700 1731 Subject: BarCorp contract signed, let's go! 1732 Message-ID: 1734 --6ae0cc9247 1735 Content-Type: text/rfc822-headers; charset="us-ascii"; protected-headers="v1" 1736 Content-Disposition: inline 1738 Subject: BarCorp contract signed, let's go! 1740 --6ae0cc9247 1741 Content-Type: multipart/mixed; boundary="8dfc0e9ecf" 1743 --8dfc0e9ecf 1744 Content-Type: multipart/alternative; boundary="32c4d5a901" 1746 --32c4d5a901 1747 Content-Type: text/plain; charset="us-ascii" 1749 Hi Bob! 1751 I just signed the contract with BarCorp and they've set us up with an account 1752 on their system for testing. 1754 The account information is: 1756 Site: https://barcorp.example/ 1757 Username: examplecorptest 1758 Password: correct-horse-battery-staple 1760 Please get the account set up and apply the test harness. 1762 Let me know when you've got some results. 1764 Thanks, Alice 1765 -- 1766 Alice Lovelace 1767 President 1768 OpenPGP Example Corp 1770 --32c4d5a901 1771 Content-Type: text/html; charset="us-ascii" 1773

Hi Bob! 1774

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

1777 The account information is: 1778

1779
Site
https://barcorp.example/
1780
Username
examplecorptest
1781
Password
correct-horse-battery-staple
1782

1783 Please get the account set up and apply the test harness. 1784

1785 Let me know when you've got some results. 1786

1787 Thanks, Alice
1788 --
1789 Alice Lovelace
1790 President
1791 OpenPGP Example Corp
1792

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