Memory Hole protected e-mail headers

[Daiki Ueno]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

>  https://modernpgp.org/memoryhole/
>  https://github.com/ModernPGP/memoryhole/
>
> If you're an implementor of a Mail User Agent (MUA) that handles or
> generates OpenPGP-signed or -encrypted messages, we want to make sure
> this makes sense to you.

As I will eventually implement it in Emacs (Gnus), I would like to
clarify a point: is it just meant to be a guideline, or aiming at an
amendment to RFC 3156?

If it is the former, it makes sense to reuse the valid MIME structure.
However, the implementation could be complicated, as it basically means
to add an exception based on the message structure.

On the other hand, if it is possible to revise RFC 3156, perhaps we
could have a simpler message structure, something like:

    |--- multipart/signed
      |--- text/plain
      |--- application/pgp-signature
      |--- application/octet-stream (signed rfc822-headers)

or:

    |--- multipart/encrypted
      |--- application/pgp-encrypted
      |--- application/octet-stream
      |--- application/octet-stream (encrypted rfc822-headers)

where the rfc822-headers part is appended to the message as an optional
3rd part.  This is an incompatible change, but I suppose this doesn't
break most of existing MUAs, as long as they only look at the first two
parts.  Also, like Werner's idea[1], it allows IMAP MUAs to retrieve the
metadata part (the 3rd part) independently of the main part.  That would
be useful for generating a summary.

There are, of course, some drawbacks:

- the 3rd part cannot be verified/decrypted with existing MUAs
- the 3rd part must be securely associated with the 2nd part, to prevent
  the entire message structure from being crafted by attackers

Regards,

Footnotes: 
[1]  https://lists.gnupg.org/pipermail/gnupg-devel/2015-June/030078.html

-- 
Daiki Ueno