idnits 2.17.00 (12 Aug 2021) /tmp/idnits62452/draft-autocrypt-lamps-protected-headers-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 123 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 (20 December 2019) is 876 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 == Outdated reference: A later version (-05) exists of draft-dkg-lamps-samples-01 -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 0 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: 22 June 2020 Independent 6 D.K. Gillmor 7 ACLU 8 20 December 2019 10 Protected Headers for Cryptographic E-mail 11 draft-autocrypt-lamps-protected-headers-02 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 22 June 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 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 Cryptographic Layers . . . . . . . . . . . . 7 64 3.1.2. S/MIME Cryptographic Layers . . . . . . . . . . . . . 8 65 3.2. Cryptographic Envelope . . . . . . . . . . . . . . . . . 9 66 3.3. Cryptographic Payload . . . . . . . . . . . . . . . . . . 9 67 3.3.1. Simple Cryptographic Payloads . . . . . . . . . . . . 9 68 3.3.2. Multilayer Cryptographic Envelopes . . . . . . . . . 10 69 3.3.3. A Baroque Example . . . . . . . . . . . . . . . . . . 10 70 3.4. Exposed Headers are Outside . . . . . . . . . . . . . . . 11 71 4. Message Composition . . . . . . . . . . . . . . . . . . . . . 11 72 4.1. Copying All Headers . . . . . . . . . . . . . . . . . . . 11 73 4.2. Confidential Subject . . . . . . . . . . . . . . . . . . 11 74 4.3. Obscured Headers . . . . . . . . . . . . . . . . . . . . 11 75 4.4. Message Composition without Protected Headers . . . . . . 12 76 4.5. Message Composition with Protected Headers . . . . . . . 12 77 5. Legacy Display . . . . . . . . . . . . . . . . . . . . . . . 14 78 5.1. Message Generation: Including a Legacy Display Part . . . 14 79 5.1.1. Legacy Display Transformation . . . . . . . . . . . . 15 80 5.1.2. When to Generate Legacy Display . . . . . . . . . . . 15 81 5.2. Message Rendering: Omitting a Legacy Display Part . . . . 16 82 5.2.1. Legacy Display Detection Algorithm . . . . . . . . . 16 83 5.3. Legacy Display is Decorative and Transitional . . . . . . 16 84 6. Message Interpretation . . . . . . . . . . . . . . . . . . . 17 85 6.1. Reverse-Copying . . . . . . . . . . . . . . . . . . . . . 17 86 6.2. Signature Invalidation . . . . . . . . . . . . . . . . . 17 87 6.3. The Legacy Display Part . . . . . . . . . . . . . . . . . 18 88 6.4. Replying to a Message with Obscured Headers . . . . . . . 18 89 7. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 18 90 7.1. Misunderstood Obscured Subjects . . . . . . . . . . . . . 18 91 7.2. Reply/Forward Losing Subjects . . . . . . . . . . . . . . 19 92 7.3. Usability Impact of Reduced Metadata . . . . . . . . . . 20 93 7.4. Usability Impact of Obscured Message-ID . . . . . . . . . 20 94 7.5. Usability Impact of Obscured From/To/Cc . . . . . . . . . 21 95 7.6. Mailing List Header Modifications . . . . . . . . . . . . 21 96 8. Comparison with Other Header Protection Schemes . . . . . . . 21 97 8.1. S/MIME 3.1 Header Protection . . . . . . . . . . . . . . 21 98 8.2. The Content-Type Property "forwarded=no" 99 {forwarded=no} . . . . . . . . . . . . . . . . . . . . . 22 100 8.3. pEp Header Protection . . . . . . . . . . . . . . . . . . 23 101 8.4. DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 8.5. S/MIME "Secure Headers" . . . . . . . . . . . . . . . . . 23 103 8.6. Triple-Wrapping . . . . . . . . . . . . . . . . . . . . . 24 104 9. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 24 105 9.1. Signed PGP/MIME Message with Protected Headers . . . . . 24 106 9.2. S/MIME multipart/signed Message with Protected Headers . 27 107 9.3. S/MIME application/pkcs7-mime SignedData Message with 108 Protected Headers . . . . . . . . . . . . . . . . . . . 28 109 9.4. Signed and Encrypted PGP/MIME Message with Protected 110 Headers . . . . . . . . . . . . . . . . . . . . . . . . 30 111 9.5. Signed and Encrypted S/MIME Message with Protected 112 Headers . . . . . . . . . . . . . . . . . . . . . . . . 33 113 9.6. Signed and Encrypted PGP/MIME Message with Protected 114 Headers and Legacy Display Part . . . . . . . . . . . . 38 115 9.7. Multilayer PGP/MIME Message with Protected Headers . . . 41 116 9.8. Multilayer PGP/MIME Message with Protected Headers and 117 Legacy Display Part . . . . . . . . . . . . . . . . . . 45 118 9.9. Signed and Encrypted S/MIME Message with Protected Headers 119 and Legacy Display . . . . . . . . . . . . . . . . . . . 48 120 9.10. Encrypted-only (unsigned) S/MIME Message with Protected 121 Headers and Legacy Display . . . . . . . . . . . . . . . 53 122 9.11. Encrypted-only (unsigned) PGP/MIME Message with Protected 123 Headers and Legacy Display . . . . . . . . . . . . . . . 55 124 9.12. An Unfortunately Complex Example . . . . . . . . . . . . 58 125 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 126 11. Security Considerations . . . . . . . . . . . . . . . . . . . 63 127 11.1. Subject Leak . . . . . . . . . . . . . . . . . . . . . . 63 128 11.2. Signature Replay . . . . . . . . . . . . . . . . . . . . 64 129 11.3. Participant Modification . . . . . . . . . . . . . . . . 64 130 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 65 131 13. Document Considerations . . . . . . . . . . . . . . . . . . . 65 132 13.1. Document History . . . . . . . . . . . . . . . . . . . . 65 133 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 66 134 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 135 15.1. Normative References . . . . . . . . . . . . . . . . . . 66 136 15.2. Informative References . . . . . . . . . . . . . . . . . 67 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 139 1. Introduction 141 E-mail end-to-end security with OpenPGP and S/MIME standards can 142 provide integrity, authentication, non-repudiation and 143 confidentiality to the body of a MIME e-mail message. However, PGP/ 144 MIME ([RFC3156]) alone does not protect message headers. And the 145 structure to protect headers defined in S/MIME 3.1 ([RFC3851]) has 146 not seen widespread adoption. 148 This document defines a scheme, "Protected Headers for Cryptographic 149 E-mail", which has been adopted by multiple existing e-mail clients 150 in order to extend the cryptographic protections provided by PGP/MIME 151 to also protect the message headers. This scheme is also applicable 152 to S/MIME [RFC8551]. 154 This document describes how these protections can be applied to 155 cryptographically signed messages, and also discusses some of the 156 challenges of encrypting many transit-oriented headers. 158 It offers guidance for protecting the confidentiality of non-transit- 159 oriented headers like Subject, and also offers a means to preserve 160 backwards compatibility so that an encrypted Subject remains 161 available to recipients using software that does not implement 162 support for the Protected Headers scheme. 164 The document also discusses some of the compatibility constraints and 165 usability concerns which motivated the design of the scheme, as well 166 as limitations and a comparison with other proposals. 168 This technique has already proven itself as a useful building block 169 for other improvements to cryptographic e-mail, such as the Autocrypt 170 Level 1.1 ([Autocrypt]) "Gossip" mechanism. 172 1.1. Requirements Language 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in BCP 177 14 [RFC2119] [RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 1.2. Terminology 182 For the purposes of this document, we define the following concepts: 184 * _MUA_ is short for Mail User Agent; an e-mail client. 186 * _Protection_ of message data refers to cryptographic encryption 187 and/or signatures, providing confidentiality, authenticity or 188 both. 190 * _Cryptographic Layer_, _Cryptographic Envelope_ and _Cryptographic 191 Payload_ are defined in Section 3 193 * _Original Headers_ are the [RFC5322] message headers as known to 194 the sending MUA at the time of message composition. 196 * _Protected Headers_ are any headers protected by the scheme 197 described in this document. 199 * _Exposed Headers_ are any headers outside the Cryptographic 200 Payload (protected or not). 202 * _Obscured Headers_ are any Protected Headers which have been 203 modified or removed from the set of Exposed Headers. 205 * _Legacy Display Part_ is a MIME construct which provides 206 visibility for users of legacy clients of data from the Original 207 Headers which may have been removed or obscured from the Exposed 208 Headers. It is defined in Section 5. 210 * _User-Facing Headers_ are explained and enumerated in 211 Section 1.2.1. 213 * _Structural Headers_ are documented in Section 1.2.2. 215 1.2.1. User-Facing Headers 217 Of all the headers that an e-mail message may contain, only a handful 218 are typically presented directly to the user. The user-facing 219 headers are: 221 * "Subject" 223 * "From" 225 * "To" 227 * "Cc" 229 * "Date" 231 * "Reply-To" 233 * "Followup-To" 234 The above is a complete list. No other headers are considered "user- 235 facing". 237 Other headers may affect the visible rendering of the message (e.g., 238 "References" and "In-Reply-To" may affect the placement of a message 239 in a threaded discussion), but they are not directly displayed to the 240 user and so are not considered "user-facing" for the purposes of this 241 document. 243 1.2.2. Structural Headers 245 A message header whose name begins with "Content-" is referred to in 246 this document as a "structural" header. 248 These headers indicate something about the specific MIME part they 249 are attached to, and cannot be transferred or copied to other parts 250 without endangering the readability of the message. 252 This includes (but is not limited to): 254 * "Content-Type" 256 * "Content-Transfer-Encoding" 258 * "Content-Disposition" 260 Note that no "user-facing" headers (Section 1.2.1) are also 261 "structural" headers. Of course, many headers are neither "user- 262 facing" nor "structural". 264 FIXME: are there any non-"Content-*" headers we should consider as 265 structural? 267 2. Protected Headers Summary 269 The Protected Headers scheme relies on three backward-compatible 270 changes to a cryptographically-protected e-mail message: 272 * Headers known to the composing MUA at message composition time are 273 (in addition to their typical placement as Exposed Headers on the 274 outside of the message) also present in the MIME header of the 275 root of the Cryptographic Payload. These Protected Headers share 276 cryptographic properties with the rest of the Cryptographic 277 Payload. 279 * When the Cryptographic Envelope includes encryption, any Exposed 280 Header MAY be _obscured_ by a transformation (including deletion). 282 * If the composing MUA intends to obscure any user-facing headers, 283 it MAY add a decorative "Legacy Display" MIME part to the 284 Cryptographic Payload which additionally duplicates the original 285 values of the obscured user-facing headers. 287 When a composing MUA encrypts a message, it SHOULD obscure the 288 "Subject:" header, by using the literal string "..." (three U+002E 289 FULL STOP characters) as the value of the exposed "Subject:" header. 291 When a receiving MUA encounters a message with a Cryptographic 292 Envelope, it treats the headers of the Cryptographic Payload as 293 belonging to the message itself, not just the subpart. In 294 particular, when rendering a header for any such message, the 295 renderer SHOULD prefer the header's Protected value over its Exposed 296 value. 298 A receiving MUA that understands Protected Headers and discovers a 299 Legacy Display part SHOULD hide the Legacy Display part when 300 rendering the message. 302 The following sections contain more detailed discussion. 304 3. Cryptographic MIME Message Structure 306 Implementations use the structure of an e-mail message to protect the 307 headers. This section establishes some conventions about how to 308 think about message structure. 310 3.1. Cryptographic Layers 312 "Cryptographic Layer" refers to a MIME substructure that supplies 313 some cryptographic protections to an internal MIME subtree. The 314 internal subtree is known as the "protected part" though of course it 315 may itself be a multipart object. 317 In the diagrams below, "↧" (DOWNWARDS ARROW FROM BAR, U+21A7) 318 indicates "decrypts to", and "⇩" (DOWNWARDS WHITE ARROW, U+21E9) 319 indicates "unwraps to". 321 3.1.1. PGP/MIME Cryptographic Layers 323 For PGP/MIME [RFC3156] there are two forms of Cryptographic Layers, 324 signing and encryption. 326 3.1.1.1. PGP/MIME Signing Cryptographic Layer (multipart/signed) 327 └┬╴multipart/signed; protocol="application/pgp-signature" 328 ├─╴[protected part] 329 └─╴application/pgp-signature 331 3.1.1.2. PGP/MIME Encryption Cryptographic Layer (multipart/encrypted) 333 └┬╴multipart/encrypted 334 ├─╴application/pgp-encrypted 335 └─╴application/octet-stream 336 ↧ (decrypts to) 337 └─╴[protected part] 339 3.1.2. S/MIME Cryptographic Layers 341 For S/MIME [RFC8551], there are four forms of Cryptographic Layers: 342 multipart/signed, PKCS#7 signed-data, PKCS7 enveloped-data, PKCS7 343 authEnveloped-data. 345 3.1.2.1. S/MIME Multipart Signed Cryptographic Layer 347 └┬╴multipart/signed; protocol="application/pkcs7-signature" 348 ├─╴[protected part] 349 └─╴application/pkcs7-signature 351 3.1.2.2. S/MIME PKCS7 signed-data Cryptographic Layer 353 └─╴application/pkcs7-mime; smime-type="signed-data" 354 ⇩ (unwraps to) 355 └─╴[protected part] 357 3.1.2.3. S/MIME PKCS7 enveloped-data Cryptographic Layer 359 └─╴application/pkcs7-mime; smime-type="enveloped-data" 360 ↧ (decrypts to) 361 └─╴[protected part] 363 3.1.2.4. S/MIME PKCS7 authEnveloped-data Cryptographic Layer 365 └─╴application/pkcs7-mime; smime-type="authEnveloped-data" 366 ↧ (decrypts to) 367 └─╴[protected part] 369 Note that "enveloped-data" (Section 3.1.2.3) and "authEnveloped-data" 370 (Section 3.1.2.4) have identical message structure and semantics. 371 The only difference between the two is ciphertext malleability. 373 The examples in this document only include "enveloped-data", but the 374 implications for that layer apply to "authEnveloped-data" as well. 376 3.1.2.5. PKCS7 Compression is NOT a Cryptographic Layer 378 The Cryptographic Message Syntax (CMS) provides a MIME compression 379 layer ("smime-type="compressed-data""), as defined in [RFC3274]. 380 While the compression layer is technically a part of CMS, it is not 381 considered a Cryptographic Layer for the purposes of this document. 383 3.2. Cryptographic Envelope 385 The Cryptographic Envelope is the largest contiguous set of 386 Cryptographic Layers of an e-mail message starting with the outermost 387 MIME type (that is, with the Content-Type of the message itself). 389 If the Content-Type of the message itself is not a Cryptographic 390 Layer, then the message has no cryptographic envelope. 392 "Contiguous" in the definition above indicates that if a 393 Cryptographic Layer is the protected part of another Cryptographic 394 Layer, the layers together comprise a single Cryptographic Envelope. 396 Note that if a non-Cryptographic Layer intervenes, all Cryptographic 397 Layers within the non-Cryptographic Layer _are not_ part of the 398 Cryptographic Envelope (see the example in Section 3.3.3). 400 Note also that the ordering of the Cryptographic Layers implies 401 different cryptographic properties. A signed-then-encrypted message 402 is different than an encrypted-then-signed message. 404 3.3. Cryptographic Payload 406 The Cryptographic Payload of a message is the first non-Cryptographic 407 Layer - the "protected part" - within the Cryptographic Envelope. 408 Since the Cryptographic Payload itself is a MIME part, it has its own 409 set of headers. 411 Protected headers are placed on (and read from) the Cryptographic 412 Payload, and should be considered to have the same cryptographic 413 properties as the message itself. 415 3.3.1. Simple Cryptographic Payloads 417 As described above, if the "protected part" identified in 418 Section 3.1.1.1 or Section 3.1.1.2 is not itself a Cryptographic 419 Layer, that part _is_ the Cryptographic Payload. 421 If the application wants to generate a message that is both encrypted 422 and signed, it MAY use the simple MIME structure from Section 3.1.1.2 423 by ensuring that the [RFC4880] Encrypted Message within the 424 "application/octet-stream" part contains an [RFC4880] Signed Message. 426 3.3.2. Multilayer Cryptographic Envelopes 428 It is possible to construct a Cryptographic Envelope consisting of 429 multiple layers for PGP/MIME, typically of the following structure: 431 A └┬╴multipart/encrypted 432 B ├─╴application/pgp-encrypted 433 C └─╴application/octet-stream 434 D ↧ (decrypts to) 435 E └┬╴multipart/signed 436 F ├─╴[Cryptographic Payload] 437 G └─╴application/pgp-signature 439 When handling such a message, the properties of the Cryptographic 440 Envelope are derived from the series "A", "E". 442 As noted in Section 3.3.1, PGP/MIME applications also have a simpler 443 MIME construction available with the same cryptographic properties. 445 3.3.3. A Baroque Example 447 Consider a message with the following overcomplicated structure: 449 H └┬╴multipart/encrypted 450 I ├─╴application/pgp-encrypted 451 J └─╴application/octet-stream 452 K ↧ (decrypts to) 453 L └┬╴multipart/signed 454 M ├┬╴multipart/mixed 455 N │├┬╴multipart/signed 456 O ││├─╴text/plain 457 P ││└─╴application/pgp-signature 458 Q │└─╴text/plain 459 R └─╴application/pgp-signature 461 The 3 Cryptographic Layers in such a message are rooted in parts "H", 462 "L", and "N". But the Cryptographic Envelope of the message consists 463 only of the properties derived from the series "H", "L". The 464 Cryptographic Payload of the message is part "M". 466 It is NOT RECOMMENDED to generate messages with such complicated 467 structures. Even if a receiving MUA can parse this structure 468 properly, it is nearly impossible to render in a way that the user 469 can reason about the cryptographic properties of part "O" compared to 470 part "Q". 472 3.4. Exposed Headers are Outside 474 The Cryptographic Envelope fully encloses the Cryptographic Payload, 475 whether the message is signed or encrypted or both. The Exposed 476 Headers are considered to be outside of both. 478 4. Message Composition 480 This section describes the composition of a cryptographically- 481 protected message with Protected Headers. 483 We document legacy composition of cryptographically-protected 484 messages (without protected headers) in Section 4.4, and then 485 describe a revised version of that algorithm in Section 4.5 that 486 produces conformant Protected Headers. 488 4.1. Copying All Headers 490 All non-structural headers known to the composing MUA are copied to 491 the MIME header of the Cryptographic Payload. The composing MUA 492 SHOULD protect all known non-structural headers in this way. 494 If the composing MUA omits protection for some of the headers, the 495 receiving MUA will have difficulty reasoning about the integrity of 496 the headers (see Section 11.2). 498 4.2. Confidential Subject 500 When a message is encrypted, the Subject should be obscured by 501 replacing the Exposed Subject with three periods: "..." 503 This value ("...") was chosen because it is believed to be language 504 agnostic and avoids communicating any potentially misleading 505 information to the recipient (see Section 7.1 for a more detailed 506 discussion). 508 4.3. Obscured Headers 510 Due to compatibility and usability concerns, a Mail User Agent SHOULD 511 NOT obscure any of: "From", "To", "Cc", "Message-ID", "References", 512 "Reply-To", "In-Reply-To", (FIXME: MORE?) unless the user has 513 indicated they have security constraints which justify the potential 514 downsides (see Section 7 for a more detailed discussion). 516 Aside from that limitation, this specification does not at this time 517 define or limit the methods a MUA may use to convert Exposed Headers 518 into Obscured Headers. 520 4.4. Message Composition without Protected Headers 522 This section roughly describes the steps that a legacy MUA might use 523 to compose a cryptographically-protected message _without_ Protected 524 Headers. 526 The message composition algorithm takes three parameters: 528 * "origbody": the traditional unprotected message body as a well- 529 formed MIME tree (possibly just a single MIME leaf part). As a 530 well-formed MIME tree, "origbody" already has structural headers 531 present (see Section 1.2.2). 533 * "origheaders": the intended non-structural headers for the 534 message, represented here as a table mapping from header names to 535 header values.. For example, "origheaders['From']" refers to the 536 value of the "From" header that the composing MUA would typically 537 place on the message before sending it. 539 * "crypto": The series of cryptographic protections to apply (for 540 example, "sign with the secret key corresponding to OpenPGP 541 certificate X, then encrypt to OpenPGP certificates X and Y"). 542 This is a routine that accepts a MIME tree as input (the 543 Cryptographic Payload), wraps the input in the appropriate 544 Cryptographic Envelope, and returns the resultant MIME tree as 545 output, 547 The algorithm returns a MIME object that is ready to be injected into 548 the mail system: 550 * Apply "crypto" to "origbody", yielding MIME tree "output" 552 * For header name "h" in "origheaders": 554 - Set header "h" of "output" to "origheaders[h]" 556 * Return "output" 558 4.5. Message Composition with Protected Headers 560 A reasonable sequential algorithm for composing a message _with_ 561 protected headers takes two more parameters in addition to 562 "origbody", "origheaders", and "crypto": 564 * "obscures": a table of headers to be obscured during encryption, 565 mapping header names to their obscuring values. For example, this 566 document recommends only obscuring the subject, so that would be 567 represented by the single-entry table "obscures = {'Subject': 569 '...'}". If header "Foo" is to be deleted entirely, 570 "obscures['Foo']" should be set to the special value "null". 572 * "legacy": a boolean value, indicating whether any recipient of the 573 message is believed to have a legacy client (that is, a MUA that 574 is capable of decryption, but does not understand protected 575 headers). 577 The revised algorithm for applying cryptographic protection to a 578 message is as follows: 580 * if "crypto" contains encryption, and "legacy" is "true", and 581 "obscures" contains any user-facing headers (see Section 1.2.1), 582 wrap "orig" in a structure that carries a Legacy Display part: 584 - Create a new MIME leaf part "legacydisplay" with header 585 "Content-Type: text/plain; protected-headers="v1"" 587 - For each obscured header name "obh" in "obscures": 589 o If "obh" is user-facing: 591 + Add "obh: origheaders[ob]" to the body of 592 "legacydisplay". For example, if 593 "origheaders['Subject']" is "lunch plans?", then add the 594 line "Subject: lunch plans?" to the body of 595 "legacydisplay" 597 - Construct a new MIME part "wrapper" with "Content-Type: 598 multipart/mixed" 600 - Give "wrapper" exactly two subparts: "legacydisplay" and 601 "origbody", in that order. 603 - Let "payload" be MIME part "wrapper" 605 * Otherwise: 607 - Let "payload" be MIME part "origbody" 609 * For each header name "h" in "origheaders": 611 - Set header "h" of MIME part "payload" to "origheaders[h]" 613 * Set the "protected-headers" parameter on the "Content-Type" of 614 "payload" to "v1" 616 * Apply "crypto" to "payload", producing MIME tree "output" 617 * If "crypto" contains encryption: 619 - For each obscured header name "obh" in "obscures": 621 o If "obscures[obh]" is "null": 623 + Drop "obh" from "origheaders" 625 o Else: 627 + Set "origheaders[obh]" to "obscures[obh]" 629 * For each header name "h" in "origheaders": 631 - Set header "h" of "output" to "origheaders[h]" 633 * return "output" 635 Note that both new parameters, "obscured" and "legacy", are 636 effectively ignored if "crypto" does not contain encryption. This is 637 by design, because they are irrelevant for signed-only cryptographic 638 protections. 640 5. Legacy Display 642 MUAs typically display user-facing headers (Section 1.2.1) directly 643 to the user. An encrypted message may be read by a decryption- 644 capable legacy MUA that is unaware of this standard. The user of 645 such a legacy client risks losing access to any obscured headers. 647 This section presents a workaround to mitigate this risk by 648 restructuring the Cryptographic Payload before encrypting to include 649 a "Legacy Display" part. 651 5.1. Message Generation: Including a Legacy Display Part 653 A generating MUA that wants to make an Obscured Subject (or any other 654 user-facing header) visible to a recipient using a legacy MUA SHOULD 655 modify the Cryptographic Payload by wrapping the intended body of the 656 message in a "multipart/mixed" MIME part that prefixes the intended 657 body with a Legacy Display part. 659 The Legacy Display part MUST be of Content-Type "text/plain" or 660 "text/rfc822-headers" ("text/plain" is RECOMMENDED), and MUST contain 661 a "protected-headers" parameter whose value is "v1". It SHOULD be 662 marked with "Content-Disposition: inline" to encourage recipients to 663 render it. 665 The contents of the Legacy Display part MUST be only the user-facing 666 headers that the sending MUA intends to obscure after encryption. 668 The original body (now a subpart) SHOULD also be marked with 669 "Content-Disposition: inline" to discourage legacy clients from 670 presenting it as an attachment. 672 5.1.1. Legacy Display Transformation 674 Consider a message whose Cryptographic Payload, before encrypting, 675 that would have a traditional "multipart/alternative" structure: 677 X └┬╴multipart/alternative 678 Y ├─╴text/plain 679 Z └─╴text/html 681 When adding a Legacy Display part, this structure becomes: 683 V └┬╴multipart/mixed 684 W ├─╴text/plain ("Legacy Display" part) 685 X └┬╴multipart/alternative ("original body") 686 Y ├─╴text/plain 687 Z └─╴text/html 689 Note that with the inclusion of the Legacy Display part, the 690 Cryptographic Payload is the "multipart/mixed" part (part "V" in the 691 example above), so Protected Headers should be placed at that part. 693 5.1.2. When to Generate Legacy Display 695 A MUA SHOULD transform a Cryptographic Payload to include a Legacy 696 Display part only when: 698 * The message is going to be encrypted, and 700 * At least one user-facing header (see Section 1.2.1) is going to be 701 obscured 703 Additionally, if the sender knows that the recipient's MUA is capable 704 of interpreting Protected Headers, it SHOULD NOT attempt to include a 705 Legacy Display part. (Signalling such a capability is out of scope 706 for this document) 708 5.2. Message Rendering: Omitting a Legacy Display Part 710 A MUA that understands Protected Headers may receive an encrypted 711 message that contains a Legacy Display part. Such an MUA SHOULD 712 avoid rendering the Legacy Display part to the user at all, since it 713 is aware of and can render the actual Protected Headers. 715 If a Legacy Display part is detected, the Protected Headers should 716 still be pulled from the Cryptographic Payload (part "V" in the 717 example above), but the body of message SHOULD be rendered as though 718 it were only the original body (part "X" in the example above). 720 5.2.1. Legacy Display Detection Algorithm 722 A receiving MUA acting on a message SHOULD detect the presence of a 723 Legacy Display part and the corresponding "original body" with the 724 following simple algorithm: 726 * Check that all of the following are true for the message: 728 * The Cryptographic Envelope must contain an encrypting 729 Cryptographic Layer 731 * The Cryptographic Payload must have a "Content-Type" of 732 "multipart/mixed" 734 * The Cryptographic Payload must have exactly two subparts 736 * The first subpart of the Cryptographic Payload must have a 737 "Content-Type" of "text/plain" or "text/rfc822-headers" 739 * The first subpart of the Cryptographic Payload's "Content-Type" 740 must contain a property of "protected-headers", and its value must 741 be "v1". 743 * If all of the above are true, then the first subpart is the Legacy 744 Display part, and the second subpart is the "original body". 745 Otherwise, the message does not have a Legacy Display part. 747 5.3. Legacy Display is Decorative and Transitional 749 As the above makes clear, the Legacy Display part is strictly 750 decorative, for the benefit of legacy decryption-capable MUAs that 751 may handle the message. As such, the existence of the Legacy Display 752 part and its "multipart/mixed" wrapper are part of a transition plan. 754 As the number of decryption-capable clients that understand Protected 755 Headers grows in comparison to the number of legacy decryption- 756 capable clients, it is expected that some senders will decide to stop 757 generating Legacy Display parts entirely. 759 A MUA developer concerned about accessiblity of the Subject header 760 for their users of encrypted mail when Legacy Display parts are 761 omitted SHOULD implement the Protected Headers scheme described in 762 this document. 764 6. Message Interpretation 766 This document does not currently provide comprehensive 767 recommendations on how to interpret Protected Headers. This is 768 deliberate; research and development is still ongoing. We also 769 recognize that the tolerance of different user groups for false 770 positives (benign conditions misidentified as security risks), vs. 771 their need for strong protections varies a great deal and different 772 MUAs will take different approaches as a result. 774 Some common approaches are discussed below. 776 6.1. Reverse-Copying 778 One strategy for interpreting Protected Headers on an incoming 779 message is to simply ignore any Exposed Header for which a Protected 780 counterpart is available. This is often implemented as a copy 781 operation (copying header back out of the Cryptographic Payload into 782 the main message header) within the code which takes care of parsing 783 the message. 785 A MUA implementing this strategy should pay special attention to any 786 user facing headers (Section 1.2.1). If a message has Protected 787 Headers, and a user-facing header is among the Exposed Headers but 788 missing from the Protected Headers, then an MUA implementing this 789 strategy SHOULD delete the identified Exposed Header before 790 presenting the message to the user. 792 This strategy does not risk raising a false alarm about harmless 793 deviations, but conversely it does nothing to inform the user if they 794 are under attack. This strategy does successfully mitigate and 795 thwart some attacks, including signature replay attacks 796 (Section 11.2) and participant modification attacks (Section 11.3). 798 6.2. Signature Invalidation 800 An alternate strategy for interpreting Protected Headers is to 801 consider the cryptographic signature on a message to be invalid if 802 the Exposed Headers deviate from their Protected counterparts. 804 This state should be presented to the user using the same interface 805 as other signature verification failures. 807 A MUA implementing this strategy MAY want to make a special exception 808 for the "Subject:" header, to avoid invalidating the signature on any 809 signed and encrypted message with a confidential subject. 811 Note that simple signature invalidation may be insufficient to defend 812 against a participant modification attack (Section 11.3). 814 6.3. The Legacy Display Part 816 This part is purely decorative, for the benefit of any recipient 817 using a legacy decryption-capable MUA. See Section 5.2 for details 818 and recommendations on how to handle the Legacy Display part. 820 6.4. Replying to a Message with Obscured Headers 822 When replying to a message, many MUAs copy headers from the original 823 message into their reply. 825 When replying to an encrypted message, users expect the replying MUA 826 to generate an encrypted message if possible. If encryption is not 827 possible, and the reply will be cleartext, users typically want the 828 MUA to avoid leaking previously-encrypted content into the cleartext 829 of the reply. 831 For this reason, an MUA replying to an encrypted message with 832 Obscured Headers SHOULD NOT leak the cleartext of any Obscured 833 Headers into the cleartext of the reply, whether encrypted or not. 835 In particular, the contents of any Obscured Protected Header from the 836 original message SHOULD NOT be placed in the Exposed Headers of the 837 reply message. 839 7. Common Pitfalls and Guidelines 841 Among the MUA authors who already implemented most of this 842 specification, several alternative or more encompassing 843 specifications were discussed and sometimes tried out in practice. 844 This section highlights a few "pitfalls" and guidelines based on 845 these discussions and lessons learned. 847 7.1. Misunderstood Obscured Subjects 849 There were many discussions around what text phrase to use to obscure 850 the "Subject:". Text phrases such as "Encrypted Message" were tried 851 but resulted in both localization problems and user confusion. 853 If the natural language phrase for the obscured "Subject:" is not 854 localized (e.g. just English "Encrypted Message"), then it may be 855 incomprehensible to a non-English-speaking recipient who uses a 856 legacy MUA that renders the obscured "Subject:" directly. 858 On the other hand, if it is localized based on the sender's MUA 859 language settings, there is no guarantee that the recipient prefers 860 the same language as the sender (consider a German speaker sending 861 English text to an Anglophone). There is no standard way for a 862 sending MUA to infer the language preferred by the recipient (aside 863 from statistical inference of language based on the composed message, 864 which would in turn leak information about the supposedly- 865 confidential message body). 867 Furthermore, implementors found that the phrase "Encrypted Message" 868 in the subject line was sometimes understood by users to be an 869 indication from the MUA that the message was actually encrypted. In 870 practice, when some MUA failed to encrypt a message in a thread that 871 started off with an obscured "Subject:", the value "Re: Encrypted 872 Message" was retained even on those cleartext replies, resulting in 873 user confusion. 875 In contrast, using "..." as the obscured "Subject:" was less likely 876 to be seen as an indicator from the MUA of message encryption, and it 877 also neatly sidesteps the localization problems. 879 7.2. Reply/Forward Losing Subjects 881 When the user of a legacy MUA replies to or forwards a message where 882 the Subject has been obscured, it is likely that the new subject will 883 be "Fwd: ..." or "Re: ..." (or the localized equivalent). This 884 breaks an important feature: people are used to continuity of subject 885 within a thread. It is especially unfortunate when a new participant 886 is added to a conversation who never saw the original subject. 888 At this time, there is no known workaround for this problem. The 889 only solution is to upgrade the MUA to support Protected Headers. 891 The authors consider this to be only a minor concern in cases where 892 encryption is being used because confidentiality is important. 893 However, in more opportunistic cases, where encryption is being used 894 routinely regardless of the sensitivity of message contents, this 895 cost becomes higher. 897 7.3. Usability Impact of Reduced Metadata 899 Many mail user agents maintain an index of message metadata 900 (including header data), which is used to rapidly construct mailbox 901 overviews and search result listings. If the process which generates 902 this index does not have access to the encrypted payload of a 903 message, or does not implement Protected Headers, then the index will 904 only contain the obscured versions Exposed Headers, in particular an 905 obscured Subject of "...". 907 For sensitive message content, especially in a hosted MUA-as- 908 a-service situation ("webmail") where the metadata index is 909 maintained and stored by a third party, this may be considered a 910 feature as the subject is protected from the third-party. However, 911 for more routine communications, this harms usability and goes 912 against user expectations. 914 Two simple workarounds exist for this use case: 916 1. If the metadata index is considered secure enough to handle 917 confidential data, the protected content may be stored directly 918 in the index once it has been decrypted. 920 2. If the metadata index is not trusted, the protected content could 921 be re-encrypted and encrypted versions stored in the index 922 instead, which are then decrypted by the client at display time. 924 In both cases, the process which decrypts the message and processes 925 the Protected Headers must be able to update the metadata index. 927 FIXME: add notes about research topics and other non-simple 928 workarounds, like oblivious server-side indexing, or searching on 929 encrypted data. 931 7.4. Usability Impact of Obscured Message-ID 933 Current MUA implementations rely on the outermost Message-ID for 934 message processing and indexing purposes. This processing often 935 happens before any decryption is even attempted. Attempting to send 936 a message with an obscured Message-ID header would result in several 937 MUAs not correctly processing the message, and would likely be seen 938 as a degradation by users. 940 Furthermore, a legacy MUA replying to a message with an obscured 941 "Message-ID:" would be likely to produce threading information 942 ("References:", "In-Reply-To:") that would be misunderstood by the 943 original sender. Implementors generally disapprove of breaking 944 threads. 946 7.5. Usability Impact of Obscured From/To/Cc 948 The impact of obscuring "From:", "To:", and "Cc:" headers has similar 949 issues as discussed with obscuring the "Message-ID:" header in 950 Section 7.4. 952 In addition, obscuring these headers is likely to cause difficulties 953 for a legacy client attempting formulate a correct reply (or "reply 954 all") to a given message. 956 7.6. Mailing List Header Modifications 958 Some popular mailing-list implementations will modify the Exposed 959 Headers of a message in specific, benign ways. In particular, it is 960 common to add markers to the "Subject" line, and it is also common to 961 modify either "From" or "Reply-To" in order to make sure replies go 962 to the list instead of directly to the author of an individual post. 964 Depending on how the MUA resolves discrepancies between the Protected 965 Headers and the Exposed Headers of a received message, these mailing 966 list "features" may either break or the MUA may incorrectly interpret 967 them as a security breach. 969 Implementors may for this reason choose to implement slightly 970 different strategies for resolving discrepancies, if a message is 971 known to come from such a mailing list. MUAs should at the very 972 least avoid presenting false alarms in such cases. 974 8. Comparison with Other Header Protection Schemes 976 Other header protection schemes have been proposed (in the IETF and 977 elsewhere) that are distinct from this mechanism. This section 978 documents the differences between those earlier mechanisms and this 979 one, and hypothesizes why it has seen greater interoperable adoption. 981 The distinctions include: 983 * backward compatibility with legacy clients 985 * compatibility across PGP/MIME and S/MIME 987 * protection for both confidentiality and signing 989 8.1. S/MIME 3.1 Header Protection 991 S/MIME 3.1 ([RFC3851]) introduces header protection via "message/ 992 rfc822" header parts. 994 The problem with this mechanism is that many legacy clients 995 encountering such a message were likely to interpret it as either a 996 forwarded message, or as an unreadable substructure. 998 For signed messages, this is particularly problematic - a message 999 that would otherwise have been easily readable by a client that knows 1000 nothing about signed messages suddenly shows up as a message-within- 1001 a-message, just by virtue of signing. This has an impact on _all_ 1002 clients, whether they are cryptographically-capable or not. 1004 For encrypted messages, whose interpretation only matters on the 1005 smaller set of cryptographically-capable legacy clients, the 1006 resulting message rendering is awkward at best. 1008 Furthermore, formulating a reply to such a message on a legacy client 1009 can also leave the user with badly-structured quoted and attributed 1010 content. 1012 Additionally, a message deliberately forwarded in its own right 1013 (without preamble or adjacent explanatory notes) could potentially be 1014 confused with a message using the declared structure. 1016 The mechanism described here allows cryptographically-incapable 1017 legacy MUAs to read and handle cleartext signed messages without any 1018 modifications, and permits cryptographically-capable legacy MUAs to 1019 handle encrypted messages without any modifications. 1021 In particular, the Legacy Display part described in Section 5 makes 1022 it feasible for a conformant MUA to generate messages with obscured 1023 Subject lines that nonetheless give access to the obscured Subject 1024 header for recipients with legacy MUAs. 1026 8.2. The Content-Type Property "forwarded=no" {forwarded=no} 1028 Section A.1.2 of 1029 [I-D.draft-ietf-lamps-header-protection-requirements-01] refers to a 1030 proposal that attempts to mitigate one of the drawbacks of the scheme 1031 described in S/MIME 3.1 (Section 8.1). 1033 In particular, using the Content-Type property "forwarded="no"" 1034 allows _non-legacy_ clients to distinguish between deliberately 1035 forwarded messages and those intended to use the defined structure 1036 for header protection. 1038 However, this fix has no impact on the confusion experienced by 1039 legacy clients. 1041 8.3. pEp Header Protection 1043 [I-D.draft-luck-lamps-pep-header-protection-03] is applicable only to 1044 signed+encrypted mail, and does not contemplate protection of signed- 1045 only mail. 1047 In addition, the pEp header protection involved for "pEp message 1048 format 2" has an additional "multipart/mixed" layer designed to 1049 facilitate transfer of OpenPGP Transferable Public Keys, which seems 1050 orthogonal to the effort to protect headers. 1052 Finally, that draft suggests that the exposed Subject header be one 1053 of "=?utf-8?Q?p=E2=89=A1p?=", "pEp", or "Encrypted message". "pEp" is 1054 a mysterious choice for most users, and see Section 7.1 for more 1055 commentary on why "Encrypted message" is likely to be problematic. 1057 8.4. DKIM 1059 [RFC6736] offers DKIM, which is often used to sign headers associated 1060 with a message. 1062 DKIM is orthogonal to the work described in this document, since it 1063 is typically done by the domain operator and not the end user 1064 generating the original message. That is, DKIM is not "end-to-end" 1065 and does not represent the intent of the entity generating the 1066 message. 1068 Furthermore, a DKIM signer does not have access to headers inside an 1069 encrypted Cryptographic Layer, and a DKIM verifier cannot effectively 1070 use DKIM to verify such confidential headers. 1072 8.5. S/MIME "Secure Headers" 1074 [RFC7508] describes a mechanism that embeds message header fields in 1075 the S/MIME signature using ASN.1. 1077 The mechanism proposed in that draft is undefined for use with PGP/ 1078 MIME. While all S/MIME clients must be able to handle CMS and ASN.1 1079 as well as MIME, a standard that works at the MIME layer itself 1080 should be applicable to any MUA that can work with MIME, regardess of 1081 whether end-to-end security layers are provided by S/MIME or PGP/ 1082 MIME. 1084 That mechanism also does not propose a means to provide 1085 confidentiality protection for headers within an encrypted-but-not- 1086 signed message. 1088 Finally, that mechanism offers no equivalent to the Legacy Display 1089 described in Section 5. Instead, sender and receiver are expected to 1090 negotiate in some unspecified way to ensure that it is safe to remove 1091 or modify Exposed Headers in an encrypted message. 1093 8.6. Triple-Wrapping 1095 [RFC2634] defines "Triple Wrapping" as a means of providing cleartext 1096 signatures over signed and encrypted material. This can be used in 1097 combination with the mechanism described in [RFC7508] to authenticate 1098 some headers for transport using S/MIME. 1100 But it does not offer confidentiality protection for the protected 1101 headers, and the signer of the outer layer of a triple-wrapped 1102 message may not be the originator of the message either. 1104 In practice on today's Internet, DKIM ([RFC6736] provides a more 1105 widely-accepted cryptographic header-verification-for-transport 1106 mechanism than triple-wrapped messages. 1108 9. Test Vectors 1110 The subsections below provide example messages that implement the 1111 Protected Header scheme. 1113 The secret keys and OpenPGP certificates from 1114 [I-D.draft-bre-openpgp-samples-00] can be used to decrypt and verify 1115 the PGP/MIME messages. 1117 The secret keys and X.509 certificates from 1118 [I-D.draft-dkg-lamps-samples-01] can be used to decrypt and verify 1119 the S/MIME messages. 1121 All test vectors are provided in textual source form as [RFC5322] 1122 messages. 1124 For easy access to these test vectors, they are also available at 1125 "imap://bob@protected-headers.cmrg.net/inbox" using any password for 1126 authentication. This IMAP account is read-only, and any flags set or 1127 cleared on the messages will persist only for the duration of the 1128 specific IMAP session. 1130 9.1. Signed PGP/MIME Message with Protected Headers 1132 This shows a clearsigned PGP/MIME message. Its MIME message 1133 structure is: 1135 └┬╴multipart/signed 1136 ├─╴text/plain ← Cryptographic Payload 1137 └─╴application/pgp-signature 1139 Note that if this message had been generated without Protected 1140 Headers, then an attacker with access to it could modify the Subject 1141 without invalidating the signature. Such an attacker could cause Bob 1142 to think that Alice wanted to cancel the contract with BarCorp 1143 instead of FooCorp. 1145 Received: from localhost (localhost [127.0.0.1]); Sun, 20 Oct 2019 1146 09:00:17 -0400 (UTC-04:00) 1147 MIME-Version: 1.0 1148 Content-Type: multipart/signed; boundary="fee"; 1149 protocol="application/pgp-signature"; micalg="pgp-sha512" 1150 From: Alice Lovelace 1151 To: Bob Babbage 1152 Date: Sun, 20 Oct 2019 09:00:00 -0400 1153 Subject: The FooCorp contract 1154 Message-ID: 1156 --fee 1157 Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" 1158 From: Alice Lovelace 1159 To: Bob Babbage 1160 Date: Sun, 20 Oct 2019 09:00:00 -0400 1161 Subject: The FooCorp contract 1162 Message-ID: 1164 Bob, we need to cancel this contract. 1166 Please start the necessary processes to make that happen today. 1168 (this is the 'pgpmime-signed' message) 1170 Thanks, Alice 1171 -- 1172 Alice Lovelace 1173 President 1174 Example Corp 1176 --fee 1177 content-type: application/pgp-signature 1179 -----BEGIN PGP SIGNATURE----- 1181 wnUEARYKAB0FAl2sWlAWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj 1182 jtl0AQDtIsRWZVCjbB3TISlcyxLpBfwjaXXV0is5+c4Gd2NNgwEAipDF3m5zIt7t 1183 29cFwQusmCqKqKfdJUf6HOUPF5L/zAI= 1184 =+M9u 1185 -----END PGP SIGNATURE----- 1187 --fee-- 1189 9.2. S/MIME multipart/signed Message with Protected Headers 1191 This shows a signed-only S/MIME message using the "multipart/signed" 1192 style (see Section 3.5.3 of [RFC8551]). Its MIME message structure 1193 is: 1195 └┬╴multipart/signed 1196 ├─╴text/plain ← Cryptographic Payload 1197 └─╴application/pkcs7-signature 1199 Note that if this message had been generated without Protected 1200 Headers, then an attacker with access to it could modify the Subject 1201 without invalidating the signature. Such an attacker could cause Bob 1202 to think that Alice wanted to cancel the contract with BarCorp 1203 instead of FooCorp. 1205 Received: from localhost (localhost [127.0.0.1]); Tue, 26 Nov 2019 1206 20:03:17 -0400 (UTC-04:00) 1207 MIME-Version: 1.0 1208 Content-Type: multipart/signed; boundary="179"; 1209 protocol="application/pkcs7-signature"; micalg="sha-256" 1210 From: Alice Lovelace 1211 To: Bob Babbage 1212 Date: Tue, 26 Nov 2019 20:03:00 -0400 1213 Subject: The FooCorp contract 1214 Message-ID: 1216 --179 1217 Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" 1218 From: Alice Lovelace 1219 To: Bob Babbage 1220 Date: Tue, 26 Nov 2019 20:03:00 -0400 1221 Subject: The FooCorp contract 1222 Message-ID: 1224 Bob, we need to cancel this contract. 1226 Please start the necessary processes to make that happen today. 1228 (this is the 'smime-multipart-signed' message) 1230 Thanks, Alice 1231 -- 1232 Alice Lovelace 1233 President 1234 Example Corp 1236 --179 1237 Content-Transfer-Encoding: base64 1238 Content-Type: application/pkcs7-signature; name="smime.p7s" 1240 MIIFhQYJKoZIhvcNAQcCoIIFdjCCBXICAQExDTALBglghkgBZQMEAgEwCwYJKoZI 1241 hvcNAQcBoIIDcjCCA24wggJWoAMCAQICFGeCtFlzUkvB9HFHGWrw/RGKqkwLMA0G 1242 CSqGSIb3DQEBDQUAMC0xKzApBgNVBAMTIlNhbXBsZSBMQU1QUyBDZXJ0aWZpY2F0 1243 ZSBBdXRob3JpdHkwIBcNMTkxMTIwMDY1NDE4WhgPMjA1MjA5MjcwNjU0MThaMBkx 1244 FzAVBgNVBAMTDkFsaWNlIExvdmVsYWNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A 1245 MIIBCgKCAQEAw+6t+WXRtiQM8yRjWQ2fbFewCodIZUX6BY02TeZuEXoEAGEsmoON 1246 6LlotcUTdGr39FE2K8IytOKkXVexswgAqBCqv8YjVDrI3yV82wrm5Td32TDlw7IS 1247 igak4ZSu+UowPQs8YO3oxqImP4onZNHvdZ3it9EggmgUyZX0dmQ6z5O9yDzHpLMa 1248 E2rXxfYcPXQwPvx4tcqbTf2htEP7PYnBa8a+sts0F7I7kD5ozGYI9dGg/XGs1lYE 1249 WAoH5YZgNFdbkJdcKG2FPAwFcVZ/hoGm6soxkDKMrYSCtBp+fqH8MV11DP821PoO 1250 vtSEnaF8UURbaths2yKpAB2WUJvgW5xa4QIDAQABo4GXMIGUMAwGA1UdEwEB/wQC 1251 MAAwHgYDVR0RBBcwFYETYWxpY2VAc21pbWUuZXhhbXBsZTATBgNVHSUEDDAKBggr 1252 BgEFBQcDBDAPBgNVHQ8BAf8EBQMDB6AAMB0GA1UdDgQWBBSsLlRapP1VGK8u6GZE 1253 ONEl0dcAeTAfBgNVHSMEGDAWgBS3Uk1zwIg9ssN6WgzzlPf3gKJ32zANBgkqhkiG 1254 9w0BAQ0FAAOCAQEAe+qOGM+8q1UhXKV6i63BrXSOKvd2iglxAggszUC6eMnrIem6 1255 6mmRzSbcGHCeU6m1MpvYSe9IiROIxjTfsgGUdZbbXtBxSmCASjOBCbphvvtoam1G 1256 i8+LZdOgR2kDwr//TYjWO6vUfXPwerNWMx4cKpFobdmvgLYCeAZKRvoPjJmTEFfw 1257 KO0cCxSifTpTFiwZhFxXKSCTdB6T2rE9JxJfzJqLUrvvEZwpQIt8hX8kym/vKw+1 1258 cbsl3rag2enVP/f4qg/0mUuzkCI8sLXd+N5gAs9wdUZRcTB0gOnUAH9m7RrpqkdC 1259 ogKdypGEQHj6GiamJAe2WndOp4BZdBtBRzjfuzGCAdkwggHVAgEBMEUwLTErMCkG 1260 A1UEAxMiU2FtcGxlIExBTVBTIENlcnRpZmljYXRlIEF1dGhvcml0eQIUZ4K0WXNS 1261 S8H0cUcZavD9EYqqTAswCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqG 1262 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMTI3MDAwMzAwWjAvBgkqhkiG9w0B 1263 CQQxIgQgGeoQw8WDmjB606EKGR5n1oMuV7Te1VjfA2oB2ebW390wDQYJKoZIhvcN 1264 AQEBBQAEggEABblYEWSnYyzL3jTS3AoPr93YKksIZr5q/b8Y5/1rMxdYxPm+iReO 1265 RHRgpbFQeiqZXzRXtMohfoIkh7RmdQoSV4OpwiUmNU+f0ZEAu8cMVJM6gdyUD+1D 1266 JwDNr+YNLV/1UUGhqx0FExOa/4O92KYBD4eRQw4KDWrkfh9dlSj0Bsl4thrZYGLz 1267 e7ut3FN5TBruZfmqMy50xZ9yUW91YyQUBLiIcuF185y5ZW/aQCxBKBbrNNGXLJbo 1268 8yKFJqSPiWZvwUmVQvfgL182hg823OJTtP4VImcUakTF0+k+BM//qqKXYrlX/tZn 1269 QzG+4ZH/XM1vgHl7ShjHS6TSOHz2ODqD6Q== 1271 --179-- 1273 9.3. S/MIME application/pkcs7-mime SignedData Message with Protected 1274 Headers 1276 This shows a signed-only S/MIME message using the "multipart/ 1277 pkcs7-mime" style (see Section 3.5.2 of [RFC8551]). Its MIME message 1278 structure is: 1280 └─╴application/pkcs7-mime smime-type="signed-data" 1281 ⇩ (unwraps to) 1282 └─╴text/plain ← Cryptographic Payload 1284 Note that if this message had been generated without Protected 1285 Headers, then an attacker with access to it could modify the Subject 1286 without invalidating the signature. Such an attacker could cause Bob 1287 to think that Alice wanted to cancel the contract with BarCorp 1288 instead of FooCorp. 1290 Received: from localhost (localhost [127.0.0.1]); Tue, 26 Nov 2019 1291 20:06:17 -0400 (UTC-04:00) 1292 Content-Transfer-Encoding: base64 1293 Content-Type: application/pkcs7-mime; name="smime.p7m"; 1294 smime-type="signed-data" 1295 MIME-Version: 1.0 1296 From: Alice Lovelace 1297 To: Bob Babbage 1298 Date: Tue, 26 Nov 2019 20:06:00 -0400 1299 Subject: The FooCorp contract 1300 Message-ID: 1302 MIIHhQYJKoZIhvcNAQcCoIIHdjCCB3ICAQExDTALBglghkgBZQMEAgEwggIJBgkq 1303 hkiG9w0BBwGgggH6BIIB9kNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNl 1304 dD0idXMtYXNjaWkiOyBwcm90ZWN0ZWQtaGVhZGVycz0idjEiDQpGcm9tOiBBbGlj 1305 ZSBMb3ZlbGFjZSA8YWxpY2VAc21pbWUuZXhhbXBsZT4NClRvOiBCb2IgQmFiYmFn 1306 ZSA8Ym9iQHNtaW1lLmV4YW1wbGU+DQpEYXRlOiBUdWUsIDI2IE5vdiAyMDE5IDIw 1307 OjA2OjAwIC0wNDAwDQpTdWJqZWN0OiBUaGUgRm9vQ29ycCBjb250cmFjdA0KTWVz 1308 c2FnZS1JRDogPHNtaW1lLW9uZXBhcnQtc2lnbmVkQHByb3RlY3RlZC1oZWFkZXJz 1309 LmV4YW1wbGU+DQoNCkJvYiwgd2UgbmVlZCB0byBjYW5jZWwgdGhpcyBjb250cmFj 1310 dC4NCg0KUGxlYXNlIHN0YXJ0IHRoZSBuZWNlc3NhcnkgcHJvY2Vzc2VzIHRvIG1h 1311 a2UgdGhhdCBoYXBwZW4gdG9kYXkuDQoNCih0aGlzIGlzIHRoZSAnc21pbWUtb25l 1312 cGFydC1zaWduZWQnIG1lc3NhZ2UpDQoNClRoYW5rcywgQWxpY2UNCi0tIA0KQWxp 1313 Y2UgTG92ZWxhY2UNClByZXNpZGVudA0KRXhhbXBsZSBDb3JwDQqgggNyMIIDbjCC 1314 AlagAwIBAgIUZ4K0WXNSS8H0cUcZavD9EYqqTAswDQYJKoZIhvcNAQENBQAwLTEr 1315 MCkGA1UEAxMiU2FtcGxlIExBTVBTIENlcnRpZmljYXRlIEF1dGhvcml0eTAgFw0x 1316 OTExMjAwNjU0MThaGA8yMDUyMDkyNzA2NTQxOFowGTEXMBUGA1UEAxMOQWxpY2Ug 1317 TG92ZWxhY2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD7q35ZdG2 1318 JAzzJGNZDZ9sV7AKh0hlRfoFjTZN5m4RegQAYSyag43ouWi1xRN0avf0UTYrwjK0 1319 4qRdV7GzCACoEKq/xiNUOsjfJXzbCublN3fZMOXDshKKBqThlK75SjA9Czxg7ejG 1320 oiY/iidk0e91neK30SCCaBTJlfR2ZDrPk73IPMeksxoTatfF9hw9dDA+/Hi1yptN 1321 /aG0Q/s9icFrxr6y2zQXsjuQPmjMZgj10aD9cazWVgRYCgflhmA0V1uQl1wobYU8 1322 DAVxVn+GgabqyjGQMoythIK0Gn5+ofwxXXUM/zbU+g6+1ISdoXxRRFtq2GzbIqkA 1323 HZZQm+BbnFrhAgMBAAGjgZcwgZQwDAYDVR0TAQH/BAIwADAeBgNVHREEFzAVgRNh 1324 bGljZUBzbWltZS5leGFtcGxlMBMGA1UdJQQMMAoGCCsGAQUFBwMEMA8GA1UdDwEB 1325 /wQFAwMHoAAwHQYDVR0OBBYEFKwuVFqk/VUYry7oZkQ40SXR1wB5MB8GA1UdIwQY 1326 MBaAFLdSTXPAiD2yw3paDPOU9/eAonfbMA0GCSqGSIb3DQEBDQUAA4IBAQB76o4Y 1327 z7yrVSFcpXqLrcGtdI4q93aKCXECCCzNQLp4yesh6brqaZHNJtwYcJ5TqbUym9hJ 1328 70iJE4jGNN+yAZR1ltte0HFKYIBKM4EJumG++2hqbUaLz4tl06BHaQPCv/9NiNY7 1329 q9R9c/B6s1YzHhwqkWht2a+AtgJ4BkpG+g+MmZMQV/Ao7RwLFKJ9OlMWLBmEXFcp 1330 IJN0HpPasT0nEl/MmotSu+8RnClAi3yFfyTKb+8rD7VxuyXetqDZ6dU/9/iqD/SZ 1331 S7OQIjywtd343mACz3B1RlFxMHSA6dQAf2btGumqR0KiAp3KkYRAePoaJqYkB7Za 1332 d06ngFl0G0FHON+7MYIB2TCCAdUCAQEwRTAtMSswKQYDVQQDEyJTYW1wbGUgTEFN 1333 UFMgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhRngrRZc1JLwfRxRxlq8P0RiqpMCzAL 1334 BglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 1335 DQEJBTEPFw0xOTExMjcwMDA2MDBaMC8GCSqGSIb3DQEJBDEiBCAKDM98nuDl98sK 1336 i4SDvP2xlxr2SdV/xNVYs6SeGCBRuTANBgkqhkiG9w0BAQEFAASCAQAcryWkSIbG 1337 rrc/aDF1Z4KRnoRpr+fOutQSLV7k0Tgezt+X/kJCIiuLvjUxLrTux1yUWCKUPb6T 1338 KLYASPJpwDXrNzqmGs1pJmWHTZwUhbFVXt16FaQZkDSATtvhQU39Rsot2j1pP/UV 1339 J7+5FPQwNc4dt7MFW7jU4TBHo2VrzjZ2K8ioELPxsixOCAp3ytkhf1Umw6bC5M/u 1340 oWjsa6xzAl4fw5+pxZw0JdbrYn5kmPiekSsYy2/+yOwzrtIYtHW5dY7DoWWXDXtD 1341 cmCGHkO8qry+MnMy3PwvXiX0warQo1fnhXB5tlk2K9YdiDcOtnAshEBXAudnxlPK 1342 JGzeJVUfbfM0 1344 Unwrapping the PKCS7 SignedData yields the following internal 1345 message: 1347 Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" 1348 From: Alice Lovelace 1349 To: Bob Babbage 1350 Date: Tue, 26 Nov 2019 20:06:00 -0400 1351 Subject: The FooCorp contract 1352 Message-ID: 1354 Bob, we need to cancel this contract. 1356 Please start the necessary processes to make that happen today. 1358 (this is the 'smime-onepart-signed' message) 1360 Thanks, Alice 1361 -- 1362 Alice Lovelace 1363 President 1364 Example Corp 1366 9.4. Signed and Encrypted PGP/MIME Message with Protected Headers 1368 This shows a simple encrypted PGP/MIME message with protected 1369 headers. The encryption also contains a signature in the OpenPGP 1370 Message structure. Its MIME message structure is: 1372 └┬╴multipart/encrypted 1373 ├─╴application/pgp-encrypted 1374 └─╴application/octet-stream 1375 ↧ (decrypts to) 1376 └─╴text/plain ← Cryptographic Payload 1378 The "Subject:" header is successfully obscured. 1380 Note that if this message had been generated without Protected 1381 Headers, then an attacker with access to it could have read the 1382 Subject. Such an attacker would know details about Alice and Bob's 1383 business that they wanted to keep confidential. 1385 The protected headers also protect the authenticity of subject line 1386 as well. 1388 The session key for this message's Cryptographic Layer is an AES-256 1389 key with value 1390 "8df4b2d27d5637138ac6de46415661be0bd01ed12ecf8c1db22a33cf3ede82f2" 1391 (in hex). 1393 If Bob's MUA is capable of interpreting these protected headers, it 1394 should render the "Subject:" of this message as "BarCorp contract 1395 signed, let's go!". 1397 Received: from localhost (localhost [127.0.0.1]); Mon, 21 Oct 2019 1398 07:09:28 -0700 (UTC-07:00) 1399 MIME-Version: 1.0 1400 Content-Type: multipart/encrypted; boundary="ca4"; 1401 protocol="application/pgp-encrypted" 1402 From: Alice Lovelace 1403 To: Bob Babbage 1404 Date: Mon, 21 Oct 2019 07:09:00 -0700 1405 Message-ID: 1406 Subject: ... 1408 --ca4 1409 content-type: application/pgp-encrypted 1411 Version: 1 1413 --ca4 1414 content-type: application/octet-stream 1416 -----BEGIN PGP MESSAGE----- 1418 wV4DR2b2udXyHrYSAQdAH1KRyK7qZzNpI7TVprCPo/aOTW9R5hBKcTkKES1Fo3Yw 1419 mtDplfGFN2JMzQ1OVbe2gbcyhrYfs+7Fd4eoZ0geE2cUYn5M951I0se1W+MdMZ/j 1420 wcDMA3wvqk35PDeyAQv/ePyXTBTU98wzM5LcwhWZcCmxCtTgqHmjJmymQKQqJuCA 1421 flrZPG6V6RyidGwmJYf2uDdmlhAHxFbYAalkI+/V3SnO5OSejKvspUtuRnBOW8Ps 1422 luWQ6ANww/o4y/2/SkIodRmwaIBbs/4CaDQivSeBueHnPu0EqxTBNI47dQx9mkdB 1423 Z5PsucuUVSq2SmdIrCM9aLyoUF60NVhdp3mYQaVH12dX19wjZtclTR74t66I/Wsc 1424 FHONiGii/ioJS9LGllnaRiS7carLbtw0s2yJJZPZeRozMPi0o8zgne77wdoF+NyU 1425 LkGtqXvLbPPA9SDGTHgkJ6H+wUhh0OGWebYwpN3F6R7Su1OlYRkQ8kokOmJmZokg 1426 qhDueENW2RsZIg06sydGFaRY5BoGe2EBkcXUVBWqYEMH3Zxz/kAEylVY5sZOqcae 1427 PAlvTF6Y4nNVGVylUvcuJ4DsQbi2AueD7Tl28ha1xJTkzlHlt4UyU878eUfdVLOM 1428 FF+hwbxlo6RBT4uurMee0sHrAUDHma9Kx6XrALINbIl5lfMKKXnKhfQYpfbYbz8J 1429 jVFz0zCxMqmdHZLe/G9mxoksvXrbFf8b5DHfDYGCRvbj+CzERo6KCceaVSpKVGL8 1430 xiwHrjg+vwfn9EG9j+vp3jB39wES/IZZThSnf0JvJA4ePVnfbxcxMqgg/S2isyHf 1431 NAp89ZlX5mznom9efKUoojodNNFsMIt+YNaHEtnjZl+BXstGkXXOiurEt5HuEyRz 1432 +cyjwpnQChz6PuY0Ehsj42mMyGa3167H2kIqtKtxIfl5/qm1df1mlEc7SpmU+uHV 1433 58D22bl/Ukr8vmFu09z7V2U7zXz+FtohuVpeTr3l0UVEFEGIQT4JUqxiavZqMsZE 1434 6DKj6X+fzXdxMyrDd/lD2ikZdllqTuvsuuiFW1OtEbuIKRoYUl6u8t44/KYoHCQK 1435 BWXhyh7lPpfOGkemA3KY0D7yG4caTWmN5GSskGyKqQjiCxa0jKqT1qfNBTxBh4/6 1436 8Ijf/cmlSNjC6ghzuwtNG7wr0mSC0pjQsl7b16Im7FOmP67pputqcFrZOIzVbrS8 1437 vVe0+1X3/5VnmYHCilaI41ln3wGRTlC/j4lIoGNGlJJ9LeOz0DlfIwfIy9aVUDXo 1438 48awW8hYu4Ck42GIJQP9HsQ9fbFzHmyUHhS4h+xGXHTbPFqiPyzsoAT8KDTLMj4y 1439 CKWaqmqXMkuaD7hMc42xW8ziq2ZXZCv1ajDclbkg5rx9R6n4dZL6Cajt7wK2mMHt 1440 giNkCqLU2LuPhw/R9comDDJPFmb6WB/PBrnTrUwrFy4/6du5uK09kwLIUu82UVhm 1441 5xHVqybxIkHGeVNXqRSe3M3w8ERbkXqNp3s7BrGGb1bYdlrPf8h1PTeWi9vfXUdn 1442 wFHr0g3xjeQ9orvJZl5jPuk5NryF2J/iNEh7+sE= 1443 =NT2A 1444 -----END PGP MESSAGE----- 1446 --ca4-- 1448 Unwrapping the Cryptographic Layer yields the following content: 1450 From: Alice Lovelace 1451 To: Bob Babbage 1452 Date: Mon, 21 Oct 2019 07:09:00 -0700 1453 Subject: BarCorp contract signed, let's go! 1454 Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" 1455 Message-ID: 1457 Hi Bob! 1459 I just signed the contract with BarCorp and they've set us up with 1460 an account on their system for testing. 1462 The account information is: 1464 Site: https://barcorp.example/ 1465 Username: examplecorptest 1466 Password: correct-horse-battery-staple 1468 Please get the account set up and apply the test harness. 1470 Let me know when you've got some results. 1472 (this is the 'pgpmime-sign+enc' message) 1474 Thanks, Alice 1475 -- 1476 Alice Lovelace 1477 President 1478 Example Corp 1480 9.5. Signed and Encrypted S/MIME Message with Protected Headers 1482 This shows a simple signed and encrypted S/MIME message with 1483 protected headers. Its MIME message structure is: 1485 └─╴application/pkcs7-mime smime-type="enveloped-data" 1486 ↧ (decrypts to) 1487 └─╴application/pkcs7-mime smime-type="signed-data" 1488 ⇩ (unwraps to) 1489 └─╴text/plain ← Cryptographic Payload 1491 The "Subject:" header is successfully obscured. 1493 Note that if this message had been generated without Protected 1494 Headers, then an attacker with access to it could have read the 1495 Subject. Such an attacker would know details about Alice and Bob's 1496 business that they wanted to keep confidential. 1498 The protected headers also protect the authenticity of subject line 1499 as well. 1501 The session key for this message's Cryptographic Layer is an AES-256 1502 key with value 1503 "12e2551896f77e24ce080153cda27dddd789d399bdd87757e65655d956f5f0b7" 1504 (in hex). 1506 If Bob's MUA is capable of interpreting these protected headers, it 1507 should render the "Subject:" of this message as "BarCorp contract 1508 signed, let's go!". 1510 Received: from localhost (localhost [127.0.0.1]); Wed, 27 Nov 2019 1511 01:15:28 -0700 (UTC-07:00) 1512 MIME-Version: 1.0 1513 Content-Transfer-Encoding: base64 1514 Content-Type: application/pkcs7-mime; name="smime.p7m"; 1515 smime-type="enveloped-data" 1516 From: Alice Lovelace 1517 To: Bob Babbage 1518 Date: Wed, 27 Nov 2019 01:15:00 -0700 1519 Message-ID: 1520 Subject: ... 1522 MIIPVQYJKoZIhvcNAQcDoIIPRjCCD0ICAQAxggLCMIIBXQIBADBFMC0xKzApBgNV 1523 BAMTIlNhbXBsZSBMQU1QUyBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCFCJT7jBtAgsf 1524 As31ycE+Ot95phvCMA0GCSqGSIb3DQEBAQUABIIBAKswTlBs+STeesZIYAf7Gqsj 1525 Za0rdUeDTSxt8RCa010EHb2lqKzHRwwPJkClLm6Glb09nYnQiFrEl6jbWTG3hMRD 1526 OSt9kyqeg+MxXr2g4LoXAT+8hg/qBoF//tX+bzxhx0gx8wjxBc3bvp4esCJro7Aq 1527 tx56BtVsIO6TA0NT0CaOcnMhIo09raR6JQX+DoPynKeXihny6TFDP7eopCgorCfR 1528 o59O3ZMvaui6Q9KixZy3Yae8fa0ZdJu3FahIZTPdBHzbmirLxcYgp+cbTpW+Yno2 1529 X5GJ8eq8Y0qcc/8r6Xd3REarUxO2YbO2D6cgDj+aNnnsoG1/9psaYl8W1MSc2/Qw 1530 ggFdAgEAMEUwLTErMCkGA1UEAxMiU2FtcGxlIExBTVBTIENlcnRpZmljYXRlIEF1 1531 dGhvcml0eQIUZ4K0WXNSS8H0cUcZavD9EYqqTAswDQYJKoZIhvcNAQEBBQAEggEA 1532 RHhTarDqNLzXSaBokp2L3EwDv11KiGtMSMUQuPelNoC2nNYU1yzAF4jd+1UUo4Uu 1533 quiHg5Hn44a9MejrVmQRLd5IEJiZGD8m5JguuOjn0ooyA6EEWUpMn6hOAKlaCiXd 1534 kwTivKfhQFJe9Eb6TKqtvT2IEu3kXFfJKi+VyQw49+RXBmajDKJoHtumMJs8k4Ll 1535 kJah+wD+snwHg2LCiJeSVHmpf4RvSiIJSvk206IeTxN3JecNbBpKLtIoy/CjWEZv 1536 G3Pj/zkBbb+XhHbXo+Zk/e3aLToVG/cldx6Ti8zArOYNAzgt1G7dmJ3mnNPitEwN 1537 O4qIozhT2Qn8P95AEV5PsDCCDHUGCSqGSIb3DQEHATAUBggqhkiG9w0DBwQIUzdf 1538 vwulBs+AggxQMK121v6lO7W1r96RW0rsOHzsIvGyfyRTT1UuZRxVL09BQZstI5ss 1539 5Zv8BogoKA0mLaNBKM755joUbzF5f/jMYhkW3q0Het9/HRH0mOnCSnoT4i2yzNdi 1540 0tj8ixPT4sgPe9FOTkke9CzoJ967kj9D8u7Ik2goojttt3ViJkv3a1qrWDMiJRIJ 1541 gOTTA6ZaQep5L92vtCobhD+i7iaktEpmbYucXs8jjMmwyxCFxHXGD/fwDk3UDgeu 1542 8a5f66YepZdbLKB61A3rBwJMvQubuXEIEb04tG0Fgwx3Ao2NshN+XRk/y+uhQKdC 1543 5ZduTxk5sokA+H4nzVv0IUkAAI+8FwY5ZWFGlncKUM/wvrGHQq3R/utChFauOHxD 1544 7vZQLM91TcQzVWdHfJGPtp+ekjRlu9UqatQgc1ogObw3PGYlJc90Gl7AZHAsYncU 1545 jsMbdsweuFuYNHJ8lR5VMo6L4bCNMy+tQBOfYTF1el+i9S3r3SWdBP+uLiKgDQ52 1546 /o4shxoi+YOf9k8wRR0iDKqwzcJuABplpgA9qjsQNqBKF5t5p3l3ihH1mfh8FaPL 1547 ab0aDC7uunY5g44qXcG9YS+j5wUFuxgYyGkVcJq3xIit9YbEy8uPxJFz4g0vNC+r 1548 uUSsztbLyHkhv7vnCTAlmjgG9eDpW/tEC/85pLOV1HUooD05eRfkjU+1XsccX8DG 1549 iCax2C6W3cc1SC/d3a1+27OcgvPdDcb7zuL3v6qgqbN+7GDrcQHQRFMd2vd6+xGk 1550 NWZQMBZVHmdCcKGl9YaH0RgkGH5beTRKEV1wBafuVOwTEwl/FuZzD4oHrOaP3GLO 1551 cLxi44her/hNxtxDc2Lw0VQcxD8A55OkCt9+u9M5/YPj41FWyH6kdh86p958gzF5 1552 EpwCnQDe+s7OrwFVV00DEJhqtEcxRCSSW8dS4hVEhVxQJ56liJP+VZ+LTUJBelt4 1553 mfSpSqxeJnmyY0nmhEbZKVbK95a1WYMJCEpk2n1g/bQGqJKRryGwbEF9WqqHuvPo 1554 Bv/BfinoUL3Kd3g+hgSCR4mCg5EhEsCx21jEqEggzb2XMcA+knGUYxSWj322pZfW 1555 LDh50gkL3GQSmm9fOvjdK40GwZv8HUdLXuAQ/J19PafMaDkd4jzRi37VBqdDgLY3 1556 u6K+oFKhG4oqQYa/er+ZGAqqldTmu8HGCsjm6kGZvSAocJg0UnLPBNI0/iB0BYGf 1557 KJk302jy8kfAXGSiWrYDNbTuDzFMD0zsbHbM07AOOROGwKv5TxAF1EHHTxGb3IKI 1558 jRkVBL7QdRtDH03zlxv0lnFwiuCrzLrQdUuEG/0wt8RaNr+p8hAo0YEGbB9jmbax 1559 CSLLWeNbMOo8eIi3Mft4qmDXp3TEuHHru8kbvA36vQ8+dunSf2BcecyM6UAYBqaw 1560 SCcxQmEcyMuyjSLVerVfMl5lwlmM+qabxHq0hpJHnCR3Vl2qX3CiRWpVlNaBVyTf 1561 793bAm7DU7G+Tzt5gdgE4s41aZt8fFXyclhH1QLPNSnctxJjuW1gJJ0h51iCQJp2 1562 TgzDw35oqvBxbN3yqCFjScsQXPXYErGWkLrAkUurff4x/ZAizFkmjjdpyaIK9JBw 1563 QRyrYYQ8pJhXJe9BrP3OS6evFlsWZW1MaoQcOUMWsuVucE0e4AQRGlPixDjJWW7L 1564 I6AQ3KUW6ggzDJksaYHDiuEoBa7vcYoTar+/AhNjYMjkQX/3kptQryqy+xke0t8O 1565 EPQER0Wur2IpvM6YsvI/SoeFwxMb4Zm5AFvvibiCCmmoJc4A9E1tZ/sMstHyZ5iu 1566 tJqu1M5B0DIoFdB5pzbZYCkgN2n7EY23JS7E/ozOrzYuOIVUJVtB5awqmuSLmI+N 1567 R91g4FMEfLYC1HYKYlaknX2zmrx8+Z8MEJNM2K0q8wPBnm86OpGeJmlZhFwT2x0R 1568 eJpKcfLGroXYh2Gb6BxwIfKjOOTXCoIFP02JbTJ7clc/2ei0BN6JxywPkH4renaP 1569 SkuNBgbexfZGBhMTlR+CtKLEUmw5bxBTDwjjcvzWDPhy/VurLQxhOqYnbhZW21SV 1570 4qMrJ4uGXEhylnP0FD+HR4mB2epYcW3dFj4cGN3B2Y5NnOTw0Z7fi4S0BPdvYjP9 1571 LL5WZ6p90mII9wcunGCRnLUUYumRnIbhVHIBTTIRI5PUSVFfEuotrDZ9oZcwYkO7 1572 fQX21gJCzvJyp8ft01HX4Kc4mN/FMPgGcmq70N335yQ4mQ/eSvTNn7E+35ZGn9f8 1573 PI7QPJRhdUkBZCnwyv+OwK2VzySxnqNfPaZk168foGRd9eFCw80L4U+SuLDQH6ZT 1574 o++VKk4Ce2jx1khoig16wic0dVFwt4bmybNz4u/qdobYr5fs7dKPHHO02SBvAl60 1575 16foheiBtV2VA8mEBA1BhcNmKYegu+RGhmGfNDuZB8XdbPQ6M+N+ilEj/6rr+wgD 1576 gcmEyAGNwJkmWpbyrm9M4lDtzemv5N5V32ppGizEt6c0xlkiULllwGdWey3+YRez 1577 7b+Kl/uIpDuRbp5Tf43dyPsy/cx4DNm5kAB4CcyyVlXPaqXm0llEPYBmaMW3O+D2 1578 5v4Wj1qwIRO5qgI8FyVnX6sm/oucfg5l172edaCG8f42gIMNfQBgWVMsSG7Nt00x 1579 dJo/OGtACwnY47ohMFG0BejWueAksdnqVWCIto989iBHgegNx5jUCycB/YOm0xh0 1580 pfeNjA9PwZMUpjlqrjDFIan/UFYAZH5ISSV7G30oRKJ3TTEshShXP2K3cn7Fa9W+ 1581 H/jyTEQGfCiTq7Xx5FrOIJBmKjylkF7oGlIBxJgKKRm0iD/sGNTaSJ6Pl8/K6dEz 1582 zsMwEFTawnWVq32Xn3d6/+FADZ9lGhC5WwVgaQHRb/9Ejt1mBdptmXjEj5w0YOib 1583 xFer54LrQgvBWEYRqDneh3bI53BudbTl7YitqULVGETe+k1T0NbcyElrr2Y/NKHk 1584 rPMarAfByookkJrDtVh3VrAm2ows7OwvKGyoNybjlyczjt7xosatZ1xkgb9mtR5i 1585 E2l9ajSR4SzQjHoboRyOCwl5ZgLV/+yp3jTkNcUkFDRtkVbGfascBIMe0ifUGfvP 1586 mJ9AQHZxdfm99KlQjCZzR8CBUvR+zsT43jr91CQKSSEvPMl6vVRV2thiWw3VGgP+ 1587 c8i5zj6+zCnlEdSWiIeFwOJ9/ewKSdU9pGrA0OQtXbYQlDCKuGK1Vgy6jJCeglDH 1588 T6gVNy5ip593wWWfOVxVEWUygi6JCdS27b5+P/wlNjTrzpZ4yWDCpyogyrT1gf1/ 1589 GgvdGuWWinKSLOyh1fJ1p9WoDWcqH98QhJXLV+X3OC+tmMofytmHgXN8jjVsWSRa 1590 VWrFUarMs2hZDWf6e6ncwvMC8QliiszrKXQNckxvBuh5hug9WKurVj4CIWnoqXFh 1591 OqlO+VbqZSj+TT5pCN//370vsIZIn5UbrpDmUP0rUvdTGz9iWQRUl6R2g2h286s6 1592 pAGHv9luXCoPJ5uPTwcbBSl/js6J+K5McyqRl4fucacfVFnMuDpET/tT1eAROP3F 1593 DOBKqV5YOO0rWMexzMLJUEQ/eGSwfp7wv8on7jeGxAexMqyWCrhRk9G2ZwiT4L7Q 1594 rX4NIDj6oujCCkeFUATs0pGKwEFGmpbEUfDOsioWoVYJZPsO9kAGq6bhbKACOkeZ 1595 v95ha/3CleYXGUUNtzLsCx+c9Zp/Wl+0PcT3ZSWhmRbXiIvz+ntHVe47PHxbvH6a 1596 ZG7YGc/9u3jTvJJyYtQO54uGET/eFWSxCUo5/VfsheOuLdXN7JnVi6ooF+c7WUZd 1597 61FwfDwNf8z0GWs3EotozrWyBgKS5VFP99vZM64nSqu9v5PSzmb0AY/Zc5KhVXVY 1598 zQqmO3keXq92Fejtgyd/O9ITZf5GkMQVU7+IT52JxFRQplkbTHJj4HRGtGHtIyPW 1599 Rmf9qSZz8QgVyAUKK1k+kLBJTHN3CWIB6S9hO42HWEFvLVl8wPWW5aLYTsVMGnMU 1600 aZ35M35odjrvY9B0INMpL53Hm7qH1w/h9QCv+xsFmanYsoylwbuKW2TcSnWB74C7 1601 Wy0NmCkaM+JweOgygffWicLGJ3jKWccykTUZtodz1ectNHh24puZICnvfzwjte+n 1602 eSQqJfHMsra6V8BcshpwmvPylHnkU+2KyhQ8430OR/qaXAYJ7EWRBEFe4EIpxzfL 1603 zQF0LwbhpAstpcjOlJfEHmQiWx8ASzE1LMSfZo148sXYEWsJL7t5tWs= 1605 Unwrapping the outer Cryptographic Layer of this message yields the 1606 following MIME part (with its own Cryptographic Layer): 1608 Content-Transfer-Encoding: base64 1609 Content-Type: application/pkcs7-mime; name="smime.p7m"; 1610 smime-type="signed-data" 1612 MIIIkwYJKoZIhvcNAQcCoIIIhDCCCIACAQExDTALBglghkgBZQMEAgEwggMXBgkq 1613 hkiG9w0BBwGgggMIBIIDBEZyb206IEFsaWNlIExvdmVsYWNlIDxhbGljZUBzbWlt 1614 ZS5leGFtcGxlPg0KVG86IEJvYiBCYWJiYWdlIDxib2JAc21pbWUuZXhhbXBsZT4N 1615 CkRhdGU6IFdlZCwgMjcgTm92IDIwMTkgMDE6MTU6MDAgLTA3MDANClN1YmplY3Q6 1616 IEJhckNvcnAgY29udHJhY3Qgc2lnbmVkLCBsZXQncyBnbyENCkNvbnRlbnQtVHlw 1617 ZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiOyBwcm90ZWN0ZWQtaGVh 1618 ZGVycz0idjEiDQpNZXNzYWdlLUlEOiA8c21pbWUtc2lnbitlbmNAcHJvdGVjdGVk 1619 LWhlYWRlcnMuZXhhbXBsZT4NCg0KSGkgQm9iIQ0KDQpJIGp1c3Qgc2lnbmVkIHRo 1620 ZSBjb250cmFjdCB3aXRoIEJhckNvcnAgYW5kIHRoZXkndmUgc2V0IHVzIHVwIHdp 1621 dGgNCmFuIGFjY291bnQgb24gdGhlaXIgc3lzdGVtIGZvciB0ZXN0aW5nLg0KDQpU 1622 aGUgYWNjb3VudCBpbmZvcm1hdGlvbiBpczoNCg0KICAgICAgICBTaXRlOiBodHRw 1623 czovL2JhcmNvcnAuZXhhbXBsZS8NCiAgICBVc2VybmFtZTogZXhhbXBsZWNvcnB0 1624 ZXN0DQogICAgUGFzc3dvcmQ6IGNvcnJlY3QtaG9yc2UtYmF0dGVyeS1zdGFwbGUN 1625 Cg0KUGxlYXNlIGdldCB0aGUgYWNjb3VudCBzZXQgdXAgYW5kIGFwcGx5IHRoZSB0 1626 ZXN0IGhhcm5lc3MuDQoNCkxldCBtZSBrbm93IHdoZW4geW91J3ZlIGdvdCBzb21l 1627 IHJlc3VsdHMuDQoNCih0aGlzIGlzIHRoZSAnc21pbWUtc2lnbitlbmMnIG1lc3Nh 1628 Z2UpDQoNClRoYW5rcywgQWxpY2UNCi0tIA0KQWxpY2UgTG92ZWxhY2UNClByZXNp 1629 ZGVudA0KRXhhbXBsZSBDb3JwDQqgggNyMIIDbjCCAlagAwIBAgIUZ4K0WXNSS8H0 1630 cUcZavD9EYqqTAswDQYJKoZIhvcNAQENBQAwLTErMCkGA1UEAxMiU2FtcGxlIExB 1631 TVBTIENlcnRpZmljYXRlIEF1dGhvcml0eTAgFw0xOTExMjAwNjU0MThaGA8yMDUy 1632 MDkyNzA2NTQxOFowGTEXMBUGA1UEAxMOQWxpY2UgTG92ZWxhY2UwggEiMA0GCSqG 1633 SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD7q35ZdG2JAzzJGNZDZ9sV7AKh0hlRfoF 1634 jTZN5m4RegQAYSyag43ouWi1xRN0avf0UTYrwjK04qRdV7GzCACoEKq/xiNUOsjf 1635 JXzbCublN3fZMOXDshKKBqThlK75SjA9Czxg7ejGoiY/iidk0e91neK30SCCaBTJ 1636 lfR2ZDrPk73IPMeksxoTatfF9hw9dDA+/Hi1yptN/aG0Q/s9icFrxr6y2zQXsjuQ 1637 PmjMZgj10aD9cazWVgRYCgflhmA0V1uQl1wobYU8DAVxVn+GgabqyjGQMoythIK0 1638 Gn5+ofwxXXUM/zbU+g6+1ISdoXxRRFtq2GzbIqkAHZZQm+BbnFrhAgMBAAGjgZcw 1639 gZQwDAYDVR0TAQH/BAIwADAeBgNVHREEFzAVgRNhbGljZUBzbWltZS5leGFtcGxl 1640 MBMGA1UdJQQMMAoGCCsGAQUFBwMEMA8GA1UdDwEB/wQFAwMHoAAwHQYDVR0OBBYE 1641 FKwuVFqk/VUYry7oZkQ40SXR1wB5MB8GA1UdIwQYMBaAFLdSTXPAiD2yw3paDPOU 1642 9/eAonfbMA0GCSqGSIb3DQEBDQUAA4IBAQB76o4Yz7yrVSFcpXqLrcGtdI4q93aK 1643 CXECCCzNQLp4yesh6brqaZHNJtwYcJ5TqbUym9hJ70iJE4jGNN+yAZR1ltte0HFK 1644 YIBKM4EJumG++2hqbUaLz4tl06BHaQPCv/9NiNY7q9R9c/B6s1YzHhwqkWht2a+A 1645 tgJ4BkpG+g+MmZMQV/Ao7RwLFKJ9OlMWLBmEXFcpIJN0HpPasT0nEl/MmotSu+8R 1646 nClAi3yFfyTKb+8rD7VxuyXetqDZ6dU/9/iqD/SZS7OQIjywtd343mACz3B1RlFx 1647 MHSA6dQAf2btGumqR0KiAp3KkYRAePoaJqYkB7Zad06ngFl0G0FHON+7MYIB2TCC 1648 AdUCAQEwRTAtMSswKQYDVQQDEyJTYW1wbGUgTEFNUFMgQ2VydGlmaWNhdGUgQXV0 1649 aG9yaXR5AhRngrRZc1JLwfRxRxlq8P0RiqpMCzALBglghkgBZQMEAgGgaTAYBgkq 1650 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTExMjcwODE1 1651 MDBaMC8GCSqGSIb3DQEJBDEiBCC5A+mnkPofr5VZKP+y+n5m21txluYikOynnkYb 1652 tCaH+jANBgkqhkiG9w0BAQEFAASCAQAgfVYYJu+aUcWjlFOT//l8p4LOBcB3WBEa 1653 x7msyZcptuaJtWaLedzgwi+nGHfhl/02wzTvCjx+LTHGouU83ILpEdDAxEDqzNgd 1654 gEJF7wswM7N31PhjpQyH+HbrJTH0tF+/xREgCG14yRs5yAXOkvkFDmd55svukInx 1655 eSb97LhQHQGpJLh5FBstWWBKQitNn8eB3g6h+c43zp4nBXoS2aFiUvYdWugw4QHW 1656 7T7dcSX5gAEHt/dm2q4oH0g9YtHmRpOmqdNQSuMkR7vomEkOkv2XWmlf3znKWe8Q 1657 Pd1ihgrhOASyT1oBmnpEVwvsSkhqoxkGcrrSefUZy5h0wKfNSqRW 1659 Unwrapping the inner Cryptographic Layer yields the Cryptographic 1660 Payload: 1662 From: Alice Lovelace 1663 To: Bob Babbage 1664 Date: Wed, 27 Nov 2019 01:15:00 -0700 1665 Subject: BarCorp contract signed, let's go! 1666 Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" 1667 Message-ID: 1669 Hi Bob! 1671 I just signed the contract with BarCorp and they've set us up with 1672 an account on their system for testing. 1674 The account information is: 1676 Site: https://barcorp.example/ 1677 Username: examplecorptest 1678 Password: correct-horse-battery-staple 1680 Please get the account set up and apply the test harness. 1682 Let me know when you've got some results. 1684 (this is the 'smime-sign+enc' message) 1686 Thanks, Alice 1687 -- 1688 Alice Lovelace 1689 President 1690 Example Corp 1692 9.6. Signed and Encrypted PGP/MIME Message with Protected Headers and 1693 Legacy Display Part 1695 If Alice's MUA wasn't sure whether Bob's MUA would know to render the 1696 obscured "Subject:" header correctly, it might include a legacy 1697 display part in the cryptographic payload. 1699 This PGP/MIME message is structured in the following way: 1701 └┬╴multipart/encrypted 1702 ├─╴application/pgp-encrypted 1703 └─╴application/octet-stream 1704 ↧ (decrypts to) 1705 └┬╴multipart/mixed ← Cryptographic Payload 1706 ├─╴text/plain ← Legacy Display Part 1707 └─╴text/plain 1709 The example below shows the same message as Section 9.4. 1711 If Bob's MUA is capable of handling protected headers, the two 1712 messages should render in the same way as the message in Section 9.4, 1713 because it will know to omit the Legacy Display part as documented in 1714 Section 5.2. 1716 But if Bob's MUA is capable of decryption but is unaware of protected 1717 headers, it will likely render the Legacy Display part for him so 1718 that he can at least see the originally-intended "Subject:" line. 1720 For this message, the session key is an AES-256 key with value 1721 "95a71b0e344cce43a4dd52c5fd01deec5118290bfd0792a8a733c653a12d223e" 1722 (in hex). 1724 Received: from localhost (localhost [127.0.0.1]); Mon, 21 Oct 2019 1725 07:18:28 -0700 (UTC-07:00) 1726 MIME-Version: 1.0 1727 Content-Type: multipart/encrypted; boundary="924"; 1728 protocol="application/pgp-encrypted" 1729 From: Alice Lovelace 1730 To: Bob Babbage 1731 Date: Mon, 21 Oct 2019 07:18:00 -0700 1732 Message-ID: 1733 Subject: ... 1735 --924 1736 content-type: application/pgp-encrypted 1738 Version: 1 1740 --924 1741 content-type: application/octet-stream 1743 -----BEGIN PGP MESSAGE----- 1745 wV4DR2b2udXyHrYSAQdAXX1u0LNgj2o6biKu64RULx3PY/gcetRoyNOWNoXG8zow 1746 LF4DhnBs27vQkh1BIU4KmJFOwwjLwuRvS/J4NvCqqcEYwiPdhp5q5ftn7wrq2W5s 1747 wcDMA3wvqk35PDeyAQv+M8gxGXm9ecpcotEX+9OM9EY5N8V7FmZ6ydRpBXgWvCpB 1748 Nr6qk9OsOvIlhiN1IJbl73mEb5LdMj3wtRwGP3DB4AoPabIMXh/hCcNAhaWusVH0 1749 AK33oDjH3rhntORMveOqq4QhRzUGR1ctYWRNBXgKC/n3Bmp7mHAzfb4RyBGXDXsI 1750 TCXAb2qDnk06vTCVaHJ/ggBInSb12iYPkhDtoxbNFOP7U97lSVgSoDels6TRDfpb 1751 9K667gVyhkTnBvys+EqWbe7Bz5MJqxn9NQxh7HTdY2kXSKGGe1DUrAzLKRpT78fQ 1752 O02DLHR9EUh30hYQEPnuKAdYHJquXB5UiObJpQ5UDEt3MsvObUD7k21MQk5K6iyh 1753 1wcxtXm/kPqQ3eOpVm8iaRve/VrpZEgA0/9PcvQJ0VCWQ/fZEBVmh3ojIoZF9WJE 1754 jB3FwPS2lVLJhaZFTGU7xOKsz/x0K2M8meAsa7nx0TaetmieRA2L+wBaHhoUz77L 1755 9ihYlIBPNvkb49jnF3ft0sI2AYM9DWi3Ki7uWnw/Ue7jiu8dseBTvuxXU7XYPS+l 1756 k3nqqtCKjDziq+ojjw3+ahsfNNIrcFTizjZqGG5AK+dwjiTY3T4fJ4b07513+2uj 1757 /tJE7p6IuuxlE+qlpI1PrX7JFHpihbxsWnwT2RBgo+sdeVko3HbyWtfLnfwI+eNo 1758 njB1DvhWg4C61ilnbRU+osbnZSoSqJSdHCHqn06YfL75sdHrhDiXzV5+LPiaqHoD 1759 S1wOLknIFD91GO3PXaae3ENJgE9CFz4v0jNw2+kASuH80DwnKiMQrmG78rY4u652 1760 HcO2p0ZQAX2QeK0UidSjQQaKRtz5sys6QUbS46lgMSnHljQun4g8hlvoDH/7Zz4a 1761 kMgbZj7TRPU2EaApRX9JZub7nD9ODJkqtLJef9ncmI3QwBjClXy1sL/olUhUjFAZ 1762 VNbbInqEba+LLio4HUozBAjrVVWOrAt776lBSR4n72DdMjMKZ5osxPLtAVce9KeV 1763 s1cdKffbF4VDoe97eRq5ua4KJW/c+8WGW1u/vzPA7Zj6rR+gaWKqw4rnlys4+M2b 1764 LHugg+cF0k/sEfrmEuHyefYvms9Ht2icbiSTbqN+ApXuC9QtNRb/XnEw5lCH+dBO 1765 EYm/W0qSDXMcvoZaZ379uFkXqiECLF11iA3K89BV1VXFXgatnLHbNBdpm+mmJlz+ 1766 MY0NTCASFv0Bri4Y7j6kSOZMnfol+84j/nVCpBej8QrXqbpL+/6xrBURcA1Sb+Xu 1767 XRF1Veybr1bj1Tcp7aDLzZtQ8pk+8zyxy9dOePPcBDZlnDXCALf9eXJ/HX/6EYNT 1768 3Oh+kmF7UxghUGUnyTfBMhnBD5oNi+OGVyDWyRv5jfYc5FWwXOmcRjigPlofLmo9 1769 7eLOmYMmp0L2DdNiVer/Dl5g8HRSVaRceHJVUrNM+M2xzCkdrTHJSh7MBU0TwUd+ 1770 RXYQgfPu8xbeouLnSTVC5Kuul3VA8Q1/Y6KcjQTgjNvrOzjHTxjKek5fokNxvFQj 1771 1fkAIM9w2k0= 1772 =+l7i 1773 -----END PGP MESSAGE----- 1775 --924-- 1777 Decrypting the Cryptographic Layer yields the following content: 1779 From: Alice Lovelace 1780 To: Bob Babbage 1781 Date: Mon, 21 Oct 2019 07:18:00 -0700 1782 Subject: BarCorp contract signed, let's go! 1783 Content-Type: multipart/mixed; boundary="6ae"; protected-headers="v1" 1784 Message-ID: 1786 --6ae 1787 content-type: text/plain; protected-headers="v1" 1788 Content-Disposition: inline 1790 Subject: BarCorp contract signed, let's go! 1792 --6ae 1793 Content-Type: text/plain; charset="us-ascii" 1795 Hi Bob! 1797 I just signed the contract with BarCorp and they've set us up with 1798 an account on their system for testing. 1800 The account information is: 1802 Site: https://barcorp.example/ 1803 Username: examplecorptest 1804 Password: correct-horse-battery-staple 1806 Please get the account set up and apply the test harness. 1808 Let me know when you've got some results. 1810 (this is the 'pgpmime-sign+enc+legacy-disp' message) 1812 Thanks, Alice 1813 -- 1814 Alice Lovelace 1815 President 1816 Example Corp 1818 --6ae-- 1820 9.7. Multilayer PGP/MIME Message with Protected Headers 1822 Some mailers may generate signed and encrypted messages with a 1823 multilayer cryptographic envelope. We show here how such a mailer 1824 might generate the same message as Section 9.4. 1826 A typical PGP/MIME message like this has the following structure: 1828 └┬╴multipart/encrypted 1829 ├─╴application/pgp-encrypted 1830 └─╴application/octet-stream 1831 ↧ (decrypts to) 1832 └┬╴multipart/signed 1833 ├─╴text/plain ← Cryptographic Payload 1834 └─╴application/pgp-signature 1836 For this message, the session key is an AES-256 key with value 1837 "5e67165ed1516333daeba32044f88fd75d4a9485a563d14705e41d31fb61a9e9" 1838 (in hex). 1840 Received: from localhost (localhost [127.0.0.1]); Mon, 21 Oct 2019 1841 07:12:28 -0700 (UTC-07:00) 1842 MIME-Version: 1.0 1843 Content-Type: multipart/encrypted; boundary="024"; 1844 protocol="application/pgp-encrypted" 1845 From: Alice Lovelace 1846 To: Bob Babbage 1847 Date: Mon, 21 Oct 2019 07:12:00 -0700 1848 Message-ID: 1849 Subject: ... 1851 --024 1852 content-type: application/pgp-encrypted 1854 Version: 1 1856 --024 1857 content-type: application/octet-stream 1859 -----BEGIN PGP MESSAGE----- 1861 wV4DR2b2udXyHrYSAQdApTCCVZLqLBNWL55la9dZGbO1aPtMkIFXYo8DOKgIpCcw 1862 gm5VfqOECRjoZqCwveFWGqRknz0lc+eau5fcbenmEW8J1E0FjpoBEnFo9vYb6PrU 1863 wcDMA3wvqk35PDeyAQwAwiuMTVdntVxYn6dnGUoaga2txqCsxioqn4JgfmGrIfBf 1864 +BEHyt/a43rWwfi3QycCKg483Fqx0YG3HHJEiiwdFmE3XdoHmTRKfHuSiyzCNxPz 1865 AK2cwloBtD3w6zs+mOY7Ytq83ghyBeX0aGmgCZqGhL60In5Qu+w3Vmxc19d2+BTs 1866 ZOJzxcHACRvq2tD0RRmyhjWKqVdd2akllMy1pcXLIediUiEI5MA3TaWUk/uVDsUq 1867 S6JtL0dEy0s49Z+flcGfEyGCGU6TqV0Yun0bl3A7/OJjYC+75eCv89s/q4W1UM1M 1868 psO2X7xNlhgREncwvaoQbvfVfSlxHgWGCZDL8+O/7XC5EDyK4LAR912SG4Desr9e 1869 k9Fn3bH6Tt71vpH0nByKCh0m2/apFEMLXSq7DMiJEN4spbc4D3iBnxYqEH99e052 1870 KNjrHaoG59bZ6TNJj/JN+E5sQzDxic00O4Qccg9M7iFh6eBLOuBhBpRxbeoXQkl3 1871 1mzI8XpyFoGu0HH0I0Cs0sJGAUnVvA0LGq7wjKpy0bWQlB2YVCKU6C8GnX6GUcLm 1872 SMovYhGKfpb+LUu+UM1BZ9vd9D/tsMd2WBw5tM1ncfRuSTOhVeFgTEGiCrBn7sdb 1873 UFTV+jb5CktQMwj5vWlVPhMIUeISwoAQJ1ONuOqFnVTJ2bZOdxZeV6NDYPYCERuR 1874 Sh980UxdjGLvw/LtMThKJRUr3S2TcmKSwGen5a96S+lAAmMJN5wLrH+X76UuRvV+ 1875 O7m6KDasO+fEIWXKYHGjJI1On8MnkVE4dSDKgUNukVRoBAB9Iqn11zWb6IX7f11M 1876 k8C+8F5Y1xxEG3CCeYdTKSiIkDvBV8oFGrFCYXWO2bLWFpCZ0t2qDfWX5SvXj+EZ 1877 KxAiZobwQEw16WYp4Mk0Ppf0UrBXkfnLBieRgO4o5j5Y//EXKpv8TSBxRbeOVfRk 1878 x11HNbaNeBtID4N2HfjsqUX3y2ZH3m7HWLwkQeX6Yw5qqSWQjC8fklxOku+brAaM 1879 ayudhVFKiD5PVfe1NrVv5dDSbj5VyQkoESi2zLmd4SLoFIMp8/lfSnpl0ZF4krFb 1880 wIF8wd+zT2307fN4DRKjuqFVr0Yl8oh9iPJN0xXSyygeo+JWWfYPu41vf+viRZMh 1881 aj1nhJoa9UghiYfXuDu+VjzZuM22C/9gVbXMSuY1PaKffBleTNhCT7JWlmhNBW6t 1882 ouH6dZ2X6OlXECmByzKy+d8Dun21G2nLuE82QP9y7/QZ2g+OSWZAA2IIDiH2tEIb 1883 8CNSVwZXNpSeqH5u3+aRE1M5EzslbLU78Ryrxt6lNAzEHD42Fif+qaH0WW52wV2H 1884 vnaxJW0yQ1o4W6W+BPtKqtE7t8JgTEtxldKHIdWCMXg2isxWMMIE12QEc26+bQnz 1885 h+kDrTqxtp8rSfhLSQi4TRoudxx8mMjwFEWnRIFRQG7eGNPaqZYF3dz/neN/fy0p 1886 Jbf1gFJAtrSIlOOaZ+iT864OtcaLOHkOLNGEuyJR1dOC9tuyldarvKR0v0i4jhY6 1887 UxDkknDkq0IzTmczFyAH3lBLRPMZNZ1z 1888 =YU4k 1889 -----END PGP MESSAGE----- 1891 --024-- 1893 Decrypting the encryption Cryptographic Layer yields the following 1894 content: 1896 Content-Type: multipart/signed; boundary="80b"; 1897 protocol="application/pgp-signature"; micalg="pgp-sha512" 1899 --80b 1900 From: Alice Lovelace 1901 To: Bob Babbage 1902 Date: Mon, 21 Oct 2019 07:12:00 -0700 1903 Subject: BarCorp contract signed, let's go! 1904 Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" 1905 Message-ID: 1907 Hi Bob! 1909 I just signed the contract with BarCorp and they've set us up with 1910 an account on their system for testing. 1912 The account information is: 1914 Site: https://barcorp.example/ 1915 Username: examplecorptest 1916 Password: correct-horse-battery-staple 1918 Please get the account set up and apply the test harness. 1920 Let me know when you've got some results. 1922 (this is the 'pgpmime-layered' message) 1924 Thanks, Alice 1925 -- 1926 Alice Lovelace 1927 President 1928 Example Corp 1930 --80b 1931 content-type: application/pgp-signature 1933 -----BEGIN PGP SIGNATURE----- 1935 wnUEARYKAB0FAl2tvLAWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj 1936 jjiqAPwOjOQI/Sr3vG0hiAKmfBgmB7VhKiUbfFWKRaWKkzJ/kAD/eOjMNvaZ5MG1 1937 fw6xQXpB1vRrY9Ttz3zr+TfLnfHFwQM= 1938 =4v4Q 1939 -----END PGP SIGNATURE----- 1941 --80b-- 1942 Note the placement of the Protected Headers on the Cryptographic 1943 Payload specifically, which is not the immediate child of the 1944 encryption Cryptographic Layer. 1946 9.8. Multilayer PGP/MIME Message with Protected Headers and Legacy 1947 Display Part 1949 And, a mailer that generates a multilayer cryptographic envelope 1950 might want to provide a Legacy Display part, if it is unsure of the 1951 capabilities of the recipient's MUA. We show here how such a mailer 1952 might generate the same message as Section 9.4. 1954 Such a PGP/MIME message might have the following structure: 1956 └┬╴multipart/encrypted 1957 ├─╴application/pgp-encrypted 1958 └─╴application/octet-stream 1959 ↧ (decrypts to) 1960 └┬╴multipart/signed 1961 ├┬╴multipart/mixed ← Cryptographic Payload 1962 │├─╴text/plain ← Legacy Display Part 1963 │└─╴text/plain 1964 └─╴application/pgp-signature 1966 For this message, the session key is an AES-256 key with value 1967 "b346a2a50fa0cf62895b74e8c0d2ad9e3ee1f02b5d564c77d879caaee7a0aa70" 1968 (in hex). 1970 Received: from localhost (localhost [127.0.0.1]); Mon, 21 Oct 2019 1971 07:21:28 -0700 (UTC-07:00) 1972 MIME-Version: 1.0 1973 Content-Type: multipart/encrypted; boundary="32c"; 1974 protocol="application/pgp-encrypted" 1975 From: Alice Lovelace 1976 To: Bob Babbage 1977 Date: Mon, 21 Oct 2019 07:21:00 -0700 1978 Message-ID: 1979 Subject: ... 1981 --32c 1982 content-type: application/pgp-encrypted 1984 Version: 1 1986 --32c 1987 content-type: application/octet-stream 1989 -----BEGIN PGP MESSAGE----- 1990 wV4DR2b2udXyHrYSAQdAC1Ly2OZdEVNBoA4HUfvQJgdpSkelPzYiPR/TWOapEx0w 1991 gPck9O1y4gnu01fnptzYiIaZKMWis7jPqmH2jQRhnG1Q0JKS1PeCfTS9207oQiD1 1992 wcDMA3wvqk35PDeyAQwAqIL7jcN2Rm5u4qhMfvT7by7nUKCOaP/H+kMPIsXP2Kxf 1993 MlRVnrrsCgJ6j5htt48HGddpEgLlZceK3vg8WlRWSpMstpdGxxE7HZqXHKMNk8V+ 1994 8EVWlHGWBmxisA7/JOOrt4HQJnHm01drIXgWjIA+Vpu/zFA542qQH78jr9Ghhp/C 1995 Q32VOrCY/PsFxabPIYS9wWh1Ym3+VQFndCVSpxCZHs1Qilt9XGj4X712QcvgL2Pp 1996 glaulvNob899dOIo4Noj7p+cx4yMkWpi9dqHuOme23aixieBbzQopzY3gleVgXhc 1997 HFhUzje7DybtVq0em4xpNPWxq2b+WBeu+SvXFo2buHhWmMClbKf6gggod3CRKcPt 1998 h5MLF3dFE1kj3BOLxJqFOIny2EhWZvvmDQgG4uncEGo1siQhEiutQL2WClzuHGzs 1999 T8eEHKeATEPqRQHm395Ivr5btQ8gg4tnIkfBBULPgnEfY07Llc+393a0MgW9bLbn 2000 UZTmNIsS1FKXYzHxpUAD0sKBAe03UKSoYJ5b5yBghMZCCS9L9dm8llJVsMh022DC 2001 lMPpRsSm79hnFww0+Yud+i4z24C8WdivWBNoZz0M1hA5cwoQoXaxalL5GpZ/UWAd 2002 XNC6QwaCB2ioTFueq8SJAHzur2V89FMUuPmSaB3yO72vko/468nLnjwCcZDpbWCS 2003 fVwcTz8bvyZfcYA2ugRPii4NM1+bYJHHtr6CIojN0FkE5tOLAxO4vPAx5CYABTm7 2004 HQn063YJJlTtJB1SJWMzmK5vqxtXFeOByc/msdQX8goxS3G6RNPVHabESaqVrG4i 2005 F+TyzqiMFTZdLjiJXiKcFHwDoLUwA/FxkA5/BwRCM5LX3LITAvvqYy0TkaQH0SeN 2006 bfqCf4kWzuNhTfZM3wFgaA+FvYC8M7PKiE9y1+TiWEUqMa+j0rcrf2+Nzt8mT6WU 2007 eQRwf9XzgmPVNarQpStomff6dJVaxloNCwKKk3LtGRWkV0EIbKtFwPi+M7h3BgWn 2008 NQHVT1MXXV8LyKipH1ZpB3WUHjGqL13esOFwR4W+U9/qzgn6kN7kZP+yj0qXutCR 2009 GsjoVvwN6FU8cjv4nK1H65cobBAqP0iWEvLt1e351cwQWwUL1V/B3jWM3Wqui/hR 2010 lOQ9TW/WdP1/VT2Heb3503IJKJYntOMcT8aYooCLUCQmx1g4Ks1y4hP5mlLurjdv 2011 qBrvDNbRsW27GnyuUm8/oS1qpYS0gIrMe4BMXpwLca6xvXElNcm2Lo1Oqh3MhW5J 2012 IVjGkQDV2vM76qsfBdpHebO0XBKfccyx9wZDO9MOAOXVO8o/yh8H/Mcn/sOpaVsv 2013 gdf6JElYfwCOd7J44ymzonw0kbC6F7UZgpWlY5gGlga2EPwwaFkTH22D8MHOrwKA 2014 JBJCvaGxEmzrV4WlaE77LUJoDs6chIF/GKcntsBvvyvjsrFLPK/2/RtrUEkP2G4e 2015 svWDdqSECPYEFYMvzfJMwa2G0uXCLiATP8NTSleOcZ9sPkE9Ul62JVJ+y/tOz8z/ 2016 oZ4SdrgAEdJSbWbyev8bd1WCbRnOyOxuQHmVmhtCm4Ps506+sGWL+PDnywrwvyP7 2017 X1b8YpYCWaHS8md9AW2Jgcdj6p3Hc2Bs7zlMqzsc0pdvXRs= 2018 =Fb+8 2019 -----END PGP MESSAGE----- 2021 --32c-- 2023 Unwrapping the encryption Cryptographic Layer yields the following 2024 content: 2026 Content-Type: multipart/signed; boundary="03a"; 2027 protocol="application/pgp-signature"; micalg="pgp-sha512" 2029 --03a 2030 From: Alice Lovelace 2031 To: Bob Babbage 2032 Date: Mon, 21 Oct 2019 07:21:00 -0700 2033 Subject: BarCorp contract signed, let's go! 2034 Content-Type: multipart/mixed; boundary="6ae"; protected-headers="v1" 2035 Message-ID: 2037 --6ae 2038 content-type: text/plain; protected-headers="v1" 2039 Content-Disposition: inline 2041 Subject: BarCorp contract signed, let's go! 2043 --6ae 2044 Content-Type: text/plain; charset="us-ascii" 2046 Hi Bob! 2048 I just signed the contract with BarCorp and they've set us up with 2049 an account on their system for testing. 2051 The account information is: 2053 Site: https://barcorp.example/ 2054 Username: examplecorptest 2055 Password: correct-horse-battery-staple 2057 Please get the account set up and apply the test harness. 2059 Let me know when you've got some results. 2061 (this is the 'pgpmime-layered+legacy-disp' message) 2063 Thanks, Alice 2064 -- 2065 Alice Lovelace 2066 President 2067 Example Corp 2069 --6ae-- 2071 --03a 2072 content-type: application/pgp-signature 2074 -----BEGIN PGP SIGNATURE----- 2076 wnUEARYKAB0FAl2tvswWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj 2077 js14AQD2GOrZXkuKxZPY0l6AJFKiAFphRt+5V9gj3HEXKvQKPAD/bZy+vW9j1+e4 2078 MLiOb1ojjFocLx/6MvQBoI3P9a591Qs= 2079 =l8GL 2080 -----END PGP SIGNATURE----- 2082 --03a-- 2084 9.9. Signed and Encrypted S/MIME Message with Protected Headers and 2085 Legacy Display 2087 This shows the same signed and encrypted S/MIME message as 2088 Section 9.5, but formulated with a Legacy Display part so that Its 2089 MIME message structure is: 2091 └─╴application/pkcs7-mime smime-type="enveloped-data" 2092 ↧ (decrypts to) 2093 └─╴application/pkcs7-mime smime-type="signed-data" 2094 ⇩ (unwraps to) 2095 └┬╴multipart/mixed ← Cryptographic Payload 2096 ├─╴text/plain ← Legacy Display Part 2097 └─╴text/plain 445 bytes 2099 The "Subject:" header is successfully obscured. 2101 Note that if this message had been generated without Protected 2102 Headers, then an attacker with access to it could have read the 2103 Subject. Such an attacker would know details about Alice and Bob's 2104 business that they wanted to keep confidential. 2106 The protected headers also protect the authenticity of subject line 2107 as well. 2109 The session key for this message's Cryptographic Layer is an AES-256 2110 key with value 2111 "09e8f2a19d9e97deea7d51ee7d401be8763ab0377b6f30a68206e0bed4a0baec" 2112 (in hex). 2114 If Bob's MUA is capable of interpreting these protected headers, it 2115 should render the "Subject:" of this message as "BarCorp contract 2116 signed, let's go!". 2118 Received: from localhost (localhost [127.0.0.1]); Wed, 27 Nov 2019 2119 01:24:28 -0700 (UTC-07:00) 2120 MIME-Version: 1.0 2121 Content-Transfer-Encoding: base64 2122 Content-Type: application/pkcs7-mime; name="smime.p7m"; 2123 smime-type="enveloped-data" 2124 From: Alice Lovelace 2125 To: Bob Babbage 2126 Date: Wed, 27 Nov 2019 01:24:00 -0700 2127 Message-ID: 2128 Subject: ... 2130 MIIQjQYJKoZIhvcNAQcDoIIQfjCCEHoCAQAxggLCMIIBXQIBADBFMC0xKzApBgNV 2131 BAMTIlNhbXBsZSBMQU1QUyBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCFCJT7jBtAgsf 2132 As31ycE+Ot95phvCMA0GCSqGSIb3DQEBAQUABIIBAFbDR6j4ZB/Mo9BQygYItwFc 2133 P+4rO4d1ak51hc1DpSqyhiMcGahA3yxDRbZ4W1rbmC/s3d5+OWXKYgs1nNMQJ48F 2134 f45BtNTNslPZ1+NZVbkoVJO8Bxv1rjB8/qWuSUsroqzn9enS8DUBxxPL5aSWKQQN 2135 G2IaH9BUkMXLPUYA46GATly94IS4fZqwBtNNBP5eiIIPc9Ogjy+7At5GG7rVMN0M 2136 G5FL0oq52SYUe1167jp378JI+2dkA1q5+Cru/ZE2Rdw3DrMDAFO5GwC7fWKg4zPm 2137 IHZj92caVj1IyfTmGogT2o5tLMqn61BkptqxZwHDr3FI/aYo4vcHgmlKR/TdbHww 2138 ggFdAgEAMEUwLTErMCkGA1UEAxMiU2FtcGxlIExBTVBTIENlcnRpZmljYXRlIEF1 2139 dGhvcml0eQIUZ4K0WXNSS8H0cUcZavD9EYqqTAswDQYJKoZIhvcNAQEBBQAEggEA 2140 hXeYVSUsT1EBZ/+AjwyEcnlM0kuFMaNvGlBMhAZzAsy012rrZTWbqWkcA3abgm/M 2141 CuZX7mQL0I79KZdmClGpLx6gQFjLemHaClQV0ZNdX4DxakWuME/kCMqbo4MZXStT 2142 a0MHlKUdoMt72Rz4YBzNQCL7ePaii5w6Nd2KD7yJAirLYUMJEjVweVaMI9y9LmbO 2143 vb0g0iuoUe0vp9B20LRcIX37nN5D1GG4tHLPjBD43gC8iqxZQf0uah2cWD1mAG5R 2144 oBgIDKXPy2eVbcMdSaOirDKYZ49WFe9Lad9q3mHHbFs6K6/yuBm/thMEdCJKZTHo 2145 jiPvYdYF8IJfEd368I+DujCCDa0GCSqGSIb3DQEHATAUBggqhkiG9w0DBwQIsb1a 2146 JX/RU9aAgg2I0VXWfs5fc/Yad2qvawUVNX+LObjA6/+t9WxuV2emOeBYzQGjo7q+ 2147 xaIXQwbbF1ej27efGhxUYDwBNS56c0uI0Ta7jxv5OFZhzQGLRzoFp0bbZ+uVC4eP 2148 bFHarRQiPzlg900XASO0RW+UOtqN5raZ3Ry2lKwXxuStZ0pX666Rz4c8PrmMb4/B 2149 aQYn6iKcT6fDU2TpSbWY9iph6kZczSeewK+pIj9nXfjDKXScs8D2Raezev2ciq/V 2150 ZRpRH8JxieimI2yeBmEzTCq11TDYycDfMHB6reGaiCGX//8kAWtskzRyNlV61unY 2151 ZKSNhVKLwKmCQh1V1Nd3oLApT41EeM2oWedUqNBYqB+XGCD4DUYdm1e+4h73d4dn 2152 JTkCdadxEn+9RRvZ4YMlw3mvT997Dy3rTXT29dj14TstZZf2O63pY0TpYy0HZy6Z 2153 Jug1qoe/vdcJ9SPOSfJE6VWCeVjxB+eGgheFLKqzK8Hs/Bm0/wDKpSFgEpOPnkJ4 2154 HJ2Uzgn1Emo6gBDJt+qn3s2UnowcMsTgellhKvgzVq59LTyRyWL5U8XMBsXT4qjm 2155 0LkRvDkOIjMQH7kqvWbpPlnWpLKo/VVoxifldEegWAqFVrP7f5Y+nNQttAYV79uk 2156 MXvR+5YFkvmQAerfllPqXBJdbB65ovikSVsy/kAboGpRG1oAZ4ODdwdGyiGIzyyc 2157 lE0x/8+gY8BqWzRtWX4GySKyZ50/+xkJe5ss0IXPCgq/09bdihsRn57v4V4SpdDO 2158 k3g/Dce+LzCRL8uTbUhrhZnjKSjRc3fFaD/BpLYjEDbnGF0ICslN3vb2xWUK1u4M 2159 uUH9r7lH/DCb0+TxIBtxOnP7W02bz8gGJAxEVEqk6pjxxOYqfS9/uBrrAY8P21Y9 2160 PFLdeHzEdYemq3il+4S7OU3uNUuAYijxmCRs7JQxZ9puA0iaTME9gK1yikzsLtVZ 2161 f+9osk2nYgfXvlL0AiYabd5cU2GNW33TkdDMNBsB7lx77J9erVLZpPKNo4vgHA7b 2162 owrDaYe0AgcZm79fvmR0RdtIZI91MouEhkdhaPiXmypmszjR/M0Ot3Y+oU/ks+yV 2163 Sle0S0h4V8wJRJYG/9VVurm8012ke2U3EGFlVnSv/IYtpssC+U4McRCmakKCrGU7 2164 OhL5JKBQN/DFTu4pV39IQlLLhg3wzA2FSkyIL5gEbS6sP9GTPo5LlNm2nYfJQX9A 2165 sHKSrfh68dvjSNExxi/8hdmFnnRwbAnUCI/WObGOkKdheOfdQ1AAHtLO7G65X1Cx 2166 RctbAJWa93M+iRUN6qnB+vIbPPnI1Mc7i6mPYzgtPrM9bYqEZz69pQtHcGTfxOrU 2167 tm+/h36CRzJBfXodBZbwQ9mZAzfkKdlArlZYIeBUw3ORQnQ7UlJgG8KsZpUhTxCc 2168 gvMoExtlvkXcYLRUBFfZWyOi6FePzQjuCK1w58OdweJgXprEAWSvyxhmVdg4jUpX 2169 MYKE0tZI9xwujyWjACO0myYqTdmsqyds+BgfBn96XiA9OFUH2C0/GAomhNs8uPSO 2170 T3Gt7Ld/FByxEVrtl9A37X6bAwZO01j5tHmdXFPmMVep0R8zsWtPn3RyGAjcgcq6 2171 50wJRwhvofdI7wilZ0KUBsAaPj3MK52cRyD19VXKNNwt2bLDV6gcWQ8+QEMusxfp 2172 1Dc9N9DSs+w3lGsFfpoeQ53/fXcVNJm6Bv89bH9anLGYdCdRGvZsvw+xRuglykqb 2173 xLtL2lB6wzlRFREJoWTzCVsdpIZ8znPmk1cB0wDlbMeu6sddHmv+6fpyuvQfQmdj 2174 D8WLRTuyxax94TmBlhJCFYxmO/y4Ivlx5C60GIRTkHpBYL/M0RjrbIszXEqcogzU 2175 bdwjLIhdEnpJ5vy0uXwhltce8BDpenmHE7y1kHvPBiUG3vB7AIXqhohFsJU3AYUj 2176 d1TvFKS2AsizUTLuq0Ydbnz3AxMfmnZe8qYkNu2zRygL2xTa58f/MwsHKakk3OmS 2177 9JFZLrkkVWZKXoARctuahYtWBAsykaWVNnB6zGcdX1MGVccl930Z6QWHyydtZpQc 2178 ivNdEGdGv9B0K7/ngNdVgD5Wd29AMMFnS8+55mLfRZDCjUmshSySaf6Ein4HD9Hr 2179 vk6dJvBPjnI5UjeUPjmH+wcZKIjLHW/aV/6/zoxzBh61rWFlr/daec+CFZE/+epr 2180 LRRYSmv8oY47fF4duDDhoexcvP/CH+A2Hr40OfciL4vKy3nuUDCNa59xO9JWv4NL 2181 n3MQypC9bcaVPkXa7TK3ECq1Jgv8gwfdh5/ovG5OdZA4uIcO+aqcskt/PD252c63 2182 0Znww3RXXf46KT4GdKO5A377ixkUMkznnCMvottmkPxjnhQjAsQg3bJeQk8EoX8f 2183 Pq0If4i7SRBSDtb2OH1pPmk0RVPtxlRDTVj3vS3Lci4xADFgC09n9nIvPO/55aau 2184 O6StbJtLmpubS5giuDH3uftwuyRiLqm3gtbSKPdoTk+dJhHXbbpBknL4XYTPxSsR 2185 IIaRds6w30vf7/IscyunMcquJlsO929SSa93UevKEIZbqbV9oGIqwkiUMdVZK09g 2186 rW0F//Ts4a5nYdEQth/fq3JnwqeHvvUfKdasK4TtrTnUBX7qZk/K3Y1fZwjKdd/8 2187 t9t1z7Kb2d9hWwtY7xP8liDluVFTsq8NM54ZC2218X5ViWz1yFmF2LXvRixsmYJv 2188 Tz8lUUnC2B/Etm1kkU4zrYK0/L77EikKVl+B7BXfEqx6ow41j7e1YZYaqmZ9mph+ 2189 UieSdzqVYxhPwT25DrkU3r74iS28gKsbFhUaNklaFOO5iDWsKgBXT+wdZqlYQ6Fo 2190 oPe66025iJMwK8t+d53jEduHezHO2sTMAuf2hpdaZo7+rP/hRTReAR6CmI7nkWhP 2191 z5Kno9S+XhiSP+WTSpsoA4ubx0T94mL8NOVvSZA76TZ3ObVAP5VI/bwv6Grighor 2192 Kpsjt7dhSJRv+RHv95sAWBeW1Fgv8XOPSAZOmpJV2qc3x3Qmj0MXIR+7+3GlUr8+ 2193 Dit3CE1hwtxgOW0tc8kuBTfQD+wNSa9r0eUyFscEBBljpEVbLjgjVdNv4Hc+fsbT 2194 g1JzZuUIDQZoEO2xLjxD+I7vLZKQa0J1JeZ7O+NqmSxsvSnwCWtJEWNMMxYNfwsP 2195 rdj1zPLqn3rzSBqhroNbaDGn86BTwIqfhr+AKbvevxS6bI8IbyKm9u3BFr9cuawx 2196 Sp1QM3NtqNStV67qR4A6U/ZyPUJdO1bxo8F3oRmJqOt7Jc93rFgkhBJ2+eMtrA75 2197 Om5tB9LBVSl5U5yLP0COO1QE5pqk5yuhJLT9Dyss8bWDRbSWKj83e4YXhPnq71Bm 2198 001czylLVNUlDc69Tf7FXjtIxh2yjvOT3zeLBPXOjU0it+gAma4vgrh8/mMXnNiq 2199 OLsVow8aKqm+Ofd6m13K5riDFgXgNI9lbvPKUSWlEqDMEqXk1oAqD4Nb5NTGSFpQ 2200 Q4G+cHAxJCu7vcXBaZnP8uMP5IAkdg5jIPvvMRwg/aqkl/KbL98oYZ5+1xrOMuKA 2201 LT1uCJ4MMB0lWsa1He4jPe8LneSupw7vAXlbo2VzcOI6oCSY5hV+cGQRY+LjW81q 2202 Cu5nLq8bwgnZMSlPmwr0YrKmvh8YKyGOrmTadxykC5IC+XbrLDsw2Jd9mLIjUQ/V 2203 4ibjeb+e0QGob22WOplCLnHGW/SnYei8KG1dxs/ahS+8vQdrI880ZJx2QJnrz0Ej 2204 ux6tKv4mvUkqYA5hlTFeT3PTr54yA+YLcCLMfBDx4ykPQnYUBj7ONHuNSUYt1CJy 2205 faZ7cWAbhgH+wlTFdVBVeW5D4FRbM8dMTPXyfC5ygwTJOiDu3vQKyyDkmiX7sEaC 2206 P1JN2V55uacyR8ZAG5+Mlc4ZMx83kAIZZXTCdqa1EX8yda31FI2rDHmvW/82bmjL 2207 pvI4Nnn9+zzJtDVCJ0B2VAZ3Edov5GzPikm3un4+mvyhUZpH4sbT0+VhPCsr1+zn 2208 bDJyNw4AswxaaJKh2+7wBiU6h+9TP/lI8SAJHtZL7zHBH8tD10ptksLRWDs9vYqp 2209 /3T86S2vxJL5DvLFJSAZrYOE3InS+keGmTMCdAl9I8zIworC/8uQp0N8ESebEVjA 2210 aHotBk59lj/OW4JZ3tQkcdQWkpnUfW/x9xE2wthacHlRzYDDsFByjEqkQr0MU8VF 2211 EGij9RCC97zyFrhv0xJm1C6wX0pcuEcuPTNBf38WyBTIfmVHHz/I5YKk5cdWG7Hq 2212 fmccV5GKrs2BseR683HM+/u50sq0km9UrqjgFR1DjfDoRKp0guP9PqkJAnwG2nv1 2213 hmNtXumzkF0otP5LDKLJ84MGP8Wnb006iEdD48Lra+clRAIIuLX4A0wRQjViDp7n 2214 OByI6ZcQd4DTMHnFPRvMkNMLYn13LghD6P9TTjQZ0KCOCwmc2TMCIhJlvzOYX6Cc 2215 wJZYLO1ltgfnHEuh8ijv0u3d/BUpsknYKBSJGUyMEZ9iUtbFPVfXBGSTi3gcWHtl 2216 IrM7wjswJwHWSvZKWUs+YWWJTwj0apG6ViGllwOAqR9C48uLKgFWPbMoTpolnp69 2217 eiij5ZHxB0i7SI80D+r65b+fqaFzVIJXVEI0zu/mIilbYBnGkhLI/Naw1m2e1qVJ 2218 mi1JBjXLAT3pEJDh8b3Lpgw= 2220 Unwrapping the outer Cryptographic Layer of this message yields the 2221 following MIME part (with its own Cryptographic Layer): 2223 Content-Transfer-Encoding: base64 2224 Content-Type: application/pkcs7-mime; name="smime.p7m"; 2225 smime-type="signed-data" 2227 MIIJdQYJKoZIhvcNAQcCoIIJZjCCCWICAQExDTALBglghkgBZQMEAgEwggP5Bgkq 2228 hkiG9w0BBwGgggPqBIID5kZyb206IEFsaWNlIExvdmVsYWNlIDxhbGljZUBzbWlt 2229 ZS5leGFtcGxlPg0KVG86IEJvYiBCYWJiYWdlIDxib2JAc21pbWUuZXhhbXBsZT4N 2230 CkRhdGU6IFdlZCwgMjcgTm92IDIwMTkgMDE6MjQ6MDAgLTA3MDANClN1YmplY3Q6 2231 IEJhckNvcnAgY29udHJhY3Qgc2lnbmVkLCBsZXQncyBnbyENCkNvbnRlbnQtVHlw 2232 ZTogbXVsdGlwYXJ0L21peGVkOyBib3VuZGFyeT0iNmFlIjsgcHJvdGVjdGVkLWhl 2233 YWRlcnM9InYxIg0KTWVzc2FnZS1JRDogPHNtaW1lLXNpZ24rZW5jK2xlZ2FjeS1k 2234 aXNwQHByb3RlY3RlZC1oZWFkZXJzLmV4YW1wbGU+DQoNCi0tNmFlDQpjb250ZW50 2235 LXR5cGU6IHRleHQvcGxhaW47IHByb3RlY3RlZC1oZWFkZXJzPSJ2MSINCkNvbnRl 2236 bnQtRGlzcG9zaXRpb246IGlubGluZQ0KDQpTdWJqZWN0OiBCYXJDb3JwIGNvbnRy 2237 YWN0IHNpZ25lZCwgbGV0J3MgZ28hDQoNCi0tNmFlDQpDb250ZW50LVR5cGU6IHRl 2238 eHQvcGxhaW47IGNoYXJzZXQ9InVzLWFzY2lpIg0KDQpIaSBCb2IhDQoNCkkganVz 2239 dCBzaWduZWQgdGhlIGNvbnRyYWN0IHdpdGggQmFyQ29ycCBhbmQgdGhleSd2ZSBz 2240 ZXQgdXMgdXAgd2l0aA0KYW4gYWNjb3VudCBvbiB0aGVpciBzeXN0ZW0gZm9yIHRl 2241 c3RpbmcuDQoNClRoZSBhY2NvdW50IGluZm9ybWF0aW9uIGlzOg0KDQogICAgICAg 2242 IFNpdGU6IGh0dHBzOi8vYmFyY29ycC5leGFtcGxlLw0KICAgIFVzZXJuYW1lOiBl 2243 eGFtcGxlY29ycHRlc3QNCiAgICBQYXNzd29yZDogY29ycmVjdC1ob3JzZS1iYXR0 2244 ZXJ5LXN0YXBsZQ0KDQpQbGVhc2UgZ2V0IHRoZSBhY2NvdW50IHNldCB1cCBhbmQg 2245 YXBwbHkgdGhlIHRlc3QgaGFybmVzcy4NCg0KTGV0IG1lIGtub3cgd2hlbiB5b3Un 2246 dmUgZ290IHNvbWUgcmVzdWx0cy4NCg0KKHRoaXMgaXMgdGhlICdzbWltZS1zaWdu 2247 K2VuYytsZWdhY3ktZGlzcCcgbWVzc2FnZSkNCg0KVGhhbmtzLCBBbGljZQ0KLS0g 2248 DQpBbGljZSBMb3ZlbGFjZQ0KUHJlc2lkZW50DQpFeGFtcGxlIENvcnANCg0KLS02 2249 YWUtLQ0KoIIDcjCCA24wggJWoAMCAQICFGeCtFlzUkvB9HFHGWrw/RGKqkwLMA0G 2250 CSqGSIb3DQEBDQUAMC0xKzApBgNVBAMTIlNhbXBsZSBMQU1QUyBDZXJ0aWZpY2F0 2251 ZSBBdXRob3JpdHkwIBcNMTkxMTIwMDY1NDE4WhgPMjA1MjA5MjcwNjU0MThaMBkx 2252 FzAVBgNVBAMTDkFsaWNlIExvdmVsYWNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A 2253 MIIBCgKCAQEAw+6t+WXRtiQM8yRjWQ2fbFewCodIZUX6BY02TeZuEXoEAGEsmoON 2254 6LlotcUTdGr39FE2K8IytOKkXVexswgAqBCqv8YjVDrI3yV82wrm5Td32TDlw7IS 2255 igak4ZSu+UowPQs8YO3oxqImP4onZNHvdZ3it9EggmgUyZX0dmQ6z5O9yDzHpLMa 2256 E2rXxfYcPXQwPvx4tcqbTf2htEP7PYnBa8a+sts0F7I7kD5ozGYI9dGg/XGs1lYE 2257 WAoH5YZgNFdbkJdcKG2FPAwFcVZ/hoGm6soxkDKMrYSCtBp+fqH8MV11DP821PoO 2258 vtSEnaF8UURbaths2yKpAB2WUJvgW5xa4QIDAQABo4GXMIGUMAwGA1UdEwEB/wQC 2259 MAAwHgYDVR0RBBcwFYETYWxpY2VAc21pbWUuZXhhbXBsZTATBgNVHSUEDDAKBggr 2260 BgEFBQcDBDAPBgNVHQ8BAf8EBQMDB6AAMB0GA1UdDgQWBBSsLlRapP1VGK8u6GZE 2261 ONEl0dcAeTAfBgNVHSMEGDAWgBS3Uk1zwIg9ssN6WgzzlPf3gKJ32zANBgkqhkiG 2262 9w0BAQ0FAAOCAQEAe+qOGM+8q1UhXKV6i63BrXSOKvd2iglxAggszUC6eMnrIem6 2263 6mmRzSbcGHCeU6m1MpvYSe9IiROIxjTfsgGUdZbbXtBxSmCASjOBCbphvvtoam1G 2264 i8+LZdOgR2kDwr//TYjWO6vUfXPwerNWMx4cKpFobdmvgLYCeAZKRvoPjJmTEFfw 2265 KO0cCxSifTpTFiwZhFxXKSCTdB6T2rE9JxJfzJqLUrvvEZwpQIt8hX8kym/vKw+1 2266 cbsl3rag2enVP/f4qg/0mUuzkCI8sLXd+N5gAs9wdUZRcTB0gOnUAH9m7RrpqkdC 2267 ogKdypGEQHj6GiamJAe2WndOp4BZdBtBRzjfuzGCAdkwggHVAgEBMEUwLTErMCkG 2268 A1UEAxMiU2FtcGxlIExBTVBTIENlcnRpZmljYXRlIEF1dGhvcml0eQIUZ4K0WXNS 2269 S8H0cUcZavD9EYqqTAswCwYJYIZIAWUDBAIBoGkwGAYJKoZIhvcNAQkDMQsGCSqG 2270 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMTI3MDgyNDAwWjAvBgkqhkiG9w0B 2271 CQQxIgQgX1r//iHA8sj6FZnDpQl9jK7M6APu04IWNEm5nuSzt7MwDQYJKoZIhvcN 2272 AQEBBQAEggEAaeYcpNS5ON33UDUWO/kaIOKbD1JQRDsoldNC/UNlO1X1PzvL43sR 2273 g77FEV6bcl3kWReTz5aYHr4PFjoQspeGWQvQpeUW8bIlZ5nxb5O/zUcx62mbciHZ 2274 C2quuvTBGoJRfxMTD6pCPoyRW9PF2o9O4eB8lORQ0xML3jXb3oN1EF0nFXXs7Fe7 2275 8KRWA4FVldJDrgRLGdrrF73kvpTZuVGkMYb2sCosRiBO+rk0LFvOcBIQO3DjbBEM 2276 dy5zeex+eN5WMbI+lFJt8eM0fDQencMHIp2AmP4AVAashtXomx7ZIMI/fDdVxlx0 2277 OcDnTZCx0+vVBfM7d6TE91Uky6ELrMbq/Q== 2279 Unwrapping the inner Cryptographic Layer yields the Cryptographic 2280 Payload, which includes the Legacy Display part: 2282 From: Alice Lovelace 2283 To: Bob Babbage 2284 Date: Wed, 27 Nov 2019 01:24:00 -0700 2285 Subject: BarCorp contract signed, let's go! 2286 Content-Type: multipart/mixed; boundary="6ae"; protected-headers="v1" 2287 Message-ID: 2289 --6ae 2290 content-type: text/plain; protected-headers="v1" 2291 Content-Disposition: inline 2293 Subject: BarCorp contract signed, let's go! 2295 --6ae 2296 Content-Type: text/plain; charset="us-ascii" 2298 Hi Bob! 2300 I just signed the contract with BarCorp and they've set us up with 2301 an account on their system for testing. 2303 The account information is: 2305 Site: https://barcorp.example/ 2306 Username: examplecorptest 2307 Password: correct-horse-battery-staple 2309 Please get the account set up and apply the test harness. 2311 Let me know when you've got some results. 2313 (this is the 'smime-sign+enc+legacy-disp' message) 2315 Thanks, Alice 2316 -- 2317 Alice Lovelace 2318 President 2319 Example Corp 2321 --6ae-- 2323 9.10. Encrypted-only (unsigned) S/MIME Message with Protected Headers 2324 and Legacy Display 2326 This shows the same encrypted message as Section 9.9, but formulated 2327 without a signature layer, so it is "encrypted-only". 2329 Note that the lack of any signature layer means that the only forms 2330 of cryptographic protection these header receive is confidentiality. 2332 An arbitrary adversary could forge a message with arbitrary headers 2333 (and content), and package it in this same form. Consequently, the 2334 only thing "protected" about the headers in this example is 2335 confidentiality for any obscured headers (just the "Subject" in this 2336 case). 2338 Presenting the cryptographic properties of the headers of such a 2339 message in a meaningful way to the end user is a subtle and 2340 challenging task, which this document cannot cover. 2342 Its MIME message structure is: 2344 └─╴application/pkcs7-mime smime-type="enveloped-data" 2345 ↧ (decrypts to) 2346 └┬╴multipart/mixed ← Cryptographic Payload 2347 ├─╴text/plain ← Legacy Display 2348 └─╴text/plain 2350 For this message, the session key is an AES-256 key with value 2351 "e94f6aaef7f14d6ceeac770c46d7f4885e81fbeaf1462d0fdadfce6c581525e2" 2352 (in hex). 2354 Received: from localhost (localhost [127.0.0.1]); Wed, 27 Nov 2019 2355 01:27:28 -0700 (UTC-07:00) 2356 MIME-Version: 1.0 2357 Content-Transfer-Encoding: base64 2358 Content-Type: application/pkcs7-mime; name="smime.p7m"; 2359 smime-type="enveloped-data" 2360 From: Alice Lovelace 2361 To: Bob Babbage 2362 Date: Wed, 27 Nov 2019 01:27:00 -0700 2363 Message-ID: 2364 Subject: ... 2366 MIIG5QYJKoZIhvcNAQcDoIIG1jCCBtICAQAxggLCMIIBXQIBADBFMC0xKzApBgNV 2367 BAMTIlNhbXBsZSBMQU1QUyBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCFCJT7jBtAgsf 2368 As31ycE+Ot95phvCMA0GCSqGSIb3DQEBAQUABIIBADEhlzhFzYj6tUAdsRCrSiLl 2369 d9cgKtlAesJ4cDY4szFWAbnwrCmEcFxjFDUOjbfQCYCG80Sxd+xntni73I7PI2rR 2370 QLjk3w9VhLwFRyzy7qyJi2CavjKTxysX9f36+FXA+THfVQRM5ypiyYJg91X51PNX 2371 hJj3DHrnxqKeSl/z1hdt9r+s6XAUCBSvL99BGnODWhNIZtPDzt8fMNcgarfw+D5F 2372 IZJb6+wX30tkztHkpHHKrrDPveyfnlS/p06Gi3ekrrhBtMQMRb9PA/E+ivDPktsm 2373 aKg0Oauw4oZSKW3f4ukYhbnndbbagNsnTfs/QFy/p+hhKTrfCd0h1N8mTzedVX0w 2374 ggFdAgEAMEUwLTErMCkGA1UEAxMiU2FtcGxlIExBTVBTIENlcnRpZmljYXRlIEF1 2375 dGhvcml0eQIUZ4K0WXNSS8H0cUcZavD9EYqqTAswDQYJKoZIhvcNAQEBBQAEggEA 2376 FaK5QaPXJ133D2uybQt//oeDm6PkCAFW9YVOgjnLLz6FD54Dt2i1KCQu1Xlg9W3P 2377 1zJdYXOftDgilylNfmt/muEsvbRfFtMWUq0VGirHz//BWmY2cW/ocinFO514iviL 2378 MLE1umsXRNwVIVIk/uh7AmqXjPkRZgRgIMUbSbtmW4DDja+ZM0vmqFQ1iUIlApth 2379 FpjFfPDHHD8isLTbGi2iK6dEN3DIJFGbg5o3nK6yAhVZ7x3LfFNSNVDDSY5mPFG9 2380 Vm6uRgEE3Y5P6DbXXo6MHTgg0XY2f4y6MEWhOg37NT9aFAfzBBxJ1oSBWpOOfZnV 2381 K1DvAwPaemSRz9oWDcBM8DCCBAUGCSqGSIb3DQEHATAUBggqhkiG9w0DBwQIsFkN 2382 8DEx8muAggPgWGF2WsPq3/a9jUa5GA0YFPiINuETCGTNaEXiVxnT0h0CF+EhZ0T2 2383 HFCiZEM0dzO05zt9WdVvAREaCSh7ZWG9D9wJF9x+tqQbzMuJ2AdKuoOH73kClvkx 2384 pHxANLhkY7hzIqRb/eLG5D7Xh8iCDiFecXDh7EHqD/R+sfLN9aHKOcKyY36kesBQ 2385 R8aHZbbFnnD+oXSDNIPcntGG3BSGMxsWuOp+rpTKeIHWFIungDNKsLIy3kWleENw 2386 FVIcjUF6QhI1HYW6BeXuVq40GV2OOkmB24rYEW1Jg0hAtY+5rn2mRoyxvUC87bjQ 2387 hLu6xgPmhun9J324eM5aYVwkmVBnRW9hyxClZ7Sv0zlL7lGQ0VQG+zWHeJ+h/M2j 2388 mQpLgAUEGxxNCm5ASHuXPIN6pSvrOVplrT8kKLPpmMYEwmTX2/rBO4P8I8uNrqYD 2389 AyX8p0/l2ArczkWzGTz2luBahrD+cTZPApe5SeyXOxWBl1Lmb0G8o4twBeeBLiHP 2390 XwYvttx0JYG/hc/lmMpEemJqwj9uZ3wGD03dIhhDX2Oj4ek/7jT6yqJh8C1H+PqA 2391 +HNfNXsFQDrRORoqJS8YVEiYRDQNyePy2ugzLTh88nPtJp92hY7bk9zl3AYaiVFH 2392 +szlLoyzfM9D+geZemR8XfI2ijGnrWMlnyPah/zA6J6RwemhuiMklZGYG85hMU9H 2393 K4CFVM+m7xYxKpwFVnmkVZjzWInirJhehElhtCXpx/IFGxH9CPbCyEZV1WVStrl/ 2394 0fWTGicMXez6hVQCadWCXy96/eLIXOrC54gSoIJX2TD6jdVEu1YptutyGI6KdQ2p 2395 yXwhs98Uj7DM3nmFeAcjjN3e8pPoX7aG8eP+MfmHlWN6jA44jMaJmIdp9J20g74J 2396 MdjvnHa/cGibW/RamPiFObN0F94A83vcpUfU/zZ8cFHi/3/lN6Rm9+3/giGRZa9E 2397 Y6e2/CEq1cUbPQ09fPwRJmjZCfDce71DKe+ZFGdYtFR7JwDEeZ6BB4Ff4rXctcWD 2398 PgUJqUGv/SXBcFn4cNUK9MYYqVu1ovd/T7FMf+i3c5MH6BRCvft/i5aeBR+A26Gk 2399 2awtBPYdHW6+AslrFjncBbtPDlU6vX9AWuC0k0MQYnNkTWS8gTvsriXJZ6Zu5iFE 2400 ExNuFz7YcnMKnguOn2ph5azzeMm83AYzWXzZPu3mdr5Siuu/Ke38oADKP+BZ08Za 2401 XVvKvvfnRPXO9kG9hgvEMRU9KOcxn82XoGPNZib+9SPa2zYx5P6HX1Bqe/cmKAen 2402 FKEiJLSTP2/pc6AWAICqJl978HaUHfMFiN7jEUppAifpAWqNcIGSW5w= 2404 Unwrapping the single-layer Cryptographic Envelope of this message 2405 yields the following MIME structure: 2407 From: Alice Lovelace 2408 To: Bob Babbage 2409 Date: Wed, 27 Nov 2019 01:27:00 -0700 2410 Subject: BarCorp contract signed, let's go! 2411 Content-Type: multipart/mixed; boundary="6ae"; protected-headers="v1" 2412 Message-ID: 2414 --6ae 2415 content-type: text/plain; protected-headers="v1" 2416 Content-Disposition: inline 2418 Subject: BarCorp contract signed, let's go! 2420 --6ae 2421 Content-Type: text/plain; charset="us-ascii" 2423 Hi Bob! 2425 I just signed the contract with BarCorp and they've set us up with 2426 an account on their system for testing. 2428 The account information is: 2430 Site: https://barcorp.example/ 2431 Username: examplecorptest 2432 Password: correct-horse-battery-staple 2434 Please get the account set up and apply the test harness. 2436 Let me know when you've got some results. 2438 (this is the 'smime-enc+legacy-disp' message) 2440 Thanks, Alice 2441 -- 2442 Alice Lovelace 2443 President 2444 Example Corp 2446 --6ae-- 2448 9.11. Encrypted-only (unsigned) PGP/MIME Message with Protected Headers 2449 and Legacy Display 2451 This shows a comparable encrypted-only (unsigned) message, like 2452 Section 9.10 , but using PGP/MIME instead of S/MIME. 2454 Note that the lack of any signature layer means that the only forms 2455 of cryptographic protection these header receive is confidentiality. 2457 An arbitrary adversary could forge a message with arbitrary headers 2458 (and content), and package it in this same form. Consequently, the 2459 only thing "protected" about the headers in this example is 2460 confidentiality for any obscured headers (just the "Subject" in this 2461 case). 2463 Presenting the cryptographic properties of the headers of such a 2464 message in a meaningful way to the end user is a subtle and 2465 challenging task, which this document cannot cover. 2467 Its MIME message structure is: 2469 └┬╴multipart/encrypted 2470 ├─╴application/pgp-encrypted 2471 └─╴application/octet-stream 2472 ↧ (decrypts to) 2473 └┬╴multipart/mixed ← Cryptographic Payload 2474 ├─╴text/plain ← Legacy Display 2475 └─╴text/plain 2477 For this message, the session key is an AES-256 key with value 2478 "4f3e7e3cb4a49747f88d232601fa98a29d7427e8f80882464cfbca3dcb847356" 2479 (in hex). 2481 Received: from localhost (localhost [127.0.0.1]); Mon, 21 Oct 2019 2482 07:30:28 -0700 (UTC-07:00) 2483 MIME-Version: 1.0 2484 Content-Type: multipart/encrypted; boundary="c07"; 2485 protocol="application/pgp-encrypted" 2486 From: Alice Lovelace 2487 To: Bob Babbage 2488 Date: Mon, 21 Oct 2019 07:30:00 -0700 2489 Message-ID: 2490 Subject: ... 2492 --c07 2493 content-type: application/pgp-encrypted 2495 Version: 1 2497 --c07 2498 content-type: application/octet-stream 2500 -----BEGIN PGP MESSAGE----- 2501 wV4DR2b2udXyHrYSAQdAX8p0+U8WbFNtCeGX5no1X1mSPqdmwrJIVWVZT8LS/yIw 2502 lv+vor/Wsh7cKBofs1yIlPR4u/01EKjj+XkgD+h1BEtHDHp9ckuzBHmOI6YL0AZU 2503 wcDMA3wvqk35PDeyAQwAiGcX6KN1jS+gHFAUcWWvc672CPPOhIhS91BGz4MMiV/G 2504 Prm+dwIE5V7I6Sh7XMEons1Z7EdUbpxP/OufCTQwrkXlzTTIt/0TMZkZxpDvLPpA 2505 EzkdW2edtMhbTtqbGzjXgOsBVqnRZP6CaTfCba5tsVFOJ8XO+WL1ARQSDVKWPuob 2506 uXT+s4sZIam0JjnrxGYCD5NTjQt4UUmxlyXxQLEwN90wMLs8DrQ5kxcMHUU6kjDT 2507 7icQRtsuIXXzrj0AVie0/Vd1ItKjrIo3eMvpi8G3GtB5VXYB2RPGKY6/cMISYGbx 2508 s7aJVlWOTrriO4p4vFiOI6iM1YOdinbgCbzTXK+aYJpw5TmG/V5sHfRQXu77HBll 2509 8BZdC+s6v5MWSdB9qVyvnd/e97mfi+ySa4Lw4yeLJFz7OeuL8C1SeQWhTmWIkwn6 2510 FjiLFoxzkkLUE8vxcAYIUuzFMPCUEeXjH8EoLBwFz4jDOTQ4FJqn61v9AEiJS4P4 2511 mkgKdrvGqCSkZu6DpLgi0sGGAYu7ECCJLDcNTM6/S6o9AU9LcJJPgbd2wIylJyFY 2512 D6ygG0D5skuKRsJ7I/VJLx5SI6rkfTqd+vXcVcEX7vuhFAap988haqxS4fsFb/0L 2513 CeLwZH94Y9hAP7Rz/hDiwHKcV1S0eAFFEfZ3u7kmMM2+o7zePIeimHbjSDjSAts5 2514 GhZV7UDFyy6RnhSYgTNHwOhZToEPPLbHOmTzNZNp3tiS3apvYe6Yx9fCspd63Cet 2515 tW5Y0vCpHO0hJPIIv0ucVZsstn56SDBaYh70Fgq7M5UeK3AZ5KvH4cee4qd0KBgK 2516 JZXBtIsoMICQj6Xw7ecmwPO5huh1EQ0cfqdSuEu+k2ifgnOMAPe85syK/d4yVxUB 2517 wSj7Jk5r2Ytqe8ZXVoM4kYIKxVpuXmxb78KoUPvBUkLzqOMHwYpk2BjPQjZ8xqL7 2518 oKQ8ywpm90SBB7DCgES7oIgrG5ZMovqVkNppdJ3TrvkdgWtctbGe/Pb1WapMamQ/ 2519 a99+zfc9k63hDV6GW7mM7AiTO5cqkOvYEYnJShTpszf0eiIe+smM/3As4HJstCx7 2520 Wiej+lM/Rqxp81nP8R78+al6iyIdbHZ6LSxD5vKgZbhT3OQng0goZ3XQZXmIV/cZ 2521 hVpPIEDgUzQi3qJq9POPejosLQZhU41kOcyDdLZmPm7OIRG7+b2X8JRbmhtg8FMA 2522 szxT753uRpiGsKYb3dmOX9JYcDVbe9gFoIj2PktU2L96I9J79IVn9gtEeMYdR6Xn 2523 w9rKgAyGiieepz5ygl9cRaGVFfLnesAB 2524 =zBUs 2525 -----END PGP MESSAGE----- 2527 --c07-- 2529 Unwrapping the single-layer Cryptographic Envelope of this message 2530 yields the following MIME structure: 2532 From: Alice Lovelace 2533 To: Bob Babbage 2534 Date: Mon, 21 Oct 2019 07:30:00 -0700 2535 Subject: BarCorp contract signed, let's go! 2536 Content-Type: multipart/mixed; boundary="6ae"; protected-headers="v1" 2537 Message-ID: 2539 --6ae 2540 content-type: text/plain; protected-headers="v1" 2541 Content-Disposition: inline 2543 Subject: BarCorp contract signed, let's go! 2545 --6ae 2546 Content-Type: text/plain; charset="us-ascii" 2548 Hi Bob! 2550 I just signed the contract with BarCorp and they've set us up with 2551 an account on their system for testing. 2553 The account information is: 2555 Site: https://barcorp.example/ 2556 Username: examplecorptest 2557 Password: correct-horse-battery-staple 2559 Please get the account set up and apply the test harness. 2561 Let me know when you've got some results. 2563 (this is the 'pgpmime-enc+legacy-disp' message) 2565 Thanks, Alice 2566 -- 2567 Alice Lovelace 2568 President 2569 Example Corp 2571 --6ae-- 2573 9.12. An Unfortunately Complex Example 2575 For all of the potential complexity of the Cryptographic Envelope, 2576 the Cryptographic Payload itself can be complex. The Cryptographic 2577 Envelope in this example is the same as (Section 9.8). The 2578 Cryptographic Payload has protected headers and a legacy display part 2579 (also the same as Section 9.8), but in addition Alice's MUA composes 2580 a message with both plaintext and HTML variants, and Alice includes a 2581 single attachment as well. 2583 While this PGP/MIME message is complex, a modern MUA could also 2584 plausibly generate such a structure based on reasonable commands from 2585 the user composing the message (e.g., Alice composes the message with 2586 a rich text editor, and attaches a file to the message). 2588 The key takeaway of this example is that the complexity of the 2589 Cryptographic Payload (which may contain a Legacy Display part) is 2590 independent of and distinct from the complexity of the Cryptographic 2591 Envelope. 2593 This message has the following structure: 2595 └┬╴multipart/encrypted 2596 ├─╴application/pgp-encrypted 2597 └─╴application/octet-stream 2598 ↧ (decrypts to) 2599 └┬╴multipart/signed 2600 ├┬╴multipart/mixed ← Cryptographic Payload 2601 │├─╴text/plain ← Legacy Display Part 2602 │└┬╴multipart/mixed 2603 │ ├┬╴multipart/alternative 2604 │ │├─╴text/plain 2605 │ │└─╴text/html 2606 │ └─╴text/x-diff ← attachment 2607 └─╴application/pgp-signature 2609 For this message, the session key is an AES-256 key with value 2610 "1c489cfad9f3c0bf3214bf34e6da42b7f64005e59726baa1b17ffdefe6ecbb52" 2611 (in hex). 2613 Received: from localhost (localhost [127.0.0.1]); Mon, 21 Oct 2019 2614 07:33:28 -0700 (UTC-07:00) 2615 MIME-Version: 1.0 2616 Content-Type: multipart/encrypted; boundary="241"; 2617 protocol="application/pgp-encrypted" 2618 From: Alice Lovelace 2619 To: Bob Babbage 2620 Date: Mon, 21 Oct 2019 07:33:00 -0700 2621 Message-ID: 2622 Subject: ... 2624 --241 2625 content-type: application/pgp-encrypted 2627 Version: 1 2628 --241 2629 content-type: application/octet-stream 2631 -----BEGIN PGP MESSAGE----- 2633 wV4DR2b2udXyHrYSAQdArYyyCfDzUyr02W1QjJmXivzmT6XooGh6HMhPLmD/pkIw 2634 jPsIvobM6mmvctBWnGsg2IUVx3clXJum+/UmVuk5BQv0xk6x6kDt2WtwE3fWhop3 2635 wcDMA3wvqk35PDeyAQv+JZG91UzU5NJOY1Yxoadl8bNBkTdlBWN8DJEMhJd+Hmm5 2636 KDjxBtAHWcsjzkiEdZcoR9EvrfFWBCTo+AmfnDi5YEJaX6GNr61VHKDcxowCrNsC 2637 lwfdXX+TIe0cwX7RW1yvWGxCs7alVHuxUa/hDe7DklAIxOicdTKz+lpDYFTr8T9E 2638 Q/jtkk95paCzmtZ53RKaEMzizaJXD+B2s0/pBp6aJGxYMRF4yhez+b4HakUz2GK6 2639 tvFoN/qqXT97+cpREAhDFqtgHp6QmW4UUTgWaZ7G7TSDU7AuuizxGCC5yGj0l19B 2640 iwm9xoG6YvjQxKbq6klaRZabUzFxyIKcuU8iDM9eZFlHu0QFhZKYSEmVaVNb9G1C 2641 i30ncaq7Ylkj73o90ogsiLQwqdTRNZKz+65mPSzKj6HI7gu1w9Yf0MHcsHNPG9sI 2642 qTE/a88b17fc5qEEzkk8gmtnKyDI1bRvhxkrRNGWNeW6ZUEFdinYi5fAD5QYXMSW 2643 rIB+ELy/ZUYHHy31UAvS0sPRAXgbRmpFyrfzGgZMfkSbH2n+ngl+21rDjnABUetE 2644 vSdvPCL57jS+w4MaUHz7wSjv1QnzBvRts/AJAvnFYhRYe5vP3wfDIKndpnhCz7EE 2645 QUE5d3upWL2fQ2UP/hLWUjbC6FhD+GFbyw38XomjBvvznT2NAFdZRlqqXfdw+dkG 2646 /daknCkHtyZ3Z1kQkTyyEOkuIopr2cJUWLghOEuv0OEi842NsaDeKa05GepNXlOc 2647 9M9ScoUurCUGCa31tCe54GyceWs390ir6uiTeiJ5m11N0KpuoDfiHKvVdMO5Ge8+ 2648 SLxzO3gyXEUPV//lhqqy3DwgYmL4M7SJxpJFLeu/YbguQuu4jpp/XBgZkcOeB//F 2649 FHShbmH6oEIt59auutJ3I/NWI6n8EIOmRex64RYp8Bu3SLvVfsxlkjXHZk3XX52n 2650 vU4oUgHTpzUkJ8NxxmPOZY8tu5MB7wBRp2Cqxq+rOKyHQPOrLU7iej0tXMHyHzwh 2651 QZ3/6BX9GR9ZBovqdZW0IzswjEradRfJXvOdL9QEL6V41m1tnFpeuaeNGCpMVqxN 2652 zvQf1T6z1JnX/hG0XwkKmFYz92MaeofNjx6ke++cAgfdRAqQxp77RkfBZdjtDFVV 2653 DggHI67I7DSs/sF+0ftJRet6E7rJ1XYKJ24aB8ZkplRU/eRVpXTaNnluoI7nMG2p 2654 Uf/lBTS+H+2jd5PB7vcIsvrTRuvCDqktniTk2eF3yYNHVEPlP7TmpqIVlXIFgc2Z 2655 NygSO2HGQ56Cv8/HZKxaJ1tZDbUy9fVRtetj11psol5CfoGi8IVInI6gMWu3IBbb 2656 gqpv00YldQintY/BK49Q0y31Sh/5tgz+n6CZVxPxP1j+kVzOUGNy+SeThDC+H+lY 2657 d6Dd5+M+H5b/+XAnBMKArzQVxDCSPtpVI08qF1bwmZBB/ryylpLLDHpoYgOLC3Dk 2658 X/ICCAyk6n3Rz4IyupFuKNaEaiIwpjZZjqYtHbvMNJj+55crArYLfdadpTPeX5q8 2659 2QUg03J5ShkTlgp/a6qBuoUC3yHDcA0EiqGCMsF4Mmny6MtyzkKQXlgBHCDSGOyO 2660 NTnhfJxiKs1cahWf7ix9pO5dn3lTqr1+t9usJtrZuhugVW0nbzQgfA4DNULbTsu5 2661 odSTwvrBczga7+JcvDJ+QELLiP8n1QcU2VkvCVwy5RHkwWzY0J84jYLh1VZEbbWa 2662 YDFXbQzCWGRcjubwb5Eet6pEPiNnTVvo6gGQx21Bue5kTslIZO1wRLiioU3vP4TO 2663 x4/6AaJt8MmSxXiGd9fjTT5ej7iawzH9qXQ4OUmj3MvWNiOrhRittRZyjXVAxdYG 2664 /F9sj5kkN0zFsSNaK3+Mi96Il6h6h4aYMvbrd1zapA8oqj6MpZRSeLLOHiHqmbcC 2665 IMXywNeKw2ZZSM6FNjU33fEDIQnO+jXLVazdkmqtBB0sUiuBuvMrKoJtr79rmiXC 2666 K77CmcJbikYpM0hnMyDfrtQqCEW4dKZ1c8uuFJQrEhRbQ24KP+Dq70ynNiODalKN 2667 s4RgECgNgjES6ow4eIDS7vTo3xctCtXfzI5pkw8ub1rSM+Q= 2668 =wxHa 2669 -----END PGP MESSAGE----- 2671 --241-- 2673 Unwrapping the encryption Cryptographic Layer yields the following 2674 content: 2676 Content-Type: multipart/signed; boundary="c72"; 2677 protocol="application/pgp-signature"; micalg="pgp-sha512" 2679 --c72 2680 From: Alice Lovelace 2681 To: Bob Babbage 2682 Date: Mon, 21 Oct 2019 07:33:00 -0700 2683 Subject: BarCorp contract signed, let's go! 2684 Content-Type: multipart/mixed; boundary="6ae"; protected-headers="v1" 2685 Message-ID: 2687 --6ae 2688 content-type: text/plain; protected-headers="v1" 2689 Content-Disposition: inline 2691 Subject: BarCorp contract signed, let's go! 2693 --6ae 2694 Content-Type: multipart/mixed; boundary="8df" 2696 --8df 2697 Content-Type: multipart/alternative; boundary="32c" 2699 --32c 2700 Content-Type: text/plain; charset="us-ascii" 2702 Hi Bob! 2704 I just signed the contract with BarCorp and they've set us up with 2705 an account on their system for testing. 2707 The account information is: 2709 Site: https://barcorp.example/ 2710 Username: examplecorptest 2711 Password: correct-horse-battery-staple 2713 Please get the account set up and apply the test harness. 2715 Let me know when you've got some results. 2717 (this is the 'unfortunately-complex' message) 2719 Thanks, Alice 2720 -- 2721 Alice Lovelace 2722 President 2723 Example Corp 2724 --32c 2725 Content-Type: text/html; charset="us-ascii" 2727

Hi Bob! 2728

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

2732 The account information is: 2733

2734
Site
2735 https://barcorp.example/ 2736
2737
Username
examplecorptest
2738
Password
correct-horse-battery-staple
2739

2740 Please get the account set up and apply the test harness. 2741

2742 Let me know when you've got some results. 2743

2744 (this is the 'unfortunately-complex' message) 2745

2746 Thanks, Alice
2747 --
2748 Alice Lovelace
2749 President
2750 Example Corp
2751

2753 --32c-- 2755 --8df 2756 Content-Type: text/x-diff; charset="us-ascii" 2757 Content-Disposition: inline; filename="testharness-config.diff" 2759 diff -ruN a/testharness.cfg b/testharness.cfg 2760 --- a/testharness.cfg 2761 +++ b/testharness.cfg 2762 @@ -13,3 +13,8 @@ 2763 endpoint = https://openpgp.example/test/ 2764 username = testuser 2765 password = MJVMZlHR75mILg 2766 + 2767 +[barcorp] 2768 +endpoint = https://barcorp.example/ 2769 +username = examplecorptest 2770 +password = correct-horse-battery-staple 2771 --8df-- 2773 --6ae-- 2775 --c72 2776 content-type: application/pgp-signature 2778 -----BEGIN PGP SIGNATURE----- 2780 wnUEARYKAB0FAl2twZwWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj 2781 jnUTAP9YDBbjItEr14L3f/hpRDdkiexX96wHRZOZlP4VlsPbmgEA/zNQ5GZxOW70 2782 EyF6maqK0Dedw/FXsbL32iFiXMGaTgY= 2783 =EuL1 2784 -----END PGP SIGNATURE----- 2786 --c72-- 2788 10. IANA Considerations 2790 FIXME: register content-type parameter for legacy-display part 2792 MAYBE: provide a list of user-facing headers, or a new "user-facing" 2793 column in some table of known RFC5322 headers? 2795 MAYBE: provide a comparable indicator for which headers are 2796 "structural" ? 2798 11. Security Considerations 2800 This document describes a technique that can be used to defend 2801 against two security vulnerabilities in traditional end-to-end 2802 encrypted e-mail. 2804 11.1. Subject Leak 2806 While e-mail structure considers the Subject header to be part of the 2807 message metadata, nearly all users consider the Subject header to be 2808 part of the message content. 2810 As such, a user sending end-to-end encrypted e-mail may inadvertently 2811 leak sensitive material in the Subject line. 2813 If the user's MUA uses Protected Headers and obscures the Subject 2814 header as described in Section 4.2 then they can avoid this breach of 2815 confidentiality. 2817 11.2. Signature Replay 2819 A message without Protected Headers may be subject to a signature 2820 replay attack, which attempts to violate the recipient's expectations 2821 about message authenticity and integrity. Such an attack works by 2822 taking a message delivered in one context (e.g., to someone else, at 2823 a different time, with a different subject, in reply to a different 2824 message), and replaying it with different message headers. 2826 A MUA that generates all its signed messages with Protected Headers 2827 gives recipients the opportunity to avoid falling victim to this 2828 attack. 2830 Guidance for how a message recipient can use Protected Headers to 2831 defend against a signature replay attack are out of scope for this 2832 document. 2834 11.3. Participant Modification 2836 A trivial (if detectable) attack by an active network adversary is to 2837 insert an additional e-mail address in a "To" or "Cc" or "Reply-To" 2838 or "From" header. This is a staging attack against message 2839 confidentiality - it relies on followup action by the recipient. 2841 For an encrypted message that is part of an ongoing discussion where 2842 users are accustomed to doing "reply all", such an insertion would 2843 cause the replying MUA to encrypt the replying message to the 2844 additional party, giving them access to the conversation. If the 2845 replying MUA quotes and attributes cleartext from the original 2846 message within the reply, then the attacker learns the contents of 2847 the encrypted message. 2849 As certificate discovery becomes more automated and less noticeable 2850 to the end user, this is an increasing risk. 2852 An MUA that rejects Exposed Headers in favor of Protected Headers 2853 should be able to avoid this attack when replying to a signed 2854 message. 2856 12. Privacy Considerations 2858 This document only explicitly contemplates confidentiality protection 2859 for the Subject header, but not for other headers which may leak 2860 associational metadata. For example, "From" and "To" and "Cc" and 2861 "Reply-To" and "Date" and "Message-Id" and "References" and "In- 2862 Reply-To" are not explicitly necessary for messages in transit, since 2863 the SMTP envelope carries all necessary routing information, but an 2864 encrypted [RFC5322] message as described in this document will 2865 contain all this associational metadata in the clear. 2867 Although this document does not provide guidance for protecting the 2868 privacy of this metadata directly, it offers a platform upon which 2869 thoughtful implementations may experiment with obscuring additional 2870 e-mail headers. 2872 13. Document Considerations 2874 [ RFC Editor: please remove this section before publication ] 2876 This document is currently edited as markdown. Minor editorial 2877 changes can be suggested via merge requests at 2878 https://github.com/autocrypt/protected-headers or by e-mail to the 2879 authors. Please direct all significant commentary to the public IETF 2880 LAMPS mailing list: spasm@ietf.org 2882 13.1. Document History 2884 Significant changes between version -01 and -02: 2886 * Added S/MIME test vectors in addition to PGP/MIME 2888 * Legacy Display parts should now be "text/plain" and not "text/ 2889 rfc822-headers" 2891 * Cryptographic Payload must have "protected-headers" parameter set 2892 to "v1" 2894 * Test vector sample Message-Ids have been normalized 2896 * Added encrypted-only (unsigned) test vectors, at the suggestion of 2897 Russ Housley 2899 Changes between version -00 and -01: 2901 * Credit Randall for "correct horse battery staple". 2903 * Adjust test vectors to ensure no line in the generated .txt format 2904 exceeds 72 chars. 2906 * Minor formatting cleanup to appease idnits. 2908 * Update references to more recent documents (RFC 2822 -> 5322, -00 2909 to -01 of draft-ietf-lamps-header-protection-requirements). 2911 14. Acknowledgements 2913 The set of constructs and algorithms in this document has a previous 2914 working title of "Memory Hole", but that title is no longer used as 2915 different implementations gained experience in working with it. 2917 These ideas were tested and fine-tuned in part by the loose 2918 collaboration of MUA developers known as [Autocrypt]. 2920 Additional feedback and useful guidance was contributed by attendees 2921 of the OpenPGP e-mail summit ([OpenPGP-Email-Summit-2019]). 2923 The following people have contributed implementation experience, 2924 documentation, critique, and other feedback: 2926 * Holger Krekel 2928 * Patrick Brunschwig 2930 * Vincent Breitmoser 2932 * Edwin Taylor 2934 * Alexey Melnikov 2936 * Russ Housley 2938 The password example used in Section 9 comes from [xkcd936]. 2940 15. References 2942 15.1. Normative References 2944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2945 Requirement Levels", BCP 14, RFC 2119, 2946 DOI 10.17487/RFC2119, March 1997, 2947 . 2949 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 2950 "MIME Security with OpenPGP", RFC 3156, 2951 DOI 10.17487/RFC3156, August 2001, 2952 . 2954 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2955 Thayer, "OpenPGP Message Format", RFC 4880, 2956 DOI 10.17487/RFC4880, November 2007, 2957 . 2959 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2960 DOI 10.17487/RFC5322, October 2008, 2961 . 2963 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2964 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2965 May 2017, . 2967 15.2. Informative References 2969 [Autocrypt] 2970 "Autocrypt Specification 1.1", 13 October 2019, 2971 . 2973 [I-D.draft-bre-openpgp-samples-00] 2974 Einarsson, B., juga, j., and D. Gillmor, "OpenPGP Example 2975 Keys and Certificates", Work in Progress, Internet-Draft, 2976 draft-bre-openpgp-samples-00, 15 October 2019, 2977 . 2980 [I-D.draft-dkg-lamps-samples-01] 2981 Gillmor, D., "S/MIME Example Keys and Certificates", Work 2982 in Progress, Internet-Draft, draft-dkg-lamps-samples-01, 2983 20 November 2019, . 2986 [I-D.draft-ietf-lamps-header-protection-requirements-01] 2987 Melnikov, A. and B. Hoeneisen, "Problem Statement and 2988 Requirements for Header Protection", Work in Progress, 2989 Internet-Draft, draft-ietf-lamps-header-protection- 2990 requirements-01, 29 October 2019, . 2994 [I-D.draft-luck-lamps-pep-header-protection-03] 2995 Luck, C., "pretty Easy privacy (pEp): Progressive Header 2996 Disclosure", Work in Progress, Internet-Draft, draft-luck- 2997 lamps-pep-header-protection-03, 5 July 2019, 2998 . 3001 [OpenPGP-Email-Summit-2019] 3002 "OpenPGP Email Summit 2019", 13 October 2019, 3003 . 3005 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 3006 RFC 2634, DOI 10.17487/RFC2634, June 1999, 3007 . 3009 [RFC3274] Gutmann, P., "Compressed Data Content Type for 3010 Cryptographic Message Syntax (CMS)", RFC 3274, 3011 DOI 10.17487/RFC3274, June 2002, 3012 . 3014 [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 3015 Extensions (S/MIME) Version 3.1 Message Specification", 3016 RFC 3851, DOI 10.17487/RFC3851, July 2004, 3017 . 3019 [RFC6736] Brockners, F., Bhandari, S., Singh, V., and V. Fajardo, 3020 "Diameter Network Address and Port Translation Control 3021 Application", RFC 6736, DOI 10.17487/RFC6736, October 3022 2012, . 3024 [RFC7508] Cailleux, L. and C. Bonatti, "Securing Header Fields with 3025 S/MIME", RFC 7508, DOI 10.17487/RFC7508, April 2015, 3026 . 3028 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 3029 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 3030 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 3031 April 2019, . 3033 [xkcd936] Munroe, R., "xkcd: Password Strength", 10 August 2011, 3034 . 3036 Authors' Addresses 3038 Bjarni Rúnar Einarsson 3039 Mailpile ehf 3040 Baronsstigur 3041 Iceland 3043 Email: bre@mailpile.is 3044 juga 3045 Independent 3047 Email: juga@riseup.net 3049 Daniel Kahn Gillmor 3050 American Civil Liberties Union 3051 125 Broad St. 3052 New York, NY, 10004 3053 United States of America 3055 Email: dkg@fifthhorseman.net