Protected Headers for Cryptographic E-mail Mailpile ehf
Baronsstigur Iceland bre@mailpile.is
Independent
juga@riseup.net
American Civil Liberties Union
125 Broad St. New York, NY 10004 USA dkg@fifthhorseman.net
int openpgp Internet-Draft This document describes a common strategy to extend the end-to-end cryptographic protections provided by PGP/MIME, etc. to protect message headers in addition to message bodies. In addition to protecting the authenticity and integrity of headers via signatures, it also describes how to preserve the confidentiality of the Subject header.
E-mail end-to-end security with OpenPGP and S/MIME standards can provide integrity, authentication, non-repudiation and confidentiality to the body of a MIME e-mail message. However, PGP/MIME () alone does not protect message headers. And the structure to protect headers defined in S/MIME 3.1 () has not seen widespread adoption. This document defines a scheme, “Protected Headers for Cryptographic E-mail”, which has been adopted by multiple existing e-mail clients in order to extend the cryptographic protections provided by PGP/MIME to also protect the message headers. This document describes how these protections can be applied to cryptographically signed messages, and also discusses some of the challenges of encrypting many transit-oriented headers. It offers guidance for protecting the confidentiality of non-transit-oriented headers like Subject, and also offers a means to preserve backwards compatibility so that an encrypted Subject remains available to recipients using software that does not implement support for the Protected Headers scheme. The document also discusses some of the compatibility constraints and usability concerns which motivated the design of the scheme, as well as limitations and a comparison with other proposals. While the document (and the authors’) focus is primarily PGP/MIME, we believe the technique is broadly applicable and would also apply to other MIME-compatible cryptographic e-mail systems, including S/MIME (). Furthermore, this technique has already proven itself as a useful building block for other improvements to cryptographic e-mail, such as the Autocrypt Level 1.1 () “Gossip” mechanism.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
For the purposes of this document, we define the following concepts: MUA is short for Mail User Agent; an e-mail client. Protection of message data refers to cryptographic encryption and/or signatures, providing confidentiality, authenticity or both. Cryptographic Layer, Cryptographic Envelope and Cryptographic Payload are defined in Original Headers are the message headers as known to the sending MUA at the time of message composition. Protected Headers are any headers protected by the scheme described in this document. Exposed Headers are any headers outside the Cryptographic Payload (protected or not). Obscured Headers are any Protected Headers which have been modified or removed from the set of Exposed Headers. Legacy Display Part is a MIME construct which provides visibility for users of legacy clients of data from the Original Headers which may have been removed or obscured from the Exposed Headers. It is defined in . User-Facing Headers are explained and enumerated in . Structural Headers are documented in .
Of all the headers that an e-mail message may contain, only a handful are typically presented directly to the user. The user-facing headers are: Subject From To Cc Date Reply-To Followup-To The above is a complete list. No other headers are considered “user-facing”. Other headers may affect the visible rendering of the message (e.g., References and In-Reply-To may affect the placement of a message in a threaded discussion), but they are not directly displayed to the user and so are not considered “user-facing” for the purposes of this document.
A message header whose name begins with Content- is referred to in this document as a “structural” header. These headers indicate something about the specific MIME part they are attached to, and cannot be transferred or copied to other parts without endangering the readability of the message. This includes (but is not limited to): Content-Type Content-Transfer-Encoding Content-Disposition Note that no “user-facing” headers () are also “structural” headers. Of course, many headers are neither “user-facing” nor “structural”. FIXME: are there any non-Content-* headers we should consider as structural?
The Protected Headers scheme relies on three backward-compatible changes to a cryptographically-protected e-mail message: Headers known to the composing MUA at message composition time are (in addition to their typical placement as Exposed Headers on the outside of the message) also present in the MIME header of the root of the Cryptographic Payload. These Protected Headers share cryptographic properties with the rest of the Cryptographic Payload. When the Cryptographic Envelope includes encryption, any Exposed Header MAY be obscured by a transformation (including deletion). If the composing MUA intends to obscure any user-facing headers, it MAY add a decorative “Legacy Display” MIME part to the Cryptographic Payload which additionally duplicates the original values of the obscured user-facing headers. When a composing MUA encrypts a message, it SHOULD obscure the Subject: header, by using the literal string ... (three U+002E FULL STOP characters) as the value of the exposed Subject: header. When a receiving MUA encounters a message with a Cryptographic Envelope, it treats the headers of the Cryptographic Payload as belonging to the message itself, not just the subpart. In particular, when rendering a header for any such message, the renderer SHOULD prefer the header’s Protected value over its Exposed value. A receiving MUA that understands Protected Headers and discovers a Legacy Display part SHOULD hide the Legacy Display part when rendering the message. The following sections contain more detailed discussion.
Implementations use the structure of an e-mail message to protect the headers. This section establishes some conventions about how to think about message structure.
“Cryptographic Layer” refers to a MIME substructure that supplies some cryptographic protections to an internal MIME subtree. The internal subtree is known as the “protected part” though of course it may itself be a multipart object. For PGP/MIME there are two forms of Cryptographic Layers, signing and encryption. In the diagrams below, ↧ is used to indicate “decrypts to”.
The Cryptographic Envelope is the largest contiguous set of Cryptographic Layers of an e-mail message starting with the outermost MIME type (that is, with the Content-Type of the message itself). If the Content-Type of the message itself is not a Cryptographic Layer, then the message has no cryptographic envelope. “Contiguous” in the definition above indicates that if a Cryptographic Layer is the protected part of another Cryptographic Layer, the layers together comprise a single Cryptographic Envelope. Note that if a non-Cryptographic Layer intervenes, all Cryptographic Layers within the non-Cryptographic Layer are not part of the Cryptographic Envelope (see the example in ). Note also that the ordering of the Cryptographic Layers implies different cryptographic properties. A signed-then-encrypted message is different than an encrypted-then-signed message.
The Cryptographic Payload of a message is the first non-Cryptographic Layer – the “protected part” – within the Cryptographic Envelope. Since the Cryptographic Payload itself is a MIME part, it has its own set of headers. Protected headers are placed on (and read from) the Cryptographic Payload, and should be considered to have the same cryptographic properties as the message itself.
As described above, if the “protected part” identified in or is not itself a Cryptographic Layer, that part is the Cryptographic Payload. If the application wants to generate a message that is both encrypted and signed, it MAY use the simple MIME structure from by ensuring that the Encrypted Message within the application/octet-stream part contains an Signed Message.
It is possible to construct a Cryptographic Envelope consisting of multiple layers for PGP/MIME, typically of the following structure:
When handling such a message, the properties of the Cryptographic Envelope are derived from the series A, E. As noted in , PGP/MIME applications also have a simpler MIME construction available with the same cryptographic properties.
Consider a message with the following overcomplicated structure:
The 3 Cryptographic Layers in such a message are rooted in parts H, L, and N. But the Cryptographic Envelope of the message consists only of the properties derived from the series H, L. The Cryptographic Payload of the message is part M. It is NOT RECOMMENDED to generate messages with such complicated structures. Even if a receiving MUA can parse this structure properly, it is nearly impossible to render in a way that the user can reason about the cryptographic properties of part O compared to part Q.
The Cryptographic Envelope fully encloses the Cryptographic Payload, whether the message is signed or encrypted or both. The Exposed Headers are considered to be outside of both.
This section describes the composition of a cryptographically-protected message with Protected Headers. We document legacy composition of cryptographically-protected messages (without protected headers) in , and then describe a revised version of that algorithm in that produces conformant Protected Headers.
All non-structural headers known to the composing MUA are copied to the MIME header of the Cryptographic Payload. The composing MUA SHOULD protect all known non-structural headers in this way. If the composing MUA omits protection for some of the headers, the receiving MUA will have difficulty reasoning about the integrity of the headers (see ).
When a message is encrypted, the Subject should be obscured by replacing the Exposed Subject with three periods: ... This value (...) was chosen because it is believed to be language agnostic and avoids communicating any potentially misleading information to the recipient (see for a more detailed discussion).
Due to compatibility and usability concerns, a Mail User Agent SHOULD NOT obscure any of: From, To, Cc, Message-ID, References, Reply-To, In-Reply-To, (FIXME: MORE?) unless the user has indicated they have security constraints which justify the potential downsides (see for a more detailed discussion). Aside from that limitation, this specification does not at this time define or limit the methods a MUA may use to convert Exposed Headers into Obscured Headers.
This section roughly describes the steps that a legacy MUA might use to compose a cryptographically-protected message without Protected Headers. The message composition algorithm takes three parameters: origbody: the traditional unprotected message body as a well-formed MIME tree (possibly just a single MIME leaf part). As a well-formed MIME tree, origbody already has structural headers present (see ). origheaders: the intended non-structural headers for the message, represented here as a table mapping from header names to header values.. For example, origheaders['From'] refers to the value of the From header that the composing MUA would typically place on the message before sending it. crypto: The series of cryptographic protections to apply (for example, “sign with the secret key corresponding to OpenPGP certificate X, then encrypt to OpenPGP certificates X and Y”). This is a routine that accepts a MIME tree as input (the Cryptographic Payload), wraps the input in the appropriate Cryptographic Envelope, and returns the resultant MIME tree as output, The algorithm returns a MIME object that is ready to be injected into the mail system: Apply crypto to origbody, yielding MIME tree output For header name h in origheaders: Set header h of output to origheaders[h] Return output
A reasonable sequential algorithm for composing a message with protected headers takes two more parameters in addition to origbody, origheaders, and crypto: obscures: a table of headers to be obscured during encryption, mapping header names to their obscuring values. For example, this document recommends only obscuring the subject, so that would be represented by the single-entry table obscures = {'Subject': '...'}. If header Foo is to be deleted entirely, obscures['Foo'] should be set to the special value null. legacy: a boolean value, indicating whether any recipient of the message is believed to have a legacy client (that is, a MUA that is capable of decryption, but does not understand protected headers). The revised algorithm for applying cryptographic protection to a message is as follows: if crypto contains encryption, and legacy is true, and obscures contains any user-facing headers (see ), wrap orig in a structure that carries a Legacy Display part: Create a new MIME leaf part legacydisplay with header Content-Type: text/rfc822-headers; protected-headers="v1" For each obscured header name obh in obscures: If obh is user-facing: Add obh: origheaders[ob] to the body of legacydisplay. For example, if origheaders['Subject'] is lunch plans?, then add the line Subject: lunch plans? to the body of legacydisplay Construct a new MIME part wrapper with Content-Type: multipart/mixed Give wrapper exactly two subarts: legacydisplay and origbody, in that order. Let payload be MIME part wrapper Otherwise: Let payload be MIME part origbody For each header name h in origheaders: Set header h of MIME part payload to origheaders[h] FIXME: Enigmail adds protected-headers="v1" parameter to payload here. Is this necessary? Apply crypto to payload, producing MIME tree output If crypto contains encryption: For each obscured header name obh in obscures: If obscures[obh] is null: Drop obh from origheaders Else: Set origheaders[obh] to obscures[obh] For each header name h in origheaders: Set header h of output to origheaders[h] return output Note that both new parameters, obscured and legacy, are effectively ignored if crypto does not contain encryption. This is by design, because they are irrelevant for signed-only cryptographic protections.
MUAs typically display user-facing headers () directly to the user. An encrypted message may be read by a decryption-capable legacy MUA that is unaware of this standard. The user of such a legacy client risks losing access to any obscured headers. This section presents a workaround to mitigate this risk by restructuring the Cryptographic Payload before encrypting to include a “Legacy Display” part.
A generating MUA that wants to make an Obscured Subject (or any other user-facing header) visible to a recipient using a legacy MUA SHOULD modify the Cryptographic Payload by wrapping the intended body of the message in a multipart/mixed MIME part that prefixes the intended body with a Legacy Display part. The Legacy Display part MUST be of Content-Type text/rfc822-headers, and MUST contain a protected-headers parameter whose value is v1. It SHOULD be marked with Content-Disposition: inline to encourage recipients to render it. The contents of the Legacy Display part MUST be only the user-facing headers that the sending MUA intends to obscure after encryption. The original body (now a subpart) SHOULD also be marked with Content-Disposition: inline to discourage legacy clients from presenting it as an attachment.
Consider a message whose Cryptographic Payload, before encrypting, that would have a traditional multipart/alternative structure:
When adding a Legacy Display part, this structure becomes:
Note that with the inclusion of the Legacy Display part, the Cryptographic Payload is the multipart/mixed part (part V in the example above), so Protected Headers should be placed at that part.
A MUA SHOULD transform a Cryptographic Payload to include a Legacy Display part only when: The message is going to be encrypted, and At least one user-facing header (see ) is going to be obscured Additionally, if the sender knows that the recipient’s MUA is capable of interpreting Protected Headers, it SHOULD NOT attempt to include a Legacy Display part. (Signalling such a capability is out of scope for this document)
A MUA that understands Protected Headers may receive an encrypted message that contains a Legacy Display part. Such an MUA SHOULD avoid rendering the Legacy Display part to the user at all, since it is aware of and can render the actual Protected Headers. If a Legacy Display part is detected, the Protected Headers should still be pulled from the Cryptographic Payload (part V in the example above), but the body of message SHOULD be rendered as though it were only the original body (part X in the example above).
A receiving MUA acting on a message SHOULD detect the presence of a Legacy Display part and the corresponding “original body” with the following simple algorithm: Check that all of the following are true for the message: The Cryptographic Envelope must contain an encrypting Cryptographic Layer The Cryptographic Payload must have a Content-Type of multipart/mixed The Cryptographic Payload must have exactly two subparts The first subpart of the Cryptographic Payload must have a Content-Type of text/rfc822-headers The first subpart of the Cryptographic Payload’s Content-Type must contain a property of protected-headers, and its value must be v1. If all of the above are true, then the first subpart is the Legacy Display part, and the second subpart is the “original body”. Otherwise, the message does not have a Legacy Display part.
As the above makes clear, the Legacy Display part is strictly decorative, for the benefit of legacy decryption-capable MUAs that may handle the message. As such, the existence of the Legacy Display part and its multipart/mixed wrapper are part of a transition plan. As the number of decryption-capable clients that understand Protected Headers grows in comparison to the number of legacy decryption-capable clients, it is expected that some senders will decide to stop generating Legacy Display parts entirely. A MUA developer concerned about accessiblity of the Subject header for their users of encrypted mail when Legacy Display parts are omitted SHOULD implement the Protected Headers scheme described in this document.
This document does not currently provide comprehensive recommendations on how to interpret Protected Headers. This is deliberate; research and development is still ongoing. We also recognize that the tolerance of different user groups for false positives (benign conditions misidentified as security risks), vs. their need for strong protections varies a great deal and different MUAs will take different approaches as a result. Some common approaches are discussed below.
One strategy for interpreting Protected Headers on an incoming message is to simply ignore any Exposed Header for which a Protected counterpart is available. This is often implemented as a copy operation (copying header back out of the Cryptographic Payload into the main message header) within the code which takes care of parsing the message. A MUA implementing this strategy should pay special attention to any user facing headers (). If a message has Protected Headers, and a user-facing header is among the Exposed Headers but missing from the Protected Headers, then an MUA implementing this strategy SHOULD delete the identified Exposed Header before presenting the message to the user. This strategy does not risk raising a false alarm about harmless deviations, but conversely it does nothing to inform the user if they are under attack. This strategy does successfully mitigate and thwart some attacks, including signature replay attacks () and participant modification attacks ().
An alternate strategy for interpreting Protected Headers is to consider the cryptographic signature on a message to be invalid if the Exposed Headers deviate from their Protected counterparts. This state should be presented to the user using the same interface as other signature verification failures. A MUA implementing this strategy MAY want to make a special exception for the Subject: header, to avoid invalidating the signature on any signed and encrypted message with a confidential subject. Note that simple signature invalidation may be insufficient to defend against a participant modification attack ().
This part is purely decorative, for the benefit of any recipient using a legacy decryption-capable MUA. See for details and recommendations on how to handle the Legacy Display part.
When replying to a message, many MUAs copy headers from the original message into their reply. When replying to an encrypted message, users expect the replying MUA to generate an encrypted message if possible. If encryption is not possible, and the reply will be cleartext, users typically want the MUA to avoid leaking previously-encrypted content into the cleartext of the reply. For this reason, an MUA replying to an encrypted message with Obscured Headers SHOULD NOT leak the cleartext of any Obscured Headers into the cleartext of the reply, whether encrypted or not. In particular, the contents of any Obscured Protected Header from the original message SHOULD NOT be placed in the Exposed Headers of the reply message.
Among the MUA authors who already implemented most of this specification, several alternative or more encompasing specifications were discussed and sometimes tried out in practice. This section highlights a few “pitfalls” and guidelines based on these discussions and lessons learned.
There were many discussions around what text phrase to use to obscure the Subject:. Text phrases such as Encrypted Message were tried but resulted in both localization problems and user confusion. If the natural language phrase for the obscured Subject: is not localized (e.g. just English Encrypted Message), then it may be incomprehensible to a non-English-speaking recipient who uses a legacy MUA that renders the obscured Subject: directly. On the other hand, if it is localized based on the sender’s MUA language settings, there is no guarantee that the recipient prefers the same language as the sender (consider a German speaker sending English text to an Anglophone). There is no standard way for a sending MUA to infer the language preferred by the recipient (aside from statistical inference of language based on the composed message, which would in turn leak information about the supposedly-confidential message body). Furthermore, implementors found that the phrase Encrypted Message in the subject line was sometimes understood by users to be an indication from the MUA that the message was actually encrypted. In practice, when some MUA failed to encrypt a message in a thread that started off with an obscured Subject:, the value Re: Encrypted Message was retained even on those cleartext replies, resulting in user confusion. In contrast, using ... as the obscured Subject: was less likely to be seen as an indicator from the MUA of message encryption, and it also neatly sidesteps the localization problems.
When the user of a legacy MUA replies to or forwards a message where the Subject has been obscured, it is likely that the new subject will be Fwd: ... or Re: ... (or the localized equivalent). This breaks an important feature: people are used to continuity of subject within a thread. It is especially unfortunate when a new participant is added to a conversation who never saw the original subject. At this time, there is no known workaround for this problem. The only solution is to upgrade the MUA to support Protected Headers. The authors consider this to be only a minor concern in cases where encryption is being used because confidentiality is important. However, in more opportunistic cases, where encryption is being used routinely regardless of the sensitivity of message contents, this cost becomes higher.
Many mail user agents maintain an index of message metadata (including header data), which is used to rapidly construct mailbox overviews and search result listings. If the process which generates this index does not have access to the encrypted payload of a message, or does not implement Protected Headers, then the index will only contain the obscured versions Exposed Headers, in particular an obscured Subject of .... For sensitive message content, especially in a hosted MUA-as-a-service situation (“webmail”) where the metadata index is maintained and stored by a third party, this may be considered a feature as the subject is protected from the third-party. However, for more routine communications, this harms usability and goes against user expectations. Two simple workarounds exist for this use case: If the metadata index is considered secure enough to handle confidential data, the protected content may be stored directly in the index once it has been decrypted. If the metadata index is not trusted, the protected content could be re-encrypted and encrypted versions stored in the index instead, which are then decrypted by the client at display time. In both cases, the process which decrypts the message and processes the Protected Headers must be able to update the metadata index. FIXME: add notes about research topics and other non-simple workarounds, like oblivious server-side indexing, or searching on encrypted data.
Current MUA implementations rely on the outermost Message-ID for message processing and indexing purposes. This processing often happens before any decryption is even attempted. Attempting to send a message with an obscured Message-ID header would result in several MUAs not correctly processing the message, and would likely be seen as a degradation by users. Furthermore, a legacy MUA replying to a message with an obscured Message-ID: would be likely to produce threading information (References:, In-Reply-To:) that would be misunderstood by the original sender. Implementors generally disapprove of breaking threads.
The impact of obscuring From:, To:, and Cc: headers has similar issues as discussed with obscuring the Message-ID: header in . In addition, obscuring these headers is likely to cause difficulties for a legacy client attempting formulate a correct reply (or “reply all”) to a given message.
Some popular mailing-list implementations will modify the Exposed Headers of a message in specific, benign ways. In particular, it is common to add markers to the Subject line, and it is also common to modify either From or Reply-To in order to make sure replies go to the list instead of directly to the author of an individual post. Depending on how the MUA resolves discrepancies between the Protected Headers and the Exposed Headers of a received message, these mailing list “features” may either break or the MUA may incorrectly interpret them as a security breach. Implementors may for this reason choose to implement slightly different strategies for resolving discrepancies, if a message is known to come from such a mailing list. MUAs should at the very least avoid presenting false alarms in such cases.
Other header protection schemes have been proposed (in the IETF and elsewhere) that are distinct from this mechanism. This section documents the differences between those earlier mechanisms and this one, and hypothesizes why it has seen greater interoperable adoption. The distinctions include: backward compatibility with legacy clients compatibility across PGP/MIME and S/MIME protection for both confidentiality and signing
S/MIME 3.1 () introduces header protection via message/rfc822 header parts. The problem with this mechanism is that many legacy clients encountering such a message were likely to interpret it as either a forwarded message, or as an unreadable substructure. For signed messages, this is particularly problematic – a message that would otherwise have been easily readable by a client that knows nothing about signed messages suddenly shows up as a message-within-a-message, just by virtue of signing. This has an impact on all clients, whether they are cryptographically-capable or not. For encrypted messages, whose interpretation only matters on the smaller set of cryptographically-capable legacy clients, the resulting message rendering is awkward at best. Furthermore, Formulating a reply to such a message on a legacy client can also leave the user with badly-structured quoted and attributed content. Additionally, a message deliberately forwarded in its own right (without preamble or adjacent explanatory notes) could potentially be confused with a message using the declared structure. The mechanism described here allows cryptographically-incapable legacy MUAs to read and handle cleartext signed messages without any modifications, and permits cryptographically-capable legacy MUAs to handle encrypted messages without any modifications. In particular, the Legacy Display part described in {#legacy-display} makes it feasible for a conformant MUA to generate messages with obscured Subject lines that nonetheless give access to the obscured Subject header for recipients with legacy MUAs.
contains a proposal that attempts to mitigate one of the drawbacks of the scheme described in S/MIME 3.1 (). In particular, it allows non-legacy clients to distinguish between deliberately forwarded messages and those intended to use the defined structure for header protection. However, this fix has no impact on the confusion experienced by legacy clients.
is applicable only to signed+encrypted mail, and does not contemplate protection of signed-only mail. In addition, the pEp header protection involved for “pEp message format 2” has an additional multipart/mixed layer designed to facilitate transfer of OpenPGP Transferable Public Keys, which seems orthogonal to the effort to protect headers. Finally, that draft suggests that the exposed Subject header be one of “=?utf-8?Q?p=E2=89=A1p?=”, “pEp”, or “Encrypted message”. “pEp” is a mysterious choice for most users, and see for more commentary on why “Encrypted message” is likely to be problematic.
offers DKIM, which is often used to sign headers associated with a message. DKIM is orthogonal to the work described in this document, since it is typically done by the domain operator and not the end user generating the original message. That is, DKIM is not “end-to-end” and does not represent the intent of the entity generating the message. Furthermore, a DKIM signer does not have access to headers inside an encrypted Cryptographic Layer, and a DKIM verifier cannot effectively use DKIM to verify such confidential headers.
describes a mechanism that embeds message header fields in the S/MIME signature using ASN.1. The mechanism proposed in that draft is undefined for use with PGP/MIME. While all S/MIME clients must be able to handle CMS and ASN.1 as well as MIME, a standard that works at the MIME layer itself should be applicable to any MUA that can work with MIME, regardess of whether end-to-end security layers are provided by S/MIME or PGP/MIME. That mechanism also does not propose a means to provide confidentiality protection for headers within an encrypted-but-not-signed message. Finally, that mechanism offers no equivalent to the Legacy Display described in . Instead, sender and receiver are expected to negotiate in some unspecified way to ensure that it is safe to remove or modify Exposed Headers in an encrypted message.
defines “Triple Wrapping” as a means of providing cleartext signatures over signed and encrypted material. This can be used in combination with the mechanism described in to authenticate some headers for transport using S/MIME. But it does not offer confidentiality protection for the protected headers, and the signer of the outer layer of a triple-wrapped message may not be the originator of the message either. In practice on today’s Internet, DKIM ( provides a more widely-accepted cryptographic header-verification-for-transport mechanism than triple-wrapped messages.
The subsections below provide example messages that implement the Protected Header scheme. The secret keys and OpenPGP certificates from can be used to decrypt and verify them. They are provided in textual source form as messages.
This shows a clearsigned message. Its MIME message structure is:
Note that if this message had been generated without Protected Headers, then an attacker with access to it could modify the Subject without invalidating the signature. Such an attacker could cause Bob to think that Alice wanted to cancel the contract with BarCorp instead of FooCorp.
To: Bob Babbage Date: Sun, 20 Oct 2019 09:18:11 -0400 Subject: The FooCorp contract Message-ID: --904b809781 Content-Type: text/plain; charset="us-ascii" From: Alice Lovelace To: Bob Babbage Date: Sun, 20 Oct 2019 09:18:11 -0400 Subject: The FooCorp contract Message-ID: Bob, we need to cancel this contract. Please start the necessary processes to make that happen today. Thanks, Alice -- Alice Lovelace President OpenPGP Example Corp --904b809781 content-type: application/pgp-signature -----BEGIN PGP SIGNATURE----- wnUEARYKAB0FAl2sXpMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj jjvKAPwOVIBTcSVKcji7kBw0ljyBwpOgoQ7UGaY6cINfhGg5HAEA4jjbHaEuGZ29 WDTKxW/exLlcW1WqY0fva3t6jbniyQI= =IsHn -----END PGP SIGNATURE----- --904b809781-- ]]>
This shows a simple encrypted message with protected headers. The encryption also contains an signature in the OpenPGP Message structure. Its MIME message structure is:
The Subject: header is successfully obscured. Note that if this message had been generated without Protected Headers, then an attacker with access to it could have read the Subject. Such an attacker would know details about Alice and Bob’s business that they wanted to keep confidential. The protected headers also protect the authenticity of subject line as well. The session key for this message’s crypto layer is an AES-256 key with value 8df4b2d27d5637138ac6de46415661be0bd01ed12ecf8c1db22a33cf3ede82f2 (in hex). If Bob’s MUA is capable of interpreting these protected headers, it should render the Subject: of this message as BarCorp contract signed, let's go!.
To: Bob Babbage Date: Mon, 21 Oct 2019 07:18:11 -0700 Message-ID: Subject: ... --bcde3ce988 content-type: application/pgp-encrypted Version: 1 --bcde3ce988 content-type: application/octet-stream -----BEGIN PGP MESSAGE----- wV4DR2b2udXyHrYSAQdAk4rw/q9TK6dtIBm42jF6Z7z34KmNIDAKF4v4f09n5l0w OAgtdmIHyUu3ZOHSb8cFRbjAGQ3RcgIAe4DdsZIy/m9eLEDXEzf9yMSufBtap6xb wcDMA3wvqk35PDeyAQwAgFIzERxgt1aZlcA29Ds10pv0Y3oZ5yKvMNxd+WEEZNcT rJBOFNlhek5/9/nkATGiDBaKOsu5o9VyDfKMAV0TYwZxuMgUNtvVpf0XL21dghYt KVqEHeOTXzprUBdztG4Lp4e0vsG0jPZS+CvTLjbcvO+/lzb314mwN8s8vZiQ7Vlj DxubIqKypY3jL66U0Acwk85IsXdK4CB4nousr2JFK3Y3zv7cQBtPKHEG8HkmvT0R tl0QoAkdHfw0q4rpc6183FA9e8EUV88XRJrKIYn86IaTPuMkp8ULWSsboalkJH3J rSq8kzAFFd/A6G8wSj/hVpH6U+NBGW3Z/DQnRmwHqSJfu/Tnue6TFLdDN1EYzk/L Nlr4YsH6eIB8v3H4u6kY/SwhHCv/F0jItHYVSsIeJz81L0vh28H6hLIMvSDFofJP fBgIJfZIJ8nzgFpLphVpk0mcI7jHElxEPRg/M5Lmlav9srYHbKbJ0LT67Z9AFnZB LHRa/p1eZnjpTxrYU2qZ0sHaAS0MB1TwpiucDRH2VN1z8vSKb1qizJ6ZH3qT3zQ8 EAf6Lar5B6l3v/WwhjMPgu/pLlvZgDAo0cWkBYqzWpOcwviAeC7OwqnZY9/BFm/F RefFysUIu7fWpvBbKtdch9lhb3baetWKI9uAwsaublwgSGZ4dBR2hfVaX72/8oDW 3oJoUvlw59J1r5Ai1l1YtyU8ctNGT2CqbKp6OgVzqm8BOhyQS1ayjMNU0VJs0s3N BJ0B1rctk5QykDAu3rVf+sgyqzQ7ohFqlG0W/7haocAQqW++Wy9PW/n0oNAuwugv W4zisCSB916z7whso00e1Ee3Fl7xgubzrGCHU3JNO5X73+gQHZ+jzuyGdBM5NTxd UcT89ekkd9XqfR2kJrhgiUOe15znWks5JB6VGKWfz2kp2wu1AVxSkbii1Qk/tRhX PUpHGwkin41WCPlUFA6xMLk9RmLjer2Wkg9zYosnzEIHdPj+WisWY86NRSZ/tJiw qZvzNwIgkzvqs1T/8aU5Z5rUOqI1l0Kd+tVjlkPyLrZOrvEeYwOwbAzlCdLxsCdq pY4ckpU/kMbfXXk21YWYFKDCopT7iRkuzDYlyGN4w/LPKQCMZrQxSms9uPNU5XG7 Au4yYdZVMkCLuLQ0kktuLe/CCX4bX82eF/AJ5DEFxWB3CT8FbVhdKrQ2RrLKwE7b 0jBdmT3NoJMtCbq68TBJO3MmOu6AaW7cD4INREbiD+Vr8ukqsnWkFiJ3NigQiT/4 PppJ2bAABRy9Gloa434PN3zgoWzmv80EfyNbZNfY7nGAOhAzBs8FqhrOY2WIBTp+ YEkvEjS5YOwgEj1/zcHts1pOWczY/AfVi2sLkCT8FqsNlfPPebdR4Oq+CEav/M52 A+CS0s7j1gklNfNd =87qA -----END PGP MESSAGE----- --bcde3ce988-- ]]>
Unwrapping the Cryptographic Layer yields the following content:
To: Bob Babbage Date: Mon, 21 Oct 2019 07:18:11 -0700 Subject: BarCorp contract signed, let's go! Message-ID: Hi Bob! I just signed the contract with BarCorp and they've set us up with an account on their system for testing. The account information is: Site: https://barcorp.example/ Username: examplecorptest Password: correct-horse-battery-staple Please get the account set up and apply the test harness. Let me know when you've got some results. Thanks, Alice -- Alice Lovelace President OpenPGP Example Corp ]]>
If Alice’s MUA wasn’t sure whether Bob’s MUA would know to render the obscured Subject: header correctly, it might include a legacy display part in the cryptographic payload. This message is structured in the following way:
The example below shows the same message as . If Bob’s MUA is capable of handling protected headers, the two messages should render in the same way as the message in , because it will know to omit the Legacy Display part as documented in . But if Bob’s MUA is capable of decryption but is unaware of protected headers, it will likely render the Legacy Display part for him so that he can at least see the originally-intended Subject: line. For this message, the session key is an AES-256 key with value 95a71b0e344cce43a4dd52c5fd01deec5118290bfd0792a8a733c653a12d223e (in hex).
To: Bob Babbage Date: Mon, 21 Oct 2019 07:18:11 -0700 Message-ID: Subject: ... --73c8655345 content-type: application/pgp-encrypted Version: 1 --73c8655345 content-type: application/octet-stream -----BEGIN PGP MESSAGE----- wV4DR2b2udXyHrYSAQdAS0G0tRGi0cGe2INISDT7xS8b5e1iezXzXuFOrAa1fWgw JK32KLaTpnHegkEVB/cdMLMEEq56BkktxtC94YNSoeKJOTmNPhR+YWLruWRmZoAk wcDMA3wvqk35PDeyAQv6Ag30fne2jVFaH+oStUEoX/BEaclWJfpIgu9Ex5SYLmEg tNHJtLMbKWYKQHhpMiyONeVvfgkus8cPZMtpc+eZEP9FaEdQ69CqkB9Cmqt4Hs2q yNk14ec0KtL9/b5IPx4rVBrBuFSqxxiS0r0bMsTvKss1p4UGgPN9UPhJSj4dsmDP w+gLkxsUKL6i37QJIOmarMawS4iK7/MN+GbjzlMduw/VuLV80DYgIt4l96E9xJ+1 u7S6/TKXyUSuxG1Wo+3tCEpy+hTKeS8mYnjD8OYVF5To+TCMnznCiEEwebd44ild 54Bt4QS/G+x/s/aSFRM8pN2O8qz5D5sy+Mzp4dG6w/9fAhIt9mp8W/6Vn+Cgy8kD 0dHy3pN5dVavmsBqzy0uaf4xAoLLJZQBzyR+0UWygUyfc2N6VHkXo+S30LhSfkJO BMNKqkCaUoLFlHQLstZXETfXMJzpuUySH99ZTeyVnfB/eiEr9CByQqTeN9Uqtu0R QYWEpTvvYei/vJCNDBqT0sIxAftxmF/H2K4hCW2qD3eE/zSe2PpabgStHmfdZrcx X1sdOYZ7nOE0L3J/zE3jASEyQUZHr5rdt/RI5qwD2a7zirp8RNAyvk93InQuseX7 mgHADtk9LdNTWumiUd8pvm/ChXoRKvqjSV7mHpdBil0D4JKpZTGAQieP4fF71IYw 4E+VwiZZKIDSiYMUEljA3U7+M9siELlvKRACrrPZKr6OE58JywlIgRdewzroMWIO HoNJ4EOzij5rJfd6fAF4A3lH3wRu8dcuqrKwK2DhL+as1Zc/AABZD9Ov8t97/A/t b6jWJqVAVWilgarv9wwI4icN6q9hdwPZF5OaLgvpskGAtG3z51vkJuAiMogWP2Iv T0GuamZb5177yH5ShtowlTZN6D5WR7ShYbdHAPKRWFcYz4S9b7UZiWH1Ts2lHglJ 5mUbpTI1EvJFO1nwUcVLTuqB2N7lwVvD0oM9lSDcgUmrS04lqBDEax1V+PoKXYAi Q0z3eH6EDzw0xYWZhiBjgvor2qmGuIEqjBa+5qIOMrzBZK+7y0KOlkgaPik0BeYB jC/107Us+5i7c3EfQXj4K5XP72/SR0KC9cr//q9tRBOGki8yVicyOGbtSGsNgul/ 5T0VlrTecw+3ZOH4mQRGCJmxkes1amdDeklISfBeOe+LBx/tjkyixeXeh05i1doy n9VY/utOqu3Oo6XnTWktxajuhfvwSA2wNB/JnRFqu8QEVmqVzD/jwNvsvETQC83j GPKYo+P1PpAHeqRs4tMq18JQzzytXzr5llLp26qT4Sgul+8tqafkfS6zGL1xShMQ V1uMtoAt5KBfO4nfiGUAiZeR2RqRrT4YLHEZvpblIE8y7l3y8WV8gdiFfOXZ21mg gGntqnxU0hrC0IggGVBBY7zHVrcQxJOGsnAsqhQJpVBSnP0YgyrKCEVgDF4ibPBz y2bRxKP4es0advuEVKGAHULhzoV26Siz8h9MkeI6o+d28vestHng++2DsmCrdpSv EatA =MxXQ -----END PGP MESSAGE----- --73c8655345-- ]]>
Unwrapping the Cryptographic Layer yields the following content:
To: Bob Babbage Date: Mon, 21 Oct 2019 07:18:11 -0700 Subject: BarCorp contract signed, let's go! Message-ID: --6ae0cc9247 Content-Type: text/rfc822-headers; charset="us-ascii"; protected-headers="v1" Content-Disposition: inline Subject: BarCorp contract signed, let's go! --6ae0cc9247 Content-Type: text/plain; charset="us-ascii" Hi Bob! I just signed the contract with BarCorp and they've set us up with an account on their system for testing. The account information is: Site: https://barcorp.example/ Username: examplecorptest Password: correct-horse-battery-staple Please get the account set up and apply the test harness. Let me know when you've got some results. Thanks, Alice -- Alice Lovelace President OpenPGP Example Corp --6ae0cc9247-- ]]>
Some mailers may generate signed and encrypted messages with a multilayer cryptographic envelope. We show here how such a mailer might generate the same message as . A typical message like this has the following structure:
For this message, the session key is an AES-256 key with value 5e67165ed1516333daeba32044f88fd75d4a9485a563d14705e41d31fb61a9e9 (in hex).
To: Bob Babbage Date: Mon, 21 Oct 2019 07:18:11 -0700 Message-ID: Subject: ... --15d01ebd43 content-type: application/pgp-encrypted Version: 1 --15d01ebd43 content-type: application/octet-stream -----BEGIN PGP MESSAGE----- wV4DR2b2udXyHrYSAQdArQ8apKY0ciE47ZyBKgbOditGO6OBizW/VeQItRdCxA0w KaoRJewLgRnuvwaEisHWjiA0IHB9+0BSja+GFIh6gBWCFqzAfJQxoywAZMHznn6k wcDMA3wvqk35PDeyAQv/X3CYHUgNH81gAKZK/Cb7+WDbjmHcgskkvtceANQbEBEr /yVoou5BSlXsEni2wn1dtrIsrkhj6OF+B1mwGELw/3qcXdhT46iIrjn547b8Wycp saey8JqqX8FdfrxEYyOeBJn9CMDm0Dawfv+kNEdbfZtZ2IUONRgigKfcs+Pvrv3e hoY3KUe47cbiqKvw11VFTu2e4+rIPXW4sB3/95Epvo+RSo58p62kbvJDmBPt5E06 mEykcvyd6GP0eyTTbtaHNcNWd8jvGUobfikwibADcmjXmbPwTJefMCBbsYov86bK 72QOWbp39JcmwUWdo850+sU0XoCHmqditFfZqEdcKRFJOl+Rt+pMSrDixHb8Thdi WcxUXetpDvACrmjsipKHbxBZAgEU0K71zvbUPk930jOqJgsyXKX0WI8u32gNZDfc enHAAnALKvwoTGU3EM6do0XRMUKYL6+ON1F1L9S1Rm9Fa+WQKcO04ZvdeHbQXkt3 Fx6ZvZT/Bn3fcIWBpHfs0sI0AfeSpGjSejaZvZQ8qoOTQkOqrjuRnpU8232/ngsC 46mObydGJZ5qEMnmdDOfQB6L1LR9dQTCzA6swlG4U62MoO0n6yILCxLZTPVKYm7c 6r4KnQcvrGk1pgozdW1QjFBOjiDXbitHnqGorxKUcVVorXSEU919wKm11tGGyZ7/ 2sta4WQq9ILVvPqB2I1hLfbteBUYWgB/rJcc6JsZyRItEKjSSXZoanYyuCPf0m5r rpzf18kz8gYk92RTLzefALgMiIuU9CXFtd673/MalsZ2DRYjnI3tC9AXEdV9yVVa KYX/ECbFPHNxxulu/HU7hL7QQbgxA1E41RM2KjEzmwUEA8EomuNN7eQ5AJjDP0qk EIjIxIsW8at8FB4vB4sxh95OiF3hHFZj8q6/VZW8K8LspERCdrKmtu46xt2g7uKx 8ifdwqMT5OPu4VD5EPuOZLJRnSnYskTBwjZnX+ZqRdz/7z7XdUhvn4CjjiFt804a 4uunVgTeVXQay97a7oz+SCrNc+Gvv7K0dt7oUt512+0hQAJ3W9J3Chlht4UKs759 QymPx4smS8kY7c57OWpab481cqeQZLMIftBconhzSzAGl1LZhc5MVoc7l3dEABcx G+zcTIiRT+io8PwaBvnUg3nE0xP201s5vpK2vbBBMDh3O3titYMBDJp3riyp81AR Rm6tymUZaRMxq17T6BJ0b0fXyQ2fiz5vuudK5L/zDBvkOSIlhvaV2zxJqMhlSS54 W2RrwNjxkgBCiz1u1Yzi/HQ+jUwO/p8uGn0hyyIEEDIX50gPe2IQjgEjGteIBrDF sfi9jCEhK/Y0xANG4Mt01Ukt6cgGQhrKuBnyy9KRG+US7aaPdMQuPLfOlhPZOjIQ Bytek3JyT/QCsKPSjcGiNinllYk+Za8gL6SCNfZam1y/E802xX4z30t7Z6EBSRLi +qwzOCu7wTkJkoOPLfZFLY41OrVaR8lyBG1eZmtJXbER1GuuRv/7IC2xcDZv/2VO ahdnPLy7 =rOD1 -----END PGP MESSAGE----- --15d01ebd43-- ]]>
Unwrapping the encryption Cryptographic Layer yields the following content:
To: Bob Babbage Date: Mon, 21 Oct 2019 07:18:11 -0700 Subject: BarCorp contract signed, let's go! Message-ID: Hi Bob! I just signed the contract with BarCorp and they've set us up with an account on their system for testing. The account information is: Site: https://barcorp.example/ Username: examplecorptest Password: correct-horse-battery-staple Please get the account set up and apply the test harness. Let me know when you've got some results. Thanks, Alice -- Alice Lovelace President OpenPGP Example Corp --a6b911f1d1 content-type: application/pgp-signature -----BEGIN PGP SIGNATURE----- wnUEARYKAB0FAl2tviMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj jk5oAQCUL+lTDVp2pMOgcDuwnYtYCU9XMRxLgG4bZERZaYf1jQEAj85xO9Cjd7dZ jBU3m8KYcHe5P5QtOYMw8snpliWXXgA= =Vh3K -----END PGP SIGNATURE----- --a6b911f1d1-- ]]>
Note the placement of the Protected Headers on the Cryptographic Payload specifically, which is not the immediate child of the encryption Cryptographic Layer.
And, a mailer that generates a multilayer cryptographic envelope might want to provide a Legacy Display part, if it is unsure of the capabilities of the recipient’s MUA. We show here how sucha mailer might generate the same message as . Such a message might have the following structure:
For this message, the session key is an AES-256 key with value b346a2a50fa0cf62895b74e8c0d2ad9e3ee1f02b5d564c77d879caaee7a0aa70 (in hex).
To: Bob Babbage Date: Mon, 21 Oct 2019 07:18:11 -0700 Message-ID: Subject: ... --750bb87f7c content-type: application/pgp-encrypted Version: 1 --750bb87f7c content-type: application/octet-stream -----BEGIN PGP MESSAGE----- wV4DR2b2udXyHrYSAQdAQL6ivBlSduqtPTk/Y3+ijcQ+N5NYfDl+o474FT/BUBIw iZzmY+CQgrHf2iRPm2GuOoN+XuZtFYk4cIhwe0gAK7+p/44osZGipnzcw0NDbMC3 wcDMA3wvqk35PDeyAQwAtPLguH2X/uqQupJWoF5bnpcxogM2hr+7W5FSFNCiTh6L ZWYY9B1M+qQqOsTSqpA9mhOoqlnUGiRWYFU164mla3KmMu4rDKSrP761E9ozQl4k o7+xjvWEBsVeU6KZLPpi9r5KDxwiGO8PT7qsNHv+OTSvJbOv1azLcSo4g67J03uU rSbMDjPD1BAZDyf7TwKpg4MXVmJtnuHURjzIQ/VtS6eZ0FYzvPZX0rMo00G4bNkR t1w06hEUemFRtEI/JhD8H3hDkx4Xo/XBWuiVD/UWrlXh1rGjTCfezd4p7F74/+t+ VHxLWWkyeNXnQqFZX6nIclvoW/ZQr2RycA8j7L/BSYEeINxE4gau+Mh/9IN460G5 Aabjok1FIv8D3inMDI9MgxHYOkAReCMJ4btObtLlzQy+f6aE3BPihIvAYlRzCBel 9Cl604BDGmVug+UeYJ7+1S55HB5vbWzx88IwELw4FCFaYwiK2FOB53tXSc/sGkBQ Eh7hf2RLSq0c17fMBuNa0sKDAY5PKwukRG+RDz/TeM0e2Y42hPsVm6rOPKNIjygd oGHLfXw/vYtpxVcdipa9LRAnoJ4JNSaB3vOLz54yxeXuOJrg6nT9JvSRuQ1AlZHq 7Sf2i0kbYkNYZOig54PVJ1/ESkzyrNlmxlRrmo/I9tCr7Wa5bMlgh0S7wm5wPUm4 sEEf+WeqU9cAQKGz4gmY87/ErvPUnudcl21SKyFZ6SlgXdo1GEAUagf3YPL/eOaW KSG/c69L3K2nBr8NnsTH054AokKOEJKM0+Tu+z8dSRFfa8vJt+fbaV/wL3xK9yEQ KxJurGTCQ3uKyaeVEyyc5oscv005iaaS9cskkU2eArjAoXNcS7dFMuNXJBbn9WZc vDmlUSnpob6ZEVySNiQLKyVPsd50VQALv9ySsVT/LNx1N+QR4PSg7uX029itcXbp zuJgBg8hnpZxKD1vWPzWslmyaC6iS4Q0qiD4XL669NEmtrSpXjX1xFv5SGLWO7IE TQttUOUgH2tarrFESGOV+354h8kW/CewMO3yR/rTV19HsZfBbuzCLMiURPmK51gb diZCD9mxd+LPuMPKo0nnoKgloFMgiono9bimJonGNKdfwhoRFFP8tIHZhkue9zqb AnjZazfsI6YyfGsshfjQ2xHUuT8tTXtNCA/yhhld3yp1b2LfWdWdGxcGrVugFhy3 fUBgeiL2cIf09cn10Y19cIISwa++LpkVWLWuINORu+d2z5Yi9E2I3Tqoi7kt3PvA GVfKK+Vpytf5f19vm53gfYPGHeF+V9fLZq2JrD4ewSzHSzbSf0Lo2uIUCRv9gTXV scKiRvA7O0tjQHKFQKcrZLcUd1YE3uRcLqL4GMlHZMdRIQ2SfEvZe8Ad5ZxoacTW nthYxDipYMheaLmXmePyTGXV0yo/btUe9q0vErhxIrWxnonhQxronVR2go9695Ia w/b1FdihjhBvVmymHdYXxCsbIKIPsE7MeAt0YXEmOly2MsqlbYv+XVwFpw9gYa6E QwMRS3Kd1bJgpuqZ4nOnHgZ1Qewhi1WbF9M3Kz6EryAgQJ6Sgy7syHqdYh4MzVOE +VMThZ5Q92DIQcJsPpEKpDIfnbEYm7N6Icfmz6fj1L9s7X1oew== =KH2Q -----END PGP MESSAGE----- --750bb87f7c-- ]]>
Unwrapping the encryption Cryptographic Layer yields the following content:
To: Bob Babbage Date: Mon, 21 Oct 2019 07:18:11 -0700 Subject: BarCorp contract signed, let's go! Message-ID: --6ae0cc9247 Content-Type: text/rfc822-headers; charset="us-ascii"; protected-headers="v1" Content-Disposition: inline Subject: BarCorp contract signed, let's go! --6ae0cc9247 Content-Type: text/plain; charset="us-ascii" Hi Bob! I just signed the contract with BarCorp and they've set us up with an account on their system for testing. The account information is: Site: https://barcorp.example/ Username: examplecorptest Password: correct-horse-battery-staple Please get the account set up and apply the test harness. Let me know when you've got some results. Thanks, Alice -- Alice Lovelace President OpenPGP Example Corp --6ae0cc9247-- --4e3b9ccaba content-type: application/pgp-signature -----BEGIN PGP SIGNATURE----- wnUEARYKAB0FAl2tviMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj jgzVAQCXwrEyApDaRBeUX1kQOCbb3RVpXcSO+BdROF1T5K3FxAEAs4hYWZXJD1lp UBe7D64qKa+fyQE1akkIWgoqoaTSlgk= =zdtG -----END PGP SIGNATURE----- --4e3b9ccaba-- ]]>
For all of the potential complexity of the Cryptographic Envelope, the Cryptographic Payload itself can be complex. The Cryptographic Envelope in this example is the same as the previous example (). The Cryptographic Payload has protected headers and a legacy display part (also the same as ), but in addition Alice’s MUA composes a message with both plaintext and HTML variants, and Alice includes a single attachment as well. While this message is complex, a modern MUA could also plausibly generate such a structure based on reasonable commands from the user composing the message (e.g., Alice composes the message with a rich text editor, and attaches a file to the message). The key takeaway of this example is that the complexity of the Cryptographic Payload (which may contain a Legacy Display part) is independent of and distinct from the complexity of the Cryptographic Envelope. This message has the following structure:
For this message, the session key is an AES-256 key with value 1c489cfad9f3c0bf3214bf34e6da42b7f64005e59726baa1b17ffdefe6ecbb52 (in hex).
To: Bob Babbage Date: Mon, 21 Oct 2019 07:18:11 -0700 Message-ID: Subject: ... --241c1d8182 content-type: application/pgp-encrypted Version: 1 --241c1d8182 content-type: application/octet-stream -----BEGIN PGP MESSAGE----- wV4DR2b2udXyHrYSAQdA6Hrr6FR4JVEu7eJP/tRMX/kaargXF/e5wrUW2Et3Ty8w HbZhbIWW4vt9reojwemfCX99j9s6zmKCEaAYVwyDZTZd+28AJNIScDgUVD9346cA wcDMA3wvqk35PDeyAQwAlCnRuVFh7GjzxzLpu6he63MNsKNKFFDKz/mXp5i0O7Je EUzUd1Hbrmn4OP/fznXrgPoi62DGlJkH/Al31EF5SqkxR71A9v9S3DnJ3PEjNAM9 lrOgEmJnKLGMoFy3wkDDs6c/qQqjLZTtdTrfteQtH9rlLqrPLqV+wbfxGi6qBh07 mUBqbdidqOpBKRs3k5vTXDrsAhGuKK0vTZd5yYJ0emBLtEnKm6MpJdaGWgO7CVnq 8/i4UoMV1lKEQQMB2gnrZ2wGXBD24jkaPefpPhLYa6WSOwL9E49fuo4AJy1CDxm8 aN2PQa+8VsBovsavh2BF50Auy0dGmjdru1O0t8hD1KyFrogeGJ/JgEJFkX5kK0M6 jgW+UZDws0ex3b7ikxM2Gboq2WeOoWqrP7Q09vPUo7fabR74ngj1VpjAdnY5v+cO HVG+hdAB5dgxXXzI8xYIP7z3bm2refQ1dbomlc8cXb7UJwKhpVgTPdwjcheZDeE9 RVLwradRXPmTqGfWTWSS0sPcAXU5DkOUxi7PiRObKeCAmw2sUnwh9t6vTq+ZFIqQ JmvsI++VftKg5hiqnPV88pF5fvjDbbcTvHNEAMtMFXLFjGHtcz1dRNwAn8DOXj5F JpBwGGtY19JZrHPP98gFioqwTQja+7M6b7KTuWKx9+bZ0JjsALxSFW+1taZN0+SB Ox60tfD0kTp3Wq+W13IYBqSniFkFkWRoua5ta9LUrVPHAnG1d8utycGsroXK/9sl /dshobLC3qmrInLh6VeryVZBFBOcOW7w5FzxZbAt6xuEvU/ooRepBwIbYkfc66OD 3yEXh6OJmMX6Cqs/HpN66lDRlm4IHD6y88j+Ot9Pwxid1GcEH6Y89rnNqCcoTRDf 94tIXtLb7a1JZlOBOLcM5B/0Qlk3YtuSw945jynqYWJ9sOG+jX0sZ0ZwwRY/gIAz vPzGzO5UDUiusL5Go1xiJjXvbXW+LKSzgzjOLkUlz1SP5OEkntigMQvsFsKRtE6K sPeHf8b5INp8tOaHiYX9tnbS8Ozok+BBQTvT0f1tYSlQkGLfvLDFyat1f7ChdTpo tZBKX+VBycblXzbIo8+BlVRIT0CiNIZwujN50IBfXGbBrxJqbNcA0GQwtLIgZSHG +1k6nGLPaHJjgN44AfH9JREZD3pMTih9zjfDnOA/dij8XOSIwuQkS0wVrkcvnT9v ByMn5QYUMUxajAMthP7YLd3uBjvhpqtYPhi8pXB6PuTsLk2nHMIWoKh/WqckZcjx pccjLia74y+O06XHI2SPG/BtjF7S9s71VcXdmQwzpJ7BP6hCHJ/AIb9W1+UdCCSX 7DHgn7wHqmbQ+LVQDMw2qvBLAXL2D2hn5uXcVMzvL9XuS00UnaKUoYILmhmkBdgl EVqW/ZeKYv5erZUkTB1f179aXrtoQ4cMRoZfE4S7+j2yCiee8tJRvOQBQjg8KsdZ b0gR1v8rkEHC9KhURsDmCGaZuFYyl5e4pne2jHDwkyEmTAygdcJpMqbdLb+KGw0V pacv7pOQj0U0oaEn6JQuiZD1fTjsyNqSVS3whHe/wf5LKeIFNrTqVXi0GwKiZBrp pvsr4I4H/luVqSg7QKJGpt/tmXY+RPAMts+8FnHBN0SrON2yuVZh3oXv/j8L1qBV BeUGnA2FYMfCpJti5UBQThZjFieNRT3xVzezGSnhQHeLAB08weAqEOfXP9HBcRng yNTRKTCfA7NCYHpqjT7+A9d83PEmbX9dAeJxVbIgwkqVVmeW0LmLJi3Lh9qilOJ+ 66xTQQtreq2GUHY5jHapu1mTB2FRmbLftQ+yPsooNVvtzAroEwo2+NKNsHZdyqma 28ECmCbHbCkoVkDyyZDwx9HF8V+0vVxWlW2feYI5IfEbsRlo00s5gMT6e+NZ7lLt OmwxtPM9UZk6HxoCb+ZaqQDiZljp6NypFhz4rxbgZHU4oUgQ0QndLk9NlipCKj2Q FX7WBggqXtjMPUHCR6xH2+VPNOQN5O3exT1TCnrT9k2t+8IXB/hgVP/OQSHiI+og AZQrFl2jObo6CvsOOojsy4rxfawiTo5HafaFBz8GpqQuUt4IGHZIofGIMLU1OQ== =XtUM -----END PGP MESSAGE----- --241c1d8182-- ]]>
Unwrapping the encryption Cryptographic Layer yields the following content:
To: Bob Babbage Date: Mon, 21 Oct 2019 07:18:11 -0700 Subject: BarCorp contract signed, let's go! Message-ID: --6ae0cc9247 Content-Type: text/rfc822-headers; charset="us-ascii"; protected-headers="v1" Content-Disposition: inline Subject: BarCorp contract signed, let's go! --6ae0cc9247 Content-Type: multipart/mixed; boundary="8dfc0e9ecf" --8dfc0e9ecf Content-Type: multipart/alternative; boundary="32c4d5a901" --32c4d5a901 Content-Type: text/plain; charset="us-ascii" Hi Bob! I just signed the contract with BarCorp and they've set us up with an account on their system for testing. The account information is: Site: https://barcorp.example/ Username: examplecorptest Password: correct-horse-battery-staple Please get the account set up and apply the test harness. Let me know when you've got some results. Thanks, Alice -- Alice Lovelace President OpenPGP Example Corp --32c4d5a901 Content-Type: text/html; charset="us-ascii"

Hi Bob!

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

The account information is:

Site
https://barcorp.example/
Username
examplecorptest
Password
correct-horse-battery-staple

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

Let me know when you've got some results.

Thanks, Alice
--
Alice Lovelace
President
OpenPGP Example Corp

--32c4d5a901-- --8dfc0e9ecf Content-Type: text/x-diff; charset="us-ascii" Content-Disposition: inline; filename="testharness-config.diff" diff -ruN a/testharness.cfg b/testharness.cfg --- a/testharness.cfg +++ b/testharness.cfg @@ -13,3 +13,8 @@ endpoint = https://openpgp.example/test/ username = testuser password = MJVMZlHR75mILg + +[barcorp] +endpoint = https://barcorp.example/ +username = examplecorptest +password = correct-horse-battery-staple --8dfc0e9ecf-- --6ae0cc9247-- --c72d4fa142 content-type: application/pgp-signature -----BEGIN PGP SIGNATURE----- wnUEARYKAB0FAl2tviMWIQTrhbtfozp14V6UTmPyMVUMT0fjjgAKCRDyMVUMT0fj juFdAQDjMySpe88yowVduslDi/IGFTGNn1d0ZxpA3IGW5Ss8ZQD9H2zbBtiKXtc7 axmvtiKF4z1DdY/IgOKFfmyGX2WZrws= =Sv5w -----END PGP SIGNATURE----- --c72d4fa142-- ]]>
FIXME: register content-type parameter for legacy-display part MAYBE: provide a list of user-facing headers, or a new “user-facing” column in some table of known RFC5322 headers? MAYBE: provide a comparable indicator for which headers are “structural” ?
This document describes a technique that can be used to defend against two security vulnerabilities in traditional end-to-end encrypted e-mail.
While e-mail structure considers the Subject header to be part of the message metadata, nearly all users consider the Subject header to be part of the message content. As such, a user sending end-to-end encrypted e-mail may inadvertently leak sensitive material in the Subject line. If the user’s MUA uses Protected Headers and obscures the Subject header as described in then they can avoid this breach of confidentiality.
A message without Protected Headers may be subject to a signature replay attack, which attempts to violate the recipient’s expectations about message authenticity and integrity. Such an attack works by taking a message delivered in one context (e.g., to someone else, at a different time, with a different subject, in reply to a different message), and replaying it with different message headers. A MUA that generates all its signed messages with Protected Headers gives recipients the opportunity to avoid falling victim to this attack. Guidance for how a message recipient can use Protected Headers to defend against a signature replay attack are out of scope for this document.
A trivial (if detectable) attack by an active network adversary is to insert an additional e-mail address in a To or Cc or Reply-To or From header. This is a staging attack against message confidentiality – it relies on followup action by the recipient. For an encrypted message that is part of an ongoing discussion where users are accustomed to doing “reply all”, such an insertion would cause the replying MUA to encrypt the replying message to the additional party, giving them access to the conversation. If the replying MUA quotes and attributes cleartext from the original message within the reply, then the attacker learns the contents of the encrypted message. As certificate discovery becomes more automated and less noticeable to the end user, this is an increasing risk. An MUA that rejects Exposed Headers in favor of Protected Headers should be able to avoid this attack when replying to a signed message.
This document only explicitly contemplates confidentiality protection for the Subject header, but not for other headers which may leak associational metadata. For example, From and To and Cc and Reply-To and Date and Message-Id and References and In-Reply-To are not explicitly necessary for messages in transit, since the SMTP envelope carries all necessary routing information, but an encrypted message as described in this document will contain all this associational metadata in the clear. Although this document does not provide guidance for protecting the privacy of this metadata directly, it offers a platform upon which thoughtful implementations may experiment with obscuring additional e-mail headers.
[ RFC Editor: please remove this section before publication ] This document is currently edited as markdown. Minor editorial changes can be suggested via merge requests at https://github.com/autocrypt/protected-headers or by e-mail to the authors. Please direct all significant commentary to the public IETF LAMPS mailing list: spasm@ietf.org
The set of constructs and algorithms in this document has a previous working title of “Memory Hole”, but that title is no longer used as different implementations gained experience in working with it. These ideas were tested and fine-tuned in part by the loose collaboration of MUA developers known as . Additional feedback and useful guidance was contributed by attendees of the OpenPGP e-mail summit (). The following people have contributed implementation experience, documentation, critique, and other feedback: Holger Krekel Patrick Brunschwig Vincent Breitmoser
Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet Message Format This document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS-TRACK] MIME Security with OpenPGP This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK] OpenPGP Message Format This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. OpenPGP Email Summit 2019 Autocrypt Specification 1.1 OpenPGP Example Keys and Certificates The OpenPGP development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of OpenPGP certificates and keys for use when generating such samples. pretty Easy privacy (pEp): Progressive Header Disclosure Issues with email header protection in S/MIME have been recently raised in the IETF LAMPS Working Group. The need for amendments to the existing specification regarding header protection was expressed. The pretty Easy privacy (pEp) implementations currently use a mechanism quite similar to the currently standardized message wrapping for S/MIME. The main difference is that pEp is using PGP/ MIME instead, and adds space for carrying public keys next to the protected message. In LAMPS, it has been expressed that whatever mechanism will be chosen, it should not be limited to S/MIME, but also applicable to PGP/MIME. This document aims to contribute to this discussion and share the pEp implementation experience with email header protection. Problem Statement and Requirements for Header Protection Privacy and security issues with email header protection in S/MIME have been identified for some time. However, the desire to fix these issue has been expressed in the IETF LAMPS Working Group only recently. The existing S/MIME specification is likely to be updated regarding header protection. Several LAMPS WG participants expressed the opinion that whatever mechanism will be chosen, it should not be limited to S/MIME, but also applicable to PGP/MIME. This document describes the problem statement, generic use cases, and requirements. Additionally it drafts possible solutions to address the challenge. Finally some best practices are collected. Enhanced Security Services for S/MIME This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK] Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633. [STANDARDS-TRACK] Diameter Network Address and Port Translation Control Application This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per-endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4 address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a Network Address Translator and Network Address and Port Translator control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. [STANDARDS-TRACK] Securing Header Fields with S/MIME This document describes how the S/MIME protocol can be extended in order to secure message header fields defined in RFC 5322. This technology provides security services such as data integrity, non-repudiation, and confidentiality. This extension is referred to as 'Secure Headers'. Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751.