juga
/
internet-drafts
forked from pEp.foundation/internet-drafts
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

non-issues and editorials (e.g.typos, restructure, grammar) taken over from head version

Browse Source
master
Bernie Hoeneisen 3 years ago
parent 1b303ef2e7
commit 1d296dde1c
1 changed files with 62 additions and 55 deletions
Show Stats Download Patch File Download Diff File

117
misc/temp/draft-ietf-lamps-header-protection.mkd-am
Unescape View File

@ -18,20 +18,24 @@ normative:
# RFC822:
# RFC1847:
# RFC1341:
RFC2045: # MIME part 1 #
RFC2046: # MIME part 2 #
RFC5322: # SMTP #
RFC2045: # MIME part 1 Format of Internet Message Bodies #
RFC2046: # MIME part 2 Media Types #
# RFC2047: # MIME part 3 Message Header Extensions for Non-ASCII Text #
# RFC2048: # MIME part 4 Registration Procedures #
RFC2049: # MIME part 5 Conformance Criteria #
RFC5322: # Internet Message Format #
RFC8551: # S/MIME #
I-D.ietf-lamps-header-protection-requirements:
informative:
# RFC1939: # POP3 #
# RFC8301:
# RFC8463:
RFC3156: # PGP/MIME #
# RFC3501: # IMAP #
RFC4949: # Internet Security Glossary #
# RFC4880: # OpenPGP #
# RFC5321:
RFC5321: # SMTP #
# RFC5490:
RFC6376: # DKIM #
RFC6409:
@ -127,11 +131,6 @@ mechanism is to be determined by the IETF LAMPS WG.
{::include ../shared/text-blocks/terms-intro.mkd}
> 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}}.
<!-- {::include ../shared/text-blocks/handshake.mkd} -->
<!-- {::include ../shared/text-blocks/trustwords.mkd} -->
<!-- {::include ../shared/text-blocks/tofu.mkd} -->
@ -141,13 +140,22 @@ mechanism is to be determined by the IETF LAMPS WG.
* PGP/MIME: MIME Security with OpenPGP (cf. {{RFC3156}})
* Message: An Email Message consisting of Header Fields
(collectively called "the Header Section of the message") followed,
optionally, by a Body; 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 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}}.
* 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.
(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
@ -169,24 +177,6 @@ mechanism is to be determined by the IETF LAMPS WG.
* Essential Header Fields (EHF): The minimum set of Header Fields an
Outer Message Header Section SHOULD contain; cf. {{outer-msg-hf}}.
* Message: An Email Message consisting of Header Hields
(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.
<!-- Feedback KRB:
It's confusing to define transport as both an entity and process. I
realize that's exactly what it is, but it reads awkwardly. Suggest
"delivery", "transit", "transfer", or similar. The other uses of
"transport" are okay, just this opening sentence needs help.
-->
The Transport on the
sending side typically determines the destination recipients by
reading the To, Cc and Bcc Header Fields (of the Outer
Message). The Transport is typically implemented by an MTA (Mail
Transfer Agent).
* Header Protection (HP): cryptographic protection of email Header
Sections (or parts of it) for signatures and/or encryption
@ -204,6 +194,18 @@ mechanism is to be determined by the IETF LAMPS WG.
cryptographic signing) is applied to a message.
-->
* Protected: Protected refers to the parts of a Message where
protection measures of any Protection Level 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.
* Original Message (OrigM): The message to be protected before any
protection related processing has been applied on the sending side.
@ -224,18 +226,21 @@ mechanism is to be determined by the IETF LAMPS WG.
at the receiving side. Typically this is the same as the Inner
Message.
* Protected: Protected refers to the parts of a message where
protection measures of any Protection Level 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.
* * Transport: The entity taking care of the transport of a Message
towards the receiver or from the sender.
<!-- Feedback KRB:
It's confusing to define transport as both an entity and process. I
realize that's exactly what it is, but it reads awkwardly. Suggest
"delivery", "transit", "transfer", or similar. The other uses of
"transport" are okay, just this opening sentence needs help.
-->
The Transport on the
sending side typically determines the destination recipients by
reading the To, Cc and Bcc Header Fields (of the Outer
Message). The Transport is typically implemented by an MTA (Mail
Transfer Agent).
* Data Minimization: Data sparseness and hiding of all technically
concealable information whenever possible.
@ -282,7 +287,7 @@ In the following a set of challenges to be addressed:
# Use Cases {#use-cases}
In the following, the reader can find a list of the generic use cases
that need to be addressed for messages with Header Protection
that need to be addressed for Messages with Header Protection
(HP). These use cases apply regardless of technology (S/MIME,
PGP/MIME, etc.) used to achieve HP.
@ -290,7 +295,7 @@ PGP/MIME, etc.) used to achieve HP.
## Interactions {#interactions}
### Main Case for Header Protection
### Main Use Case {#uc-ia-main-use-case}
Both peers (sending and receiving side) fully support Header
Protection as specified in this document or the receiving side is at
@ -298,6 +303,7 @@ least compliant with the MIME specification {{RFC2045}}, ff.;
cf. {{main-use-case}}.
### Backward Compatibility
<!--
@ -305,7 +311,7 @@ Alexey: why is the following text talking about not supporting MIME?
MIME was introduced almost 30 years ago!
Did you really mean "supports MIME, but doesn't support this specification"?
-->
The sending side fully supports Header protection as specified in this
The sending side fully supports Header Protection as specified in this
document, while the receiving side does not support the MIME
specification {{RFC2045}}, ff. correctly; see
{{backward-compatibility-use-case}}.
@ -350,8 +356,8 @@ This section contains the specification for Header Protection in
S/MIME to update and it clarifies Section 3.1 of {{RFC8551}} (S/MIME
4.0).
Furthermore, it is likely that PGP/MIME {{RFC3156}} will also incorprorate
this specification or parts of it.
Furthermore, it is likely that PGP/MIME {{RFC3156}} will also
incorporate this specification or parts of it.
This specification applies to the protection levels "signature &
encryption" and "signature only" (cf. {{protection-levels}}):
@ -638,7 +644,7 @@ The following Header Fields are defined as the Essential Header Fields:
Some of these Header Fields are required by RFC 5322 (e.g. Message-ID).
Furthermore, not including certain Header
Fields may trigger spam detection to flag the message as spam and/or
Fields may trigger spam detection to flag the message and/or
lead to user experience (UX) issues.
For further Data Minimization, the value of the Subject Header Field
@ -718,7 +724,7 @@ these Header Fields in clear text and is capable of processing those.
-->
A use case for obfuscation of all Outer Message Header Fields is
mixnet networks, i.e. "onion routing" for email (e.g.{{pEp.mixnet}}).
mixnet networks, i.e. "onion routing" for email (e.g. {{pEp.mixnet}}).
Note: It is for further study to what extent Header Field obfuscation
adversely impacts spam filtering.
@ -900,7 +906,7 @@ Type "message/RFC822".)
Should serious backward compatibility issues with rendering at the
receiver be discovered, the Legacy Display format described in
{{I-D.autocrypt-lamps-protected-headers}} may serve as a basis to
mitigate those issues (cf. {{backward-compatibility-use-case}}).
mitigate those issues (cf. {{backward-compatibility-use-cases}}).
Another variant of backward compatibility has been implemented by pEp
{{I-D.pep-email}}, i.e. pEp Email Format 1.0. At this time pEp
@ -930,7 +936,7 @@ The authors would like to thank the following people who have provided
helpful comments and suggestions for this document: Berna Alp, Claudio
Luck, David Wilson, Hernani Marques, Krista Bennett, Kelly Bristol,
Robert Williams, Sofia Balicka, Steve Kille, Volker Birk, and Wei
Chuang. <!-- TODO: add DKG either to authors or to Acknowledgements
Chuang. <!-- TODO: add DKG either to authors or to Acknowledgments
-->
--- back
@ -987,7 +993,7 @@ the message has to be cloned and adjusted depending on the recipient.
* draft-ietf-lamps-header-protection-00
* Initial version (text partialy taken over from
* Initial version (text partially taken over from
{{I-D.ietf-lamps-header-protection-requirements}}
# Open Issues
@ -1044,10 +1050,11 @@ LocalWords: Winterthur Hoeneisen GmbH Zuerich bernhard hoeneisen rfc
LocalWords: ucom ietf melnikov birk trustwords keysync Volker ann cb
LocalWords: ISOC bnet OpenPGP pgp msg asc pEpkey MUAs UI req SMTP WG
LocalWords: UX Programme Changelog IMAP DKIM DMARC DomainKeys HB HFs
LocalWords: implementer's pkcs SignedData cryptographically LF
LocalWords: prio charset Bcc LSS LSR wrt DKG prepending TBD fc
LocalWords: recurse TLS EFAIL cleartext plaintext mixnet MMHS
LocalWords: anonymization Alexey Isode ascii prepended micalg
LocalWords: sha cbe Chuang Kille cryptographic interoperability
LocalWords: roadmap
LocalWords: implementer's pkcs SignedData cryptographically LF iana
LocalWords: prio charset Bcc LSS LSR wrt DKG prepending TBD fc KRB
LocalWords: recurse TLS EFAIL cleartext plaintext mixnet MMHS CRLF
LocalWords: anonymization Alexey Isode ascii prepended micalg EHF uc
LocalWords: sha cbe Chuang Kille cryptographic interoperability RUFM
LocalWords: roadmap autocrypt OrigM InnerM OuterM MSA MTA ia bc bcc
LocalWords: subtypes smime rufm HSp Berna Balicka
-->

Write Preview
Loading…
Cancel
Save