forked from pEp.foundation/internet-drafts
commit
86952a09ed
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,479 +0,0 @@
|
||||
### This file is only of temporary nature.
|
||||
### It will be enhanced and renamed later
|
||||
### to comply with markdown / XML2RFC format
|
||||
#############################################
|
||||
|
||||
# Definitions / Glossary
|
||||
|
||||
{::include ../shared/text-blocks/key-words-rfc2119.mkd}
|
||||
|
||||
{::include ../shared/text-blocks/terms-intro.mkd}
|
||||
|
||||
<!-- {::include ../shared/text-blocks/handshake.mkd} -->
|
||||
<!-- {::include ../shared/text-blocks/trustwords.mkd} -->
|
||||
<!-- {::include ../shared/text-blocks/tofu.mkd} -->
|
||||
{::include ../shared/text-blocks/mitm.mkd}
|
||||
|
||||
|
||||
* S/MIME: Secure/Multipurpose Internet Mail Extensions (cf. {{RFC8551}})
|
||||
|
||||
* PGP/MIME: MIME Security with OpenPGP (cf. {{RFC3156}})
|
||||
|
||||
* Message: An Email Message that consists of header fields
|
||||
(collectively called "the Header Section of the message") followed,
|
||||
optionally, by a Body; cf. {{RFC5322}}.
|
||||
|
||||
* Transport: The entity taking care of the transport of a Message
|
||||
towards the receiver or from the sender. The Transport is
|
||||
typically implemented in MTA (Mail Transfer Agent).
|
||||
|
||||
* Header Field (HF): cf. {{RFC5322}} Header Fields are lines beginning
|
||||
with a field name, followed by a colon (":"), followed by a field
|
||||
body (value), and terminated by CRLF; cf. {{RFC5322}}.
|
||||
|
||||
Note: To avoid ambiguity, this document does not use the terms
|
||||
"Header" or "Headers" in isolation, but instead always uses "Header
|
||||
Field" to refer to the individual field and "Header Section" to
|
||||
refer to the entire collection; cf. {{RFC5322}}.
|
||||
|
||||
* Header Section (HS): The Header Section is a sequence of lines of
|
||||
characters with special syntax as defined in {{RFC5322}}. It is the
|
||||
(top) section of a message containing the Header Fields.
|
||||
|
||||
* Body: The Body is simply a sequence of characters that follows the
|
||||
Header Section and is separated from the Header Section by an empty
|
||||
line (i.e., a line with nothing preceding the CRLF); cf {{RFC5322}}.
|
||||
It is the (bottom) section of Message containing the payload of a
|
||||
Message. Typically, the Body consists of a (multipart) MIME
|
||||
{{RFC2045}} construct.
|
||||
|
||||
* MIME Header Section (part): The collection of MIME Header Fields
|
||||
describing the following MIME structure as defined in {{RFC2045}}.
|
||||
|
||||
* Header Protection (HP): cryptographic protection of email Header
|
||||
Sections (or parts of it) for signatures and/or encryption
|
||||
|
||||
* Protection Levels (PL): One of 'signature and encryption',
|
||||
'signature only' or 'encryption only' (see also below)
|
||||
|
||||
* Signature and encryption (protection level): If cryptographic
|
||||
signing and encryption are applied to a message.
|
||||
|
||||
* Signature only (protection level): If cryptographic signing, but no
|
||||
encryption, is applied to a message.
|
||||
|
||||
* Encryption only (protection level): If encryption (but no
|
||||
cryptographic signing) is applied to a message.
|
||||
|
||||
* Original Message: The message to be protected before any protection
|
||||
related processing has been applied on the sender side.
|
||||
|
||||
* Inner Message: The message to be protected, shortly before
|
||||
protection measures are applied to on the sender side or the message
|
||||
shortly after unwrapping on the receiver side. Typically the Inner
|
||||
Message is in clear text and often the Inner Message is the same or
|
||||
similar as the Original Message. The Inner Message MUST be the same
|
||||
on the sender and the receiver side.
|
||||
|
||||
* Outer Message: The Message as handed over to the Transport or
|
||||
received from the Transport respectively. The Outer Message
|
||||
typically differs on the sender and the receiver side.
|
||||
|
||||
* User Facing Message: The message used for rendering after the Outer
|
||||
Message Header Section has been merged with the Inner Message Header
|
||||
Section.
|
||||
|
||||
* Essential Header Fields: The Header Fields an Outer Message Header
|
||||
Section SHOULD contain at least; cf. {{HF-include-outer}}.
|
||||
|
||||
* Protected: Protected refers to the parts of a message where
|
||||
protection measures of any Protection Levels have been applied to.
|
||||
|
||||
* Protected Message: A message that protection measures of any
|
||||
Protection Levels have been applied to.
|
||||
|
||||
* Unprotected: Unprotected refers to the parts of a message where
|
||||
no protection measures of any Protection Levels have been applied to.
|
||||
|
||||
* Unprotected Message: A message that no protection measures of any
|
||||
Protection Levels have been applied to.
|
||||
|
||||
* Data Minimization: Data spareness and hiding all technically
|
||||
concealable information whenever possible.
|
||||
|
||||
|
||||
# Specification
|
||||
|
||||
This section contains the specification for Header Protection in
|
||||
S/MIME to update and clarify Section 3.1 of {{RFC8551}} (S/MIME
|
||||
4.0). This specification is likely to be integrated into S/MIME at
|
||||
some later stage.
|
||||
|
||||
Furthermore, it is likely that PGP/MIME {{RFC3156}} will also take
|
||||
over this specification or parts of it.
|
||||
|
||||
The following covers the Interaction if all parties (sending and
|
||||
receiving side) implement this specification. For backward
|
||||
compatibility cf. {{backward-compatibility}}.
|
||||
|
||||
This specification applies to the protection levels "signature &
|
||||
encryption" and "signature only". It generally NOT RECOMMENDED to send
|
||||
message with protection level "encryption only". On the other hand,
|
||||
messages with protection level "encryption only" may arrive at the
|
||||
receiving side. While not targeted to protection level "encryption
|
||||
only", this specification is assumed to also function for "encryption
|
||||
only".
|
||||
|
||||
Note: It is for further study whether or not more guidance for
|
||||
handling messages with protection level "encryption only" at the
|
||||
receiving side is needed.
|
||||
|
||||
|
||||
## MIME Format
|
||||
|
||||
As per S/MIME version 3.1 and later (cf. {{RFC8551}}), the sending
|
||||
client wraps a full MIME message in a message/rfc822 wrapper in order
|
||||
to apply S/MIME security services to these header fields.
|
||||
|
||||
To help the receiving side to distinguish between forwarded and
|
||||
wrapped message, a "forwarded" Content-Type header field parameter is
|
||||
added as defined in {{I-D.melnikov-iana-reg-forwarded}}.
|
||||
|
||||
In the simplest case, a message looks as follows:
|
||||
|
||||
~~~
|
||||
|
||||
<Outer Message Header Section (unprotected)>
|
||||
|
||||
<Outer Message Body (protected)>
|
||||
|
||||
<MIME Header Section>
|
||||
|
||||
<Inner Message Header Section>
|
||||
|
||||
<Inner Message Body>
|
||||
|
||||
~~~
|
||||
|
||||
The following example demonstrates how header section and payload of a
|
||||
protect body part might look like. For example, this will be the
|
||||
first body part of a multipart/signed message or the signed and/or
|
||||
encrypted payload of the application/pkcs7-mime body part. Lines
|
||||
prepended by "O: " are the Outer Message Header Section. Lines
|
||||
prepended by "I: " are the Inner Message Header Section. Lines
|
||||
prepended by "W: " are the wrapper (MIME Header Section):
|
||||
|
||||
|
||||
~~~
|
||||
|
||||
O: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
||||
O: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
|
||||
O: Subject: Meeting at my place
|
||||
O: From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
||||
O: To: somebody@example.net
|
||||
O: MIME-Version: 1.0
|
||||
O: Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
|
||||
O: protocol="application/pkcs7-signature";
|
||||
O: boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
|
||||
This is a multipart message in MIME format.
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
W: Content-Type: message/rfc822; forwarded=no
|
||||
W:
|
||||
I: Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
||||
I: From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
||||
I: Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
|
||||
I: MIME-Version: 1.0
|
||||
I: MMHS-Primary-Precedence: 3
|
||||
I: Subject: Meeting at my place
|
||||
I: To: somebody@example.net
|
||||
I: X-Mailer: Isode Harrier Web Server
|
||||
I: Content-Type: text/plain; charset=us-ascii
|
||||
|
||||
This is an important message that I don't want to be modified.
|
||||
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
Content-Transfer-Encoding: base64
|
||||
Content-Type: application/pkcs7-signature
|
||||
|
||||
[[base-64 encoded signature]]
|
||||
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237--
|
||||
|
||||
~~~
|
||||
|
||||
|
||||
The Outer Message Header Section is unprotected, while the remainder
|
||||
(Outer Message Body) is protected. The Inner Message Body consists of
|
||||
the MIME header Section and the Inner Message (Header Section and
|
||||
Body). The Inner Message Header Section is the same as (or a subset
|
||||
of) the Original Message Header Section
|
||||
(cf. {{HF-include-inner}}). The Inner Message Body is the same as the
|
||||
Original Message Body (before header protection has been applied).
|
||||
|
||||
The original message itself may contain any defined MIME structure.
|
||||
|
||||
There may also be an additional MIME layer with Media-Type
|
||||
"multipart/mixed" in the Outer Message Body to contain the Inner
|
||||
Message (as "message/rfc822") along with other MIME part(s).
|
||||
|
||||
|
||||
### Alternative Option Autocrypt "Protected Headers" (Ex-"Memory Hole")
|
||||
|
||||
An alternative Option (based on the former autocrypt "Memory Hole" approach)
|
||||
to be considered, is described in
|
||||
{{I-D.autocrypt-lamps-protected-headers}}.
|
||||
|
||||
That option emphasizes backward compatibility challenges to existing Mail
|
||||
User Agents (MUAs) that do encryption, but are unaware of Header
|
||||
Protection (see also {{backward-compatibility}}).
|
||||
|
||||
That option suggests to use the Media-Type "text/plain" to contain the
|
||||
Inner Message (as opposed to "message/rfc822",
|
||||
cf. {{mime-Format}}). That approach may become problematic once the
|
||||
Content of "text/plain" needs to be parsed.
|
||||
|
||||
Regarding MIME type "message/rfc822" {{rfc2046}} specifies:
|
||||
|
||||
> Plain text does not provide for or allow formatting commands, font
|
||||
> attribute specifications, processing instructions, interpretation
|
||||
> directives, or content markup. Plain text is seen simply as a
|
||||
> linear sequence of characters, possibly interrupted by line breaks
|
||||
> or page breaks"
|
||||
|
||||
Existing MIME parsers and libraries implemented according to
|
||||
{{rfc2046}} are likely to be changed to implement the option described
|
||||
in {{I-D.autocrypt-lamps-protected-headers}}, as that option differs
|
||||
from the current MIME Standard (cf. {{rfc2046}}).
|
||||
|
||||
The impact of using "text/plain", while containing in fact a
|
||||
"message/rfc822", to the MIME standards and real world deployments is
|
||||
for further study.
|
||||
|
||||
For further information, the reader is encouraged to consult
|
||||
{{I-D.autocrypt-lamps-protected-headers}}.
|
||||
|
||||
|
||||
## Header Fields to Include to the Inner Message Header Section {#HF-include-inner}
|
||||
|
||||
It is RECOMMEND that the Inner Messages contains all the original
|
||||
Header Fields with the exception of those specified in
|
||||
{{HF-exclude-inner}}.
|
||||
|
||||
|
||||
## Header Fields to Exclude from the Inner Message Header Section {#HF-exclude-inner}
|
||||
|
||||
The following Header Fields MUST NOT be included to the Inner Message
|
||||
nor to any other protected part of the message:
|
||||
|
||||
* Bcc
|
||||
|
||||
|
||||
## Header Fields to Include to the Outer Message Header Section {#HF-include-outer}
|
||||
|
||||
The Outer Message Header Section is a subset of the Inner Message
|
||||
Header Section plus the Header Fields specified in
|
||||
{{HF-exclude-inner}} plus the MIME Header Section part to describe the
|
||||
encryption or signature.
|
||||
|
||||
To maximize Privacy, it is strongly RECOMMENDED to follow the
|
||||
principle of Data Minimization, which includes data spareness and
|
||||
hiding all technically concealable information whenever possible.
|
||||
|
||||
However, the Outer Message Header Section SHOULD contain at least the
|
||||
Essential Header Fields and MUST also contain the Header Fields of the
|
||||
MIME Header Section part.
|
||||
|
||||
The Essential Header Fields are defined as the following Header
|
||||
Fields:
|
||||
|
||||
* From
|
||||
* To
|
||||
* Date
|
||||
* Message-ID
|
||||
* Subject
|
||||
|
||||
Not including those may trigger Spam Detection to flag the message as
|
||||
Spam and/or lead to User Experience (UX) issues.
|
||||
|
||||
For further Data Minimization the values of these Header Fields MAY be
|
||||
obfuscated, which is discussed further in {{obfuscation-outer-HF}}.
|
||||
|
||||
The MIME Header Section part is the collection of MIME Header Fields
|
||||
describing the following MIME structure as defined in {{RFC2045}}.
|
||||
A MIME Header Section part typically includes the following Header
|
||||
Fields:
|
||||
|
||||
* MIME-Version
|
||||
* Content-Type
|
||||
* Content-Transfer-Encoding
|
||||
* Content-Disposition
|
||||
|
||||
The following example shows the MIME header of an S/MIME signed
|
||||
message (using application/pkcs7-mime with SignedData):
|
||||
|
||||
~~~
|
||||
MIME-Version: 1.0
|
||||
Content-Type: application/pkcs7-mime; smime-type=signed-data;
|
||||
name=smime.p7m
|
||||
Content-Transfer-Encoding: base64
|
||||
Content-Disposition: attachment; filename=smime.p7m
|
||||
|
||||
~~~
|
||||
|
||||
Depending on the scenario, further Header Fields MAY be exposed in the
|
||||
Outer Message Header Section, however - as stated above - this is NOT
|
||||
RECOMMENDED unless justified. Such Header Fields may include
|
||||
|
||||
* Cc
|
||||
* Bcc
|
||||
* References
|
||||
* Reply-To
|
||||
* In-Reply-To
|
||||
|
||||
\[\[ Open Issue: Should Cc HF be included anyways, if present and if To HF
|
||||
is not obfuscated? \]\]
|
||||
|
||||
### Obfuscation of Outer Message Header Fields {#obfuscation-outer-HF}
|
||||
|
||||
If certain values of the following Outer Message Header Fields are
|
||||
obfuscated, those SHOULD assume the following values:
|
||||
|
||||
~~~
|
||||
|
||||
* From: "Obfuscated" anonymous@anonymous.invalid
|
||||
* To: "Obfuscated" anonymous@anonymous.invalid
|
||||
* Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)
|
||||
* Subject: ...
|
||||
* Message-ID: <randomly generated ID>
|
||||
|
||||
~~~
|
||||
|
||||
Note: Alternative for Date: set to Monday 9am of the same week
|
||||
|
||||
In any case, it MUST be ensured that the Transport has access to the
|
||||
envelope information containing the source and destination(s) of a
|
||||
message.
|
||||
|
||||
\[\[ TODO: Do we need this explanation about the envelope? \]\]
|
||||
|
||||
Note: It is for further study to what extent Header Field obfuscation
|
||||
(adversely) impacts Spam Filtering.
|
||||
|
||||
|
||||
## Header Fields to Exclude from the Outer Message Header Section {#HF-exclude-outer}
|
||||
|
||||
The Outer Message Header Section SHOULD NOT contain any non-essential
|
||||
Header Fields. The essential Header Fields are defined in
|
||||
{#HF-include-outer}.
|
||||
|
||||
|
||||
## Message Processing
|
||||
|
||||
### Sending Side
|
||||
|
||||
For a protected message the following steps are applied before a
|
||||
message can be handed over to the Transport:
|
||||
|
||||
|
||||
#### Step 1: Decide on Protection Level and Information Disclosure {#sender-side-step-1}
|
||||
|
||||
The entity applying protection to a message must decide:
|
||||
|
||||
* Which protection level (signature and/or encryption) is applied to
|
||||
the message? This depends on user request and/or local policy as
|
||||
well as availability of cryptographic keys.
|
||||
|
||||
* Which Header Fields shall be part of the Outer Message Header
|
||||
Section? This typically depends on local policy. By Default the
|
||||
Header Fields listed in {{HF-include-outer}} are part of the Outer
|
||||
Message Header Section.
|
||||
|
||||
* Which of these Header Fields are to be obfuscated? This depends on
|
||||
local policy and/or specific Privacy requirements of the user. By
|
||||
Default no Header Field is obfuscated. (cf. {{obfuscation-outer-HF}})
|
||||
|
||||
|
||||
#### Step 2: Compose the Outer Message Header Section {#sender-side-step-2}
|
||||
|
||||
Depending on the decision in {{sender-side-step-1}}, compose the Outer
|
||||
Message Header Section. Note, that this also includes the necessary
|
||||
MIME Header Section part for the following protection layer. Outer
|
||||
Header Fields that are not obfuscated SHOULD contain the same values
|
||||
as in the Original Message (except for MIME Header Section part, which
|
||||
depends on the protection level selected in {{sender-side-step-1}}).
|
||||
|
||||
|
||||
#### Step 3: Apply Protection to the Original Message {#sender-side-step-3}
|
||||
|
||||
Depending on the protection level in selected in
|
||||
{{sender-side-step-1}} apply signature and/or encryption to the
|
||||
original message (as per {{RFC8551}}) and include the result to the
|
||||
message as Outer Message Body.
|
||||
|
||||
The resulting (Outer) Message is then typically handed over to the
|
||||
Transport.
|
||||
|
||||
\[\[ TODO: Example \]\]
|
||||
|
||||
|
||||
### Receiving Side
|
||||
|
||||
When a protected message is received the following steps are applied:
|
||||
|
||||
|
||||
#### Step 1: Decrypt message and/or check signature {#received-side-step-1}
|
||||
|
||||
Depending on the protection level the received message is decrypted
|
||||
and/or its signature is checked as per {{RFC8551}}.
|
||||
|
||||
|
||||
#### Step 2: Construct the Receiving User Facing Message {#received-side-step-2}
|
||||
|
||||
|
||||
The receiving User Facing Message is constructed as follows:
|
||||
|
||||
* The Header Section of the User Facing Message MUST consist of the
|
||||
Outer Message Header Fields that are not contained in the Inner
|
||||
Message Header Section, and the Inner Message Header Fields
|
||||
(i.e. the Inner Message Header Field MUST always take precedence).
|
||||
|
||||
* The Body of the User Facing Message Body MUST be the same as the
|
||||
Inner Message Body.
|
||||
|
||||
The resulting message is handed over for further processing, which
|
||||
typically involves rendering it to the user.
|
||||
|
||||
Note: It is for further study whether and, if yes, how the Outer
|
||||
Message Header Section (as received from the Transport) is
|
||||
preserved for the user.
|
||||
|
||||
|
||||
|
||||
## Backward Compatibility
|
||||
|
||||
{{I-D.autocrypt-lamps-protected-headers}} describes a possibility to
|
||||
achieve backward compatibility with existing S/MIME (and PGP/MIME)
|
||||
implementations unaware of this specification (Legacy Display). It
|
||||
mainly focuses on email clients that do not render emails using header
|
||||
protection (nicely) and may confuse the user. While this has been
|
||||
observed occasionally in PGP/MIME (cf. {{RFC3156}}), the extent of
|
||||
this problem with S/MIME implementations is still unclear. (Note: At
|
||||
this time, none of the samples in
|
||||
{{I-D.autocrypt-lamps-protected-headers}} applies header protection as
|
||||
specified in Section 3.1 of {{RFC8551}}, which is wrapping as Media
|
||||
Type "message/rfc822".)
|
||||
|
||||
Should serious Backward Compatibly issues with rendering at the
|
||||
receiver show up, {{I-D.autocrypt-lamps-protected-headers}} may serve
|
||||
as a basis to mitigate those.
|
||||
|
||||
Another variant of backward compatibility has been implemented by pEp
|
||||
{{I-D.pep-email}}, i.e. pEp Message Format 1.0. At this time pEp
|
||||
has only been implementing PGP/MIME, but not yet S/MIME.
|
||||
|
||||
|
||||
## Further Considerations
|
||||
|
||||
\[\[ TODO \]\]
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Loading…
Reference in new issue