forked from pEp.foundation/internet-drafts
parent
37b03756ec
commit
6dcff55888
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 \]\]
|
||||
|
||||
Loading…
Reference in new issue