MIME structure of encrypted mail and subkeys (was: Memory Hole discussion...)

[Bjarni Runar Einarsson]

Hi Werner!

I like your proposal - moving towards a world where encrypted or signed
messages can be broken up into smaller units is desirable for many
reasons.

The subkey idea is an interesting twist on that, since it allows
different security levels for different parts of the message. It feels a
bit complicated, but it has potential. Very interesting!

Of course, as discussed in April, as soon as the message is broken up
into multiple parts like this, we start to want a summary of some sort
(a manifest), so you know whether you have the entire message or only
part of it. Whether it's 2 parts or 20 parts doesn't matter much, the
problems and solutions are the same: we need a manifest.

This manifest doesn't need to be complicated. It could be something as
simple as a few X-headers in the Memory Hole part, each header
describing an expected MIME part (things like mime-type, filename,
sha256 sum and content-ID for linking).

 - Bjarni


Werner Koch <wk at gnupg.org> wrote:
> On Wed, 24 Jun 2015 15:26, wk at gnupg.org said:
> 
> > whatever you guys use these days) on the client there will be a need for
> > unattended decryption.  This raises the same security concerns as those
> > with Enigmail's auto decryption.
> 
> What about using a second subkey to encrypt the header and the
> "abstract" (top part) of the message?  The bulk of the message would
> then be a different sub-part and encrypted using the standard key.  The
> advantage is that you can auto-decrypt the headers and the "abstract"
> while keeping the bulk encryption key on a secure medium (ie. a slow
> smartcard).
> 
> Right, that would require a more complicated message structure but it
> can also help to solve the mobile IMAP case: If the bulk is not a
> sub-part but a separate second part, you would be able to download the
> first part with the headers and the abstract of the message and display
> that.  Thus there is no need to download a large encrypted message.
> 
>   |--- multipart/mixed
>     |--- multipart/encrypted
>     | |--- application/pgp-encrypted
>     | |--- application/octet-stream [1] [subkey-1]
>     |      (decrypts to)
>     |        |
>     |        |--- multipart/mixed [2]
>     |          |--- text/rfc822-headers inline [correct header]
>     |          |--- text/plain  [abstract]
>     |--- multipart/encrypted
>       |--- application/pgp-encrypted
>       |--- application/octet-stream  [subkey-2]
>            (decrypts to)
>              |
>              |---- text/plain [bulk message] [3]
> 
> text/plain is only an example for any other MIME type.  [3] should have
> a dedicated header with the hash of [1] (or for robustness of [2]) to
> bind the two parts.  It depends on the MUAs on whether they can handle
> this.
> 
> 
> Shalom-Salam,
> 
>    Werner
> 
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

-- 
Sent using Mailpile, Free Software from www.mailpile.is
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP Digital Signature
URL: </pipermail/attachments/20150630/f272c7ec/attachment.sig>