Browse Source

partial integration of Alexey's comments

master
Bernie Hoeneisen 2 years ago
parent
commit
e1dec00821
2 changed files with 24 additions and 14 deletions
  1. +23
    -13
      ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd
  2. +1
    -1
      shared/ascii-arts/message_orig_outer_inner_rufm.mkd

+ 23
- 13
ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd View File

@ -162,8 +162,9 @@ determined by the IETF LAMPS WG.
Message. Typically, the Body consists of a (multipart) MIME
{{RFC2045}} construct.
* MIME Header Fields: Header Fields describing the MIME structure of
its body as defined in {{RFC2045}}.
* MIME Header Fields: Header Fields describing content of a MIME entity
{{RFC2045}}, in particular the MIME structure. Each MIME Header Field
name starts with "Content-" prefix.
* MIME Header Section (part): The collection of MIME Header Fields.
"MIME Header Section" refers to a Header Sections that contains only
@ -331,21 +332,20 @@ c) Encryption only
This section contains the specification for Header Protection in
S/MIME to update and clarifies Section 3.1 of {{RFC8551}} (S/MIME
4.0). This specification is likely to be integrated into S/MIME at
some later stage.
4.0).
Furthermore, it is likely that PGP/MIME {{RFC3156}} will also take
over this specification or parts of it.
Furthermore, it is likely that PGP/MIME {{RFC3156}} will also incorprorate
this specification or parts of it.
This specification applies to the protection levels "signature &
encryption" and "signature only" (cf. {{protection-levels}}):
Sending and receiving sides SHOULD implement "signature and
Sending and receiving sides MUST 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".
side MAY and receiving sides MUST implement "signature only".
It generally is NOT RECOMMENDED to send a message with protection
level "encryption only". On the other hand, messages with protection
@ -473,10 +473,11 @@ The Inner Message Body is the same as the Original Message Body.
The Original Message itself may contain any 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 (wrapped in a "message/RFC822") along with other MIME part(s).
-->
#### Alternative Option Autocrypt "Protected Headers" (Ex-"Memory Hole") {#option-ex-memory-hole}
@ -562,10 +563,11 @@ The Inner Message Body is the same as the Original Message Body.
The Original Message itself may contain any 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 along with other MIME part(s).
-->
### Inner Message Header Fields {#inner-msg-hf}
@ -634,7 +636,12 @@ Fields:
* Content-Transfer-Encoding
* Content-Disposition
The following example shows the MIME header of an S/MIME signed
<!--
Alexey: I don't find separation between MIME Header Section and
full Header Section to be useful. They have exactly the same parsing
rules.
-->
The following example shows the MIME Header Section part of an S/MIME signed
message (using application/pkcs7-mime with SignedData):
{::include ../shared/fence-line.mkd}
@ -655,6 +662,9 @@ justified. Such Header Fields may include e.g.:
* Reply-To
* In-Reply-To
<!--
Alexey: the above header fields would be need if IMAP server side threading is to be used.
-->
#### Obfuscation of Outer Message Header Fields {#obfuscation-outer-HF}
@ -732,8 +742,8 @@ Legend:
* MIME-HSp: MIME Header Section part to describe the encryption or
signature as per {{RFC8551}}
* Trans-HF: Header Fields added in Transit (between sending and
receiving side)
* Trace-HF: Header Fields added in Transit (between sending and
receiving side) as per {{RFC5322}}
* \>: taken over / copied from last column


+ 1
- 1
shared/ascii-arts/message_orig_outer_inner_rufm.mkd View File

@ -1,6 +1,6 @@
OrigM InnerM Outer(S) OuterM(R) RUFM
<Trans-HF> > <Trans-HF>
<Trace-HF> > <Trace-HF>
From (OrigM) = From
To (OrigM) = To
Cc (OrigM) = Cc


Loading…
Cancel
Save