Subject: [lamps] I-D Action: draft-ietf-lamps-e2e-mail-guidance-01.txt

From: [email-masked]
Date: Mon, 24 Jan 2022 16:36:48 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF.

        Title           : Guidance on End-to-End E-mail Security
        Author          : Daniel Kahn Gillmor
	Filename        : draft-ietf-lamps-e2e-mail-guidance-01.txt
	Pages           : 29
	Date            : 2022-01-24

Abstract:
   End-to-end cryptographic protections for e-mail messages can provide
   useful security.  However, the standards for providing cryptographic
   protection are extremely flexible.  That flexibility can trap users
   and cause surprising failures.  This document offers guidance for
   mail user agent implementers that need to compose or interpret e-mail
   messages with end-to-end cryptographic protection.  It provides a
   useful set of vocabulary as well as suggestions to avoid common
   failures.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-e2e-mail-guidance/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-lamps-e2e-mail-guidance-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-e2e-mail-guidance-01

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 25 Jan 2022 11:54:50 -0500

> 	Filename        : draft-ietf-lamps-e2e-mail-guidance-01.txt

This update mainly adds a bit of text about common ways that MUAs think
about the message's "main body" (the part represented to the user as the
text of the e-mail) and "attachments".  These concepts are useful in
thinking about e2e encrypted messages.

For example, how do cryptographic protections apply to the different
parts if they are wrapped in different cryptographic layers?  the
argument is that the entire message should be under one uniform
cryptographic envelope.

The idea of which parts might be the "main body" part for different
renderers may also be useful in the ongoing header protection work that
Bernie and Alexey and I are working on (more on that soon, hopefully).

From the document's changelog:

-----
### Substantive changes from draft-ietf-...-00 to draft-ietf-...-01

- Added section about distinguishing Main Body Parts and Attachments
- Updated document considerations section, including reference to auto-built editor's copy
-----

Reviews, comments, recommendations, questions, etc more than welcome, as
usual!

  --dkg