Encrypted or signed e-mail does not have cryptographic protection of headers – only the body of an e-mail message is encrypted or signed. This specification provides a solution to this problem by embedding relevant headers within the body of the e-mail in a well-structured way.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on February 4, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
- 1. Introduction
- 2. Terminology
- 3. Message Structure
- 3.1. Locating an embedded header
- 4. Distinguishing from DSN
- 5. Consequences for encrypted headers
- 6. Subject
- 7. To and Cc
- 8. From
- 9. Message-ID
- 10. In-Reply-To, References
- 11. Date
- 12. Security Considerations
- 13. Privacy Considerations
- 14. IANA Considerations
- 15. TODO
- 16. Informative References
- header line
- a single header field, like “Subject: encrypting mail headers”
- header block
- a collection of header lines associated with an e-mail message or MIME part
- protection layer
- a MIME part that wraps an entire MIME subtree with some form of cryptographic protection. application/signed and application/encrypted Content-Types are protection layers.
- protected subtree
- a MIME subtree immediately enclosed by a protection layer
- top protected part
- the root MIME part of a protected subtree
- external header block
- the collection of header lines located outside the body of an e-mail message
- external header line
- a header line within an external header block
- MIME part header block
- the collection of header lines assocatied with a MIME part, as distinguished from the content of the MIME part
- MIME part header line
- a header line within a MIME part header block
- displayable header part
- a Content-Type: text/rfc822-headers MIME subpart located as the first child of a multipart/mixed top protected part. This part has a MIME part header block, and its content is also a header block. A displayable header part’s MIME part header block should be Content-Disposition: inline, and its parent’s MIME part header block should be Content-Type: multipart/mixed and Memory-Hole: displayable
- displayable header line
- a header line in the content of a display header part
- mail user agent (MUA)
- an application designed to receive, render, compose, and send e-mail on behalf of a user
In order for cryptographic protection of the e-mail body to apply to associated e-mail headers, the relevant e-mail headers must be present within the body of the message. This section describes how a memoryhole-compatible MUA should inspect the content of a protected message to find the relevant headers.
Not all headers for a given message will necessarily be protected, so rendering MUAs should be prepared for circumstances where some headers have different levels of protection than others. Displaying this distinction to the user is out of scope for this specification (we hope to collect such UI/UX guidance in a companion document).
Below we describe the semantic concepts and how to find them from the structure of the message.
- When interpreting and rendering an e-mail message, cryptographically aware MUAs should associate each e-mail header line with a set of cryptographic protections: 0 or more “encrypted-by…” and 0 or more “signed-by…” protection associations per header line.
- protection association sets have a prioritization hierarchy, from highest to lowest:
- a set with both signed-by and encrypted-by associations
- a set with only signed-by associations
- a set with only encrypted-by associations
- an empty set
- within each prioritization category, a set with more associations than another is a higher priority than a set with fewer associations.
- Before cryptographic processing, all header lines have an empty set of protection associations.
- an e-mail or message part whose Content-Type is a “message protection type” (multipart/signed or multipart/encrypted) inherits all header lines (replacing its own lines) from the internal top-level protected MIME part, if the internal header line has a higher-priority set of protection associations than the current header line.
- Headers inherited across a verified multipart/signed protection that gains a “signed-by” protection association for each verified signature.
- Headers inherited across a successfully decrypted multipart/encrypted protection gain an “encrypted-by” protection association for each key known to effectively decrypt the content. If the multipart/encrypted protection also includes a cryptographic signature (as in the case of one-shot PGP/MIME), these headers also gain a “signed-by” protection association for each verified signature.
- header inheritance chains, so internal headers “bubble up” if they are a higher priority.
TODO: document Force-display (explicit embedded header mime part for compatibility with decryption-capable pre-memoryhole clients) and how it fits into the above breakdown.
Some message headers are more privacy/confidentiality sensitive than others. When a block of headers is embedded in the encrypted body, the corresponding lines in the external header should be stripped or stubbed out, for at least some of the headers.
If confidentiality is desired for a header line protected in the body of the message by an encryption protection layer, the external header line in question should be removed from the external header block, or possibly replaced with a dummy external header line. The choice of whether to remove or replace depends on the header line itself.
We document the tradeoffs about removing/replacing specific header lines below.
- registering any new headers?
- Should we mark this as updating any of the DSN RFCs?
- Acknowledge message/rfc822 wrapping and explain why this is different