pep-email: comment out things

4 years ago · fe4f4069c8
parent b6e3f485f2
commit fe4f4069c8
1 changed files with 62 additions and 111 deletions
--- a/pep-email/draft-marques-pep-email.mkd
+++ b/pep-email/draft-marques-pep-email.mkd
@ -144,7 +144,9 @@ understand the other normatively referenced documents, in particular
 {::include ../shared/text-blocks/mitm.mkd}


-# Application of the Core Design Principles
+# Opportunistic Security and Privacy for Email
+
+<!-- # Application of the Core Design Principles -->

 In addition to the Protocol's Core Design Principles outlined in
 {{I-D.birk-pep}}, the following sections on design principles apply
@ -223,10 +225,10 @@ to be energy intensive, thus drains a battery quickly). \]\]
 **TODO**: Check if we do this already, and check with VB the exact
 requirement. \]\]

-
+<!-- 
 ### Data Minimization with S/MIME

-\[\[ **TODO**: What about S/MIME? \]\]
+\[\[ **TODO**: What about S/MIME? \]\] -->



@ -415,7 +417,7 @@ recovered protected message is selfsufficiently described, including
 all protected header fields.


-### Compatibility for Header Protection
+### Header Protection

 The pEp Message Format 2 (in use by all current pEp implementations,
 cf. {{implementation-status}}) is similar to what is standardized for
@ -436,15 +438,15 @@ S/MIME in {{RFC8551}}:
 \[\[ **NOTE**: the first sentence in the quotation above is cited
 multiple times in this document. \]\]

-
+<!-- 
 ## End-to-End {#end-to-end}

-\[\[ **TODO**: Add here what is specific to email \]\] 
+\[\[ **TODO**: Add here what is specific to email \]\]  -->


-## Peer-to-Peer {#peer-to-peer}
+<!-- ## Peer-to-Peer {#peer-to-peer}

-\[\[ **TODO**: Add here what is specific to email \]\] 
+\[\[ **TODO**: Add here what is specific to email \]\]  -->

 <!-- clients MUST forward wrapped Messages -->
 <!-- 
@ -500,26 +502,26 @@ an error to encounter multiple tokens.



-### Handshake Dialog in Edit Message
-
-### Device Grouping
+<!-- ### Handshake Dialog in Edit Message -->

-### OpenPGP Key Import
+<!-- ### Device Grouping -->

+<!-- ### OpenPGP Key Import -->

+<!-- 
 ### Incoming Message Processing

 \[\[ **TODO**: Post-decryption filtering, local content indexing. \]\]

 \[\[ **TODO**: Support for local content indexing/searching. \]\]

-\[\[ **TODO**: Processing Incoming Email under Progressive Header Disclosure \]\]
-
+\[\[ **TODO**: Processing Incoming Email under Progressive Header Disclosure \]\] -->

+<!-- 

 #### Processing Incoming Email under Progressive Header Disclosure

-\[\[ TODO \]\]
+\[\[ TODO \]\] -->

 <!-- 
 ## Resolving Conflicting Protected and Unprotected Header Fields
@ -537,7 +539,7 @@ plaintext Messages are duly verified but cannot enhance the perceived
 quality of the message in the user interface, while an invalid
 signature degrades the perception, cf. {{I-D.birk-pep}}.

-
+<!-- 
 #### Incoming Filter Processing

 The Mail User Agent may implement outgoing filtering of mails, which
@ -555,9 +557,9 @@ upon first reception of the message the mailbox server is limited to
 see the transport- relevant headers of the outer wrapper message. A
 pEp client configured to trust the server (see
 {{opt-trusted-server}}) will later download the encrypted message,
-decrypt it and replace the copy on the server by the decrypted copy.
-
+decrypt it and replace the copy on the server by the decrypted copy. -->

+<!-- 
 #### Staged Filtering of Inbound Messages

 Inbound Messages are expected to be delivered to the inbox while
@ -573,21 +575,23 @@ eventually download the encrypted message, decrypt it locally and
 replace the copy on the server by the decrypted copy. Server-side
 message filters SHOULD be able to detect such post-processed
 Messages, and apply the pending filters. The client SHOULD easily
-reflect the post-filtered Messages in the user interface.
-
+reflect the post-filtered Messages in the user interface. -->

+<!-- 
 #### Outgoing Filter Processing
+ -->

+<!-- 
 The Mail User Agent may implement outgoing filtering of emails, which may veto,
 alter or replicate the email. They may also hint the MUA to store a copy in an
-alternate "Sent" folder.
+alternate "Sent" folder. -->

 <!-- pEp compliant clients MUST keep all details about cryptography away from the
 user interface and keep it transparent to the user (for the exception of
 Trustwords comparison). Outgoing filters SHOULD thus be applied on a temporary
 representation of the mail with all possible parts unencrypted and unprotected
 (the "unprotected representation of the mail"). -->
-
+<!-- 
 Filters which veto the sending or do alter the mail or replicate it (e.g.,
 mass-mail generators) SHOULD be completed prior to applying protection, and
 thus also prior to applying header protection. Redirection to alternate "Sent"
@ -595,16 +599,16 @@ folders MUST NOT be decided prior to applying protection, but MUAs MAY abide
 from this restriction if they implement the "trusted server" option and the
 option is selected for the specific mailbox server; in this case, MUAs MUST NOT
 allow to redirect a message to an untrusted server by these rules, to prevent
-information leakage to the untrusted server.
+information leakage to the untrusted server. -->

 <!-- specify if filter may alter email without additional feedback,
 and enforce the no-color-degradation policy -->
-
+<!-- 
 \[\[ TODO: Mention implicit filter for minimal color-rating for
 message replication. \]\]

 \[\[ TODO: How to produce key-export-mails manually this way? That is, what
-about non-pEp-mode? \]\]
+about non-pEp-mode? \]\] -->

 <!--
 ## Challenges faced
@ -712,7 +716,7 @@ detailed in [usenix.defective-sgn-enc] back in 2001.

 # pEp Email Protocol Specification

-
+<!-- 
 ## Multiple Identities

 pEp MUAs MUST support multiple identities to be used as "Sender
@ -728,11 +732,13 @@ follows:

 1. all uppercase characters are replaced by lowercase
 2. any dot (".") in the local part of Gmail addresses are removed
+ -->

+<!-- 
 \[\[ **TODO**: What about all the other G Suite Gmail customers? What
 about other ISPs also ignoring dots? Do we need a domain list, a IANA
 registry? Or do we want to resolve by DNS (probably not)? Offer a
-central list (probably not)? \]\]
+central list (probably not)? \]\] -->

 <!-- 
 Identities are independent of mailboxes and submission MTAs, but a
@ -767,15 +773,19 @@ choose the Identity.

 -->

+<!-- 
 \[\[ **NOTE**: For the purpose of key reset we record recently
 contacted correspondents; the fact that Outgoing Messages MAY be
 transient (e.g. writing a draft, or to obtain ratings) allows things
-to go out of sync here. \]\]
+to go out of sync here. \]\] -->
+


+<!-- ## Trust Reflection -->

-## Trust Reflection
+## Trust System

+<!-- 
 About the pEp identity system.

 ### Key {#elements-key}
@ -788,29 +798,30 @@ About the pEp identity system.

 ### Identity {#elements-identity}

-\[\[ TODO: Add here what is specific to email \]\] 
+\[\[ TODO: Add here what is specific to email \]\]  -->

-### Alias {#elements-alias}
+<!-- 
+### Alias {#elements-alias} -->

 ### Address {#elements-address}

 For pEp Email the SMTP address (e.g. joe@example.org) constitutes the address.


-
+<!-- 
 ## Opportunistic Protection
-
+ -->


 ## Pervasive Forwarding
+<!-- 

-
-### Transports and Transport Selection
-
+### Transports and Transport Selection -->


+<!-- 
 ### Interface to Cryptographic Services
-
+ -->


 ### Message Decoding and Encoding {#msg-codec}
@ -825,7 +836,9 @@ fields from unintended MTAs.
 For encoding the cryptographic protection, pEp for Email relies on
 {{MIMESEC}} which defines security multipart formats for MIME. Both
 {{SMIME}} and {{PGPMIME}} build upon {{MIMESEC}}, such that both can
-be used interchangeably.
+be used interchangeably. Note that pEp currently only implements the
+{{PGPMIME}} variant, but intends to also implement the {{SMIME}}
+variant.

 The following diagram shows the composition in three stages of a
 message being wrapped, and how the transport relevant header field
@ -937,7 +950,7 @@ EntHdrs
 Content-Disposition)


-The "Container" Entity in the Transport message contains 
+<!-- The "Container" Entity in the Transport message contains  -->


                                              +-"Near" Transport----+
@ -973,7 +986,7 @@ Tunneling is possible with Message Format 2.

 ### pEp Message Formats for Email

-The pEp message formats 1 and 2 are restricted MIME email formats
+The pEp Message Formats 1 and 2 are restricted MIME email formats
 used for running the pEp handshake protocol alongside the incidental
 message exchange. Both formats exist in a plaintext unencrypted form,
 and an encrypted form. A third OpenPGP compatibility format exists,
@ -1007,8 +1020,8 @@ This requires state to be recorded by the MUA, one record for every
 sender identity ever seen on Incoming Messages, which records the
 X-pEp-Version last recevied.

-\[\[ **TODO**: Shouldn't that be the X-pEp-Version per every
-X-EncStatus level (or subset of) to do the right thing on reset? \]\]
+<!-- \[\[ **TODO**: Shouldn't that be the X-pEp-Version per every
+X-EncStatus level (or subset of) to do the right thing on reset? \]\] -->

 <!-- 
 The X-pEp-Version field follows semantic versioning. -->
@ -1027,17 +1040,17 @@ records at all, Format 2 should be used.

 In all other cases, Format 1 should be used. -->

-**Implementation note**: Inconsistent behaviour across current pEp
+**Implementation note**: Inconsistent behaviour across existing pEp
 implementations.



-
+<!-- 
 ### Message Wrapping and Tunneling


 \[\[\ **TODO**: \]\]
-
+ -->



@ -1276,67 +1289,10 @@ attack.

 -->

-### Unencrypted Plaintext Format 2
-
-<!--
-Plaintext
-
-X-pEp-Version: 2.0
-
-multipart/related; charset="UTF-8";
-  multipart/alternative; charset="UTF-8";
-    text/plain; charset="UTF-8" / inline
-    text/html; charset="UTF-8" / inline
-  application/pgp-keys; charset="UTF-8"; name="pEpkey.asc"
-->
-
-~~~~
-    From: John Doe <jdoe@machine.example>
-    To: Mary Smith <mary@example.net>
-    Subject: Example
-    Date: Fri, 30 Jun 2018 09:55:06 +0200
-    Message-ID: <05d0526e-41c4-11e9-8828@pretty.Easy.privacy>
-    X-Pep-Version: 2.0
-    MIME-Version: 1.0
-    Content-Type: multipart/alternative;
-                  boundary="INNER_MESSAGE"
-
-    --INNER_MESSAGE
-    Content-Type: text/plain; charset="utf-8"
-    Content-Transfer-Encoding: quoted-printable
-    Content-Disposition: inline; filename="msg.txt"
-
-    p=E2=89=A1p for Privacy by Default.
-    -- =20
-    Sent from my p=E2=89=A1p for Android.
-
-    --INNER_MESSAGE
-    Content-Type: text/html; charset="utf-8"
-    Content-Transfer-Encoding: quoted-printable
-
-    p=E2=89=A1p for Privacy by Default.<br>
-    -- <br>
-    Sent from my p=E2=89=A1p for Android.<br>
-
-    --INNER_MESSAGE
-    Content-Type: application/pgp-keys
-    Content-Disposition: attachment; filename="pEpkey.asc"
-
-    -----BEGIN PGP PUBLIC KEY BLOCK-----
-    mQINBFQRqIcBEACpsz3mK1zqPdqDlxU6Yws/Xz14LJpszDLlKJckpa7hSc9jfZ4Q
-    j/ES8ndDBftM5mZLzFQ2VatqB9G9cqCgiOVFs6jfTI13nPfLit9IPWRavcVIMdwt
-    Ag7IIk/Gj628hYTdCpNCUc9b1vS6xMAkxJWYgNVwLFS2goikEHCiyzDe
-    =MicJ
-    -----END PGP PUBLIC KEY BLOCK-----
-
-    --OUTER_MESSAGE--
-~~~~
-



-
-#### Inner Message
+### Inner Message

 The pEp message format requires the innermost protected message to follow a
 fixed MIME structure and to consist of exactly one human-readable message which
@ -1356,9 +1312,9 @@ receiving side.



-#### Outer Message
+### Outer Message

-With pEp message format version 2, the pEp standardized message is equally
+With pEp Message Format 2, the pEp standardized message is equally
 wrapped in a message/rfc822 entity, but this time being in turn wrapped in a
 multipart/mixed entity. The purpose of the additional nesting is to allow for
 public keys of the sender to be stored alongside the original message while
@ -1449,7 +1405,7 @@ signed:



-#### Transport Message
+### Transport Message

 In pEp message format 2 the "outer message" consists of a full RFC822 message
 with body and a minimal set of header fields, just those necessary to conform
@ -1504,11 +1460,6 @@ modified to ensure that:



-
-
-
-
-
 ### Content-Type Parameter "forwarded"

 One caveat of the design is that the user interaction with message/rfc822