Browse Source

- Added figure with different messages (OrigM, OuterM, etc.)

- Update some specification text, mostely around Inner Message Header Section
master
Bernie Hoeneisen 1 year ago
parent
commit
a1d4b97021
3 changed files with 103 additions and 80 deletions
  1. +1
    -0
      ietf-lamps-hp/Makefile
  2. +75
    -26
      ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd
  3. +27
    -54
      shared/ascii-arts/message_orig_outer_inner_rufm.mkd

+ 1
- 0
ietf-lamps-hp/Makefile View File

@ -17,6 +17,7 @@ $(DRAFT).xml: $(NAME).mkd \
../shared/text-blocks/key-words-rfc2119.mkd \
../shared/text-blocks/terms-intro.mkd \
../shared/text-blocks/mitm.mkd \
../shared/ascii-arts/message_orig_outer_inner_rufm.mkd \
../shared/fence-line.mkd \
# ../shared/text-blocks/implementation-status.mkd \
# ../shared/author_tags/daniel_kahn_gillmor.mkd \


+ 75
- 26
ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd View File

@ -185,16 +185,18 @@ determined by the IETF LAMPS WG.
* Original Message (OrigM): The message to be protected before any
protection related processing has been applied on the sending side.
* 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 sending and the receiving side.
* Outer Message (OutM): The Message as handed over to the Transport or
received from the Transport respectively. The Outer Message
typically differs on the sending and the receiving side.
* Inner Message (InnerM): The message to be protected, shortly before
protection measures are applied to on the sending side or the
message shortly after decryption and/or unwrapping the signed part
on the receiving side. Typically the Inner Message is in clear text.
The Inner Message is rather similar as the Original Message. The
Inner Message MUST be the same on the sending and the receiving
side.
* Outer Message (OuterM): The Message as handed over to the Transport
or received from the Transport respectively. The Outer Message
normally differs on the sending and the receiving side (e.g. new
Header Fields are added by intermediary nodes).
* Receiving User Facing Message (RUFM): The message used for rendering
at the receiving side after the Outer Message Header Section has
@ -404,10 +406,10 @@ client MAY wrap 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 Content-Type header field parameter "forwarded"
SHOULD be added as defined in {{I-D.melnikov-iana-reg-forwarded}}.
Certain mailing applications might display the Inner Message as
attachment otherwise.
wrapped message, a Content-Type header field parameter "forwarded" is
added as defined in {{I-D.melnikov-iana-reg-forwarded}}. Certain
mailing applications might display the Inner Message as attachment
otherwise.
In the simplest case, a message looks as follows:
@ -476,12 +478,15 @@ prepended by "W: " are the wrapper (MIME Header Section):
{::include ../shared/fence-line.mkd}
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. {{inner-msg-hf}}). The Inner Message Body is the same as the
Original Message Body (before header protection has been applied).
(Outer Message Body) is protected. The Outer Message Body consists of
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 preceded by a MIME Header Section with
media type "message/RFC822" containing a Content-Type header field
parameter "forwarded=no" (cf. {{inner-msg-hf}}).
The Inner Message Body is the same as the Original Message Body.
The Original Message itself may contain any defined MIME structure.
@ -542,19 +547,21 @@ other protected part of the message:
{{bcc-handling}}). Certain MUAs cannot properly decrypt messages
with Bcc recipients. \]\]
In additon, the Inner Message Header Section MUST be preceded by a
MIME Header Section with media type "message/RFC822" that SHOULD
contain the Content-Type header field parameter "forwarded=no" as
defined in {{I-D.melnikov-iana-reg-forwarded}}.
### Outer Message Header Fields {#outer-msg-hf}
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.
### Outer Message Header Fields {#outer-msg-hf}
To maximize Privacy, it is strongly RECOMMENDED to follow the
principle of Data Minimization (cf. {{privacy}}).
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.
Header Fields and, in addition, MUST contain the Header Fields of the
MIME Header Section part to describe the encryption or signature as
per {{RFC8551}}.
The following Header Fields are defined as the Essential Header Fields:
@ -645,6 +652,48 @@ Note: It is for further study to what extent Header Field obfuscation
### Message Processing {#message-processing}
The Following figure depicts the different message representations
(OrigM, InnerM, OuterM, RUFM) and which parts those are constructed
from:
{::include ../shared/fence-line.mkd}
{::include ../shared/ascii-arts/message_orig_outer_inner_rufm.mkd}
{::include ../shared/fence-line.mkd}
Legend:
* OuterM(S): Outer Message (OuterM) at sending side (before processing
by Transport)
* OuterM(R): Outer Message at receiving side (as received by Transport)
* InnerM: Inner Message (that protection is applied to)
* RUFM: Receiving User Facing Message
* More-HF: Additional Header Fields (HF) in the Original Message (OrigM)
* MIME-HS: MIME Header Section; with media type (message/RFC822)
* MIME-HSp: MIME Header Section part
* Trans-HF: Header Fields added in Transit (between sending and
receiving side)
* '>': taken over / copied from last column
* '=': propagates unchanged, unless something unusual (e.g. attack)
happens
* '(*)': HF is often not present (but also further HF may not be
present). If the HF is not present, naturally it can neither be
taken over nor propagated.
* '(new)' / '(OrigM)': HF or MIME-HSp is generated depending on the
decision in {{sending-side-step-1}}, while '(new)' / '(OrigM)'
designate the default.
#### Sending Side
For a protected message the following steps are applied before a


+ 27
- 54
shared/ascii-arts/message_orig_outer_inner_rufm.mkd View File

@ -1,55 +1,28 @@
OrigM InM OutM(S) OutM(R) RUFM
<Trans-HF> > <Trans-HF>
From (OrigM) = From
To (OrigM) = To
Cc (OrigM) = Cc
Bcc (OrigM) = Bcc (*) > Bcc
Date (OrigM) = Date
Message-ID (OrigM) = Message-ID
Subject (new) = Subject
<MIME-HSp> (new) = <MIME-HSp>
PROTECTED: PROTECTED:
From > From > From = From > From
To (*) > To > To = To > To
Cc (*) > Cc > Cc = Cc > Cc
Bcc (*)
Date > Date > Date = Date > Date
Message-ID > Message-ID > Message-ID = Message-ID > Message-ID
Subject > Subject > Subject = Subject > Subject
<More HF> > <More HF> > <More HF> = <More HF> > <More-HF>
<MIME-HSp> > <MIME-HSp> > <MIME-HSp> = <MIME-HSp> > <MIME-HSp>
<Body> > <Body> > <Body> = <Body> > <Body>
OrigM InnerM Outer(S) OuterM(R) RUFM
<Trans-HF> > <Trans-HF>
From (OrigM) = From
To (OrigM) = To
Cc (OrigM) = Cc
Bcc (OrigM) = Bcc (*) > Bcc
Date (OrigM) = Date
Message-ID = Message-ID
(OrigM)
Subject (new) = Subject
<MIME-HSp> (new) = <MIME-HSp>
PROTECTED: PROTECTED:
<MIME-HS> > <MIME-HS> = <MIME-HS>
(new)
From > From > From = From > From
To > To > To = To > To
Cc (*) > Cc > Cc = Cc > Cc
Bcc (*)
Date > Date > Date = Date > Date
Message-ID > Message-ID > Message-ID = Message-ID > Message-ID
Subject > Subject > Subject = Subject > Subject
<More HF> > <More HF> > <More HF> = <More HF> > <More-HF>
<MIME-HSp> > <MIME-HSp> > <MIME-HSp> = <MIME-HSp> > <MIME-HSp>
<Body> > <Body> > <Body> = <Body> > <Body>
Legend:
* OutM(S): Outer Message (OutM) at sending side (before processing by
Transport)
* OutM(R): Outer Message at receiving side (as received by Transport)
* InM: Inner Message (that protection is applied to)
* RUFM: Receiving User Facing Message
* More-HF: Additional Header Fields (HF) in the Original Message (OrigM)
* MIME-HSp: MIME Header Section part
* Trans-HF: Header Fields added in Transit (between sending and
receiving side)
* '>': taken over / copied from last column
* '=': propagates unchanged, unless something unusual (e.g. attack)
happens
* '(*)': HF may not be prosent (in which case it is neither taken over
nor does it propagate)
* '(new)' / '(OrigM)': HF or MIME-HSp is generated depending on the
decision in {{sending-side-step-1}}, while '(new)' / '(OrigM)'
designate the default

Loading…
Cancel
Save