|
|
@ -11,7 +11,7 @@ pi: [toc, sortrefs, symrefs, comments] |
|
|
|
|
|
|
|
author: |
|
|
|
{::include ../shared/author_tags/bernie_hoeneisen.mkd} |
|
|
|
#{::include ../shared/author_tags/alexey_melnikov.mkd} |
|
|
|
{::include ../shared/author_tags/alexey_melnikov.mkd} |
|
|
|
#{::include ../shared/author_tags/daniel_kahn_gillmor.mkd} |
|
|
|
|
|
|
|
normative: |
|
|
@ -49,6 +49,7 @@ informative: |
|
|
|
# I-D.marques-pep-handshake: |
|
|
|
# I-D.birk-pep-trustwords: |
|
|
|
# I-D.marques-pep-rating: |
|
|
|
{::include ../shared/references/pep-mixnet.mkd} |
|
|
|
|
|
|
|
|
|
|
|
--- abstract |
|
|
@ -179,26 +180,26 @@ determined by the IETF LAMPS WG. |
|
|
|
* 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. |
|
|
|
* Original Message (OrigM): The message to be protected before any |
|
|
|
protection related processing has been applied on the sending 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 |
|
|
|
* Inner Message (InM): The message to be protected, shortly before |
|
|
|
protection measures are applied to on the sending side or the message |
|
|
|
shortly after unwrapping on the receiving 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. |
|
|
|
on the sending and the receiving side. |
|
|
|
|
|
|
|
* Outer Message: The Message as handed over to the Transport or |
|
|
|
* Outer Message (OutM): 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. |
|
|
|
typically differs on the sending and the receiving side. |
|
|
|
|
|
|
|
* User Facing Message: The message used for rendering after the Outer |
|
|
|
Message Header Section has been merged with the Inner Message Header |
|
|
|
Section. |
|
|
|
* Receiving User Facing Message (RUFM): The message used for rendering |
|
|
|
at the receiving side 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}}. |
|
|
|
* Essential Header Fields (EHF): The Header Fields an Outer Message |
|
|
|
Header Section SHOULD contain at least; cf. {{outer-msg-hf}}. |
|
|
|
|
|
|
|
* Protected: Protected refers to the parts of a message where |
|
|
|
protection measures of any Protection Levels have been applied to. |
|
|
@ -335,9 +336,6 @@ a) Signature and encryption |
|
|
|
Messages containing a cryptographic signature which |
|
|
|
are also encrypted. |
|
|
|
|
|
|
|
Sending and receiving side SHOULD implement 'signature and |
|
|
|
encryption', which is the default to use on the sending side. |
|
|
|
|
|
|
|
|
|
|
|
b) Signature only |
|
|
|
|
|
|
@ -350,20 +348,12 @@ b) Signature only |
|
|
|
encrypted layer. |
|
|
|
--> |
|
|
|
|
|
|
|
Certain implementations MAY decide to send 'signature only' |
|
|
|
messages, depending on the circumstances and customer requirements. |
|
|
|
Sending and Receiving sides SHOULD implement 'signature only'. |
|
|
|
|
|
|
|
|
|
|
|
c) Encryption only |
|
|
|
|
|
|
|
Messages that encryption is applied to which do not contain a |
|
|
|
cryptographic signature. |
|
|
|
|
|
|
|
'Encryption only' is NOT RECOMMENDED on the sending side, however |
|
|
|
the receiving side needs certain guidelines on how to process |
|
|
|
received 'encrypted only' messages |
|
|
|
|
|
|
|
|
|
|
|
# Specification {#specification} |
|
|
|
|
|
|
@ -376,16 +366,21 @@ Furthermore, it is likely that PGP/MIME {{RFC3156}} will also take |
|
|
|
over this specification or parts of it. |
|
|
|
|
|
|
|
This specification applies to the protection levels "signature & |
|
|
|
encryption" and "signature only". It generally is NOT RECOMMENDED to send |
|
|
|
a message with protection level "encryption only". On the other hand, |
|
|
|
messages with protection level "encryption only" might arrive at the |
|
|
|
receiving side. While not targeted to protection level "encryption |
|
|
|
only", this specification is assumed to also function for "encryption |
|
|
|
only". |
|
|
|
|
|
|
|
<!-- TODO: Clean up this section with proceeding section (redundant |
|
|
|
statements) |
|
|
|
--> |
|
|
|
encryption" and "signature only" (cf. {{protection-levels}}): |
|
|
|
|
|
|
|
Sending and receiving sides SHOULD implement "signature and |
|
|
|
encryption", which is the default to use on the sending side. |
|
|
|
|
|
|
|
Certain implementations MAY decide to send "signature only" messages, |
|
|
|
depending on the circumstances and customer requirements. Sending |
|
|
|
side MAY and receiving sides SHOULD implement "signature only". |
|
|
|
|
|
|
|
It generally is NOT RECOMMENDED to send a message with protection |
|
|
|
level "encryption only". On the other hand, messages with protection |
|
|
|
level "encryption only" might arrive at the receiving side. While not |
|
|
|
targeted to protection level "encryption only", this specification is |
|
|
|
assumed to also function for "encryption only". Receiving sides SHOULD |
|
|
|
implement "encryption only". |
|
|
|
|
|
|
|
Note: It is for further study whether or not more guidance for |
|
|
|
handling messages with protection level "encryption only" at the |
|
|
@ -483,10 +478,10 @@ The Outer Message Header Section is unprotected, while the remainder |
|
|
|
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 |
|
|
|
(cf. {{inner-msg-hf}}). 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. |
|
|
|
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 |
|
|
@ -532,17 +527,12 @@ 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}}. |
|
|
|
|
|
|
|
### Inner Message Header Header Fields {#inner-msg-hf} |
|
|
|
|
|
|
|
### Header Fields to Exclude from the Inner Message Header Section {#HF-exclude-inner} |
|
|
|
|
|
|
|
The following Header Field MUST NOT be included to the Inner Message |
|
|
|
nor to any other protected part of the message: |
|
|
|
It is RECOMMEND that the Inner Messages contains all the Header Fields |
|
|
|
of the Original Message with the exception of the following Header |
|
|
|
Field, which MUST NOT be included to the Inner Message nor to any |
|
|
|
other protected part of the message: |
|
|
|
|
|
|
|
* Bcc |
|
|
|
|
|
|
@ -551,38 +541,43 @@ nor to any other protected part of the message: |
|
|
|
with Bcc recipients. \]\] |
|
|
|
|
|
|
|
|
|
|
|
### Header Fields to Include to the Outer Message Header Section {#HF-include-outer} |
|
|
|
### Outer Message Header Fields {#outer-msg-hf} |
|
|
|
|
|
|
|
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 |
|
|
|
The Outer Message Header Section is a subset of the Original Message (OrigM) |
|
|
|
Header Section 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 (cf. {{privacy}}). |
|
|
|
|
|
|
|
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. |
|
|
|
However, the Outer Message Header Section SHOULD contain the Essential |
|
|
|
Header Fields and MUST also contain the Header Fields of the MIME |
|
|
|
Header Section part. |
|
|
|
|
|
|
|
The following Header Fields are defined as the Essential Header Fields: |
|
|
|
|
|
|
|
* From |
|
|
|
* To |
|
|
|
* Cc (if present) |
|
|
|
* Bcc (if present, see also {{HF-include-outer}} and {{bcc-handling}}) |
|
|
|
* To (if present in the OrigM) |
|
|
|
* Cc (if present in the OrigM) |
|
|
|
* Bcc (if present in the OrigM, see also {{outer-msg-hf}} and {{bcc-handling}}) |
|
|
|
* Date |
|
|
|
* Message-ID |
|
|
|
* Subject |
|
|
|
|
|
|
|
Most of these Header Fields are needed by the Transport (e.g. to |
|
|
|
Some of these Header Fields are needed by the Transport (e.g. to |
|
|
|
determine the destination). Furthermore, not including certain Header |
|
|
|
Fields may trigger Spam Detection to flag the message as Spam and/or |
|
|
|
lead to User Experience (UX) issues. |
|
|
|
Fields may trigger spam detection to flag the message as spam and/or |
|
|
|
lead to user experience (UX) issues. |
|
|
|
|
|
|
|
For further Data Minimization the value of the Subject Header Field |
|
|
|
SHOULD be obfuscated. In addition, the value of other Essential Header |
|
|
|
Fields MAY be obfuscated. Further Header Fields MAY be obfuscated, |
|
|
|
though simply not adding those to the Outer Message Header SHOULD be |
|
|
|
prefered over obfuscation. Header Field obfuscation is further |
|
|
|
specified in {{obfuscation-outer-HF}}. |
|
|
|
|
|
|
|
For further Data Minimization the values of some of these Header |
|
|
|
Fields MAY be obfuscated, which is discussed further in |
|
|
|
{{obfuscation-outer-HF}}. |
|
|
|
Header Fields not obfuscated SHOULD contain the same values as in the |
|
|
|
Original Message. |
|
|
|
|
|
|
|
The MIME Header Section part is the collection of MIME Header Fields |
|
|
|
describing the following MIME structure as defined in {{RFC2045}}. |
|
|
@ -608,58 +603,45 @@ message (using application/pkcs7-mime with SignedData): |
|
|
|
{::include ../shared/fence-line.mkd} |
|
|
|
|
|
|
|
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 e.g.: |
|
|
|
Outer Message Header Section, which is NOT RECOMMENDED unless |
|
|
|
justified. Such Header Fields may include e.g.: |
|
|
|
|
|
|
|
* References |
|
|
|
* Reply-To |
|
|
|
* In-Reply-To |
|
|
|
|
|
|
|
|
|
|
|
#### Obfuscation of Outer Message Header Fields {#obfuscation-outer-HF} |
|
|
|
|
|
|
|
If certain values of the following Outer Message Header Fields are |
|
|
|
If the values of the following Outer Message Header Fields are |
|
|
|
obfuscated, those SHOULD assume the following values: |
|
|
|
|
|
|
|
~~~ |
|
|
|
|
|
|
|
* Subject: ... |
|
|
|
* Message-ID: <new randomly generated ID> |
|
|
|
* Message-ID: <new randomly generated Message-ID> |
|
|
|
* Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC) |
|
|
|
|
|
|
|
~~~ |
|
|
|
|
|
|
|
Note: Alternative for Date: set to Monday 9am of the same week |
|
|
|
|
|
|
|
Note: Should obfuscation of Subject be default? |
|
|
|
|
|
|
|
Note: It is for further study to what extent Header Field obfuscation |
|
|
|
(adversely) impacts Spam Filtering. |
|
|
|
|
|
|
|
\[\[ TODO: Determine whether also From, To, Cc could be obfucated, e.g. |
|
|
|
\[\[ TODO: Consider alternatives for Date e.g. set to Monday 9am of the |
|
|
|
same week. \]\] |
|
|
|
|
|
|
|
* From: "Obfuscated" anonymous@anonymous.invalid |
|
|
|
|
|
|
|
\]\] |
|
|
|
In certain implementations also the From, To, and/or Cc Header Field |
|
|
|
MAY be obfucated. Those may be replaced by e.g. |
|
|
|
|
|
|
|
\[\[ TODO: Determine whether mixnet capabilities \{\{pep.mixnets-url\}\} |
|
|
|
should be described further here. |
|
|
|
* To: Obfuscated <anonymous@anonymous.invalid> |
|
|
|
|
|
|
|
https://dev.pep.foundation/Mixnet/Messages |
|
|
|
https://gitea.pep.foundation/juga/pEpPythonMixnet |
|
|
|
https://dev.pep.foundation/Mixnet/ |
|
|
|
https://dev.pep.foundation/Mixnet/Mix%20networks |
|
|
|
Such implementations need to ensure that the Transport has access |
|
|
|
to these Header Fields in clear text and is capable to process those. |
|
|
|
|
|
|
|
\]\] |
|
|
|
A use case for obfuscation of all Outer Message Header Fields is |
|
|
|
mixnet netwerks, i.e. "onion routing" for email (e.g.{{pEp.mixnet}}). |
|
|
|
|
|
|
|
### 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}}. |
|
|
|
Note: It is for further study to what extent Header Field obfuscation |
|
|
|
(adversely) impacts spam filtering. |
|
|
|
|
|
|
|
<!-- TODO: combine this and last section; same for Inner --> |
|
|
|
|
|
|
|
### Message Processing |
|
|
|
### Message Processing {#message-processing} |
|
|
|
|
|
|
|
#### Sending Side |
|
|
|
|
|
|
@ -667,7 +649,7 @@ 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} |
|
|
|
##### Step 1: Decide on Protection Level and Information Disclosure {#sending-side-step-1} |
|
|
|
|
|
|
|
The entity applying protection to a message must decide: |
|
|
|
|
|
|
@ -675,33 +657,34 @@ The entity applying protection to a message must decide: |
|
|
|
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 Header Fields of the Orignial Message shall be part of the |
|
|
|
Outer Message Header Section? This typically depends on local |
|
|
|
policy. By default the Essential Header Fields are part of the Outer |
|
|
|
Message Header Section (in addition to the MIME Header Section |
|
|
|
part); cf. {{outer-msg-hf}}. |
|
|
|
|
|
|
|
* Which of these Header Fields are to be obfuscated? This depends on |
|
|
|
local policy and/or specific Privacy requirements of the user. By |
|
|
|
default only the Subject Header Field is |
|
|
|
obfuscated. (cf. {{obfuscation-outer-HF}}) |
|
|
|
obfuscated; cf. {{obfuscation-outer-HF}}. |
|
|
|
|
|
|
|
|
|
|
|
##### Step 2: Compose the Outer Message Header Section {#sender-side-step-2} |
|
|
|
##### Step 2: Compose the Outer Message Header Section {#sending-side-step-2} |
|
|
|
|
|
|
|
Depending on the decision in {{sender-side-step-1}}, compose the Outer |
|
|
|
Depending on the decision in {{sending-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}}). |
|
|
|
{{sending-side-step-1}}). |
|
|
|
|
|
|
|
|
|
|
|
##### Step 3: Apply Protection to the Original Message {#sender-side-step-3} |
|
|
|
##### Step 3: Apply Protection to the Original Message {#sending-side-step-3} |
|
|
|
|
|
|
|
Depending on the protection level in selected in |
|
|
|
{{sender-side-step-1}} apply signature and/or encryption to the |
|
|
|
{{sending-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. |
|
|
|
|
|
|
@ -716,28 +699,30 @@ Transport. |
|
|
|
When a protected message is received the following steps are applied: |
|
|
|
|
|
|
|
|
|
|
|
##### Step 1: Decrypt message and/or check signature {#received-side-step-1} |
|
|
|
##### Step 1: Decrypt message and/or check signature {#receiving-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} |
|
|
|
|
|
|
|
##### Step 2: Construct the Receiving User Facing Message {#receiving-side-step-2} |
|
|
|
|
|
|
|
The receiving User Facing Message is constructed as follows: |
|
|
|
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 |
|
|
|
* The Header Section of the Receiving 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 Body of the Receiving 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. |
|
|
|
|
|
|
|
\[\[ TODO: Do we need to take special care for HFs, which may appear |
|
|
|
multiple times, e.g. Received HF? \]\] |
|
|
|
|
|
|
|
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. |
|
|
@ -791,7 +776,7 @@ The authors would like to thank the following people who have provided |
|
|
|
helpful comments and suggestions for this document: Claudio Luck, |
|
|
|
David Wilson, Hernani Marques, Krista Bennett, Kelly Bristol, Robert |
|
|
|
Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei Chuang. |
|
|
|
<!-- TODO: depending on authors, add Alexey / DKG --> |
|
|
|
<!-- TODO: add DKG either to authors or to Acknowledgements --> |
|
|
|
|
|
|
|
--- back |
|
|
|
|
|
|
@ -851,21 +836,23 @@ header field may appear in up to three different variants: |
|
|
|
before publication. \]\] |
|
|
|
|
|
|
|
* Decide on format of obfuscated HFs, in particular Date HF |
|
|
|
({{obfuscation-outer-HF}}) |
|
|
|
|
|
|
|
* Do we need to mention something about the envelope (some HF may no |
|
|
|
longer be readable, but need for envelope) ? |
|
|
|
|
|
|
|
* Impact on Spam Filtering, if HFs are obfuscated |
|
|
|
* Impact on spam filtering, if HFs are obfuscated |
|
|
|
({{obfuscation-outer-HF}}) |
|
|
|
|
|
|
|
* More examples |
|
|
|
* More examples (e.g. in {{message-processing}}) |
|
|
|
|
|
|
|
* Should Outer Message Header Section (as received) be preserved for |
|
|
|
the user? |
|
|
|
the user? ({{receiving-side-step-2}}) |
|
|
|
|
|
|
|
* Do we need to take special care of HFs that may appear multiple |
|
|
|
times, e.g. Received HF? ({{receiving-side-step-2}}) |
|
|
|
|
|
|
|
* Change adding Content-Type header field parameter "forwarded" from |
|
|
|
SHOULD to MUST {{mime-format}}? |
|
|
|
SHOULD to MUST ({{mime-format}})? |
|
|
|
|
|
|
|
* Decide on whether or not merge requirement from |
|
|
|
* Decide on whether or not merge requirements from |
|
|
|
{{I-D.ietf-lamps-header-protection-requirements}} into this |
|
|
|
document. |
|
|
|
|
|
|
@ -874,13 +861,14 @@ header field may appear in up to three different variants: |
|
|
|
|
|
|
|
* Enhance Introduction and Problem Statement sections |
|
|
|
|
|
|
|
* Decide in whether or not more legacy HP requirements should be |
|
|
|
in this document |
|
|
|
* Decide on whether or not specification for more legacy HP |
|
|
|
requirements should be added to this document |
|
|
|
|
|
|
|
* Improve definitions in {{protection-levels}} |
|
|
|
|
|
|
|
* Privacy Considerations |
|
|
|
* Privacy Considerations {{privacy-considerations}} |
|
|
|
|
|
|
|
* Security Considerations {{security-considerations}} |
|
|
|
|
|
|
|
|
|
|
|
<!-- |
|
|
|