MIME structure of encrypted mail and subkeys

[Bjarni Runar Einarsson]

Werner Koch <wk at gnupg.org> wrote:
> > 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,
> 
> This would inhibit one-pass processing.

Is this a real concern or a theoretical one? Do any production libraries
actually support one-pass PGP/MIME in practice? The APIs I have worked
with certainly didn't - they all buffered things up into objects.

I know it can be done (I've done similar things with MIME), but it
requires your MIME parser/generator be written in a very specific way
which is much more complicated than most developers want to deal with.
Most devs these days are used to dealing with objects, not streams.

As soon as you're buffering everything anyway, making one-pass
processing a design constraint buys you nothing but complexity.

> What about a boolean flag manifest-in-next-part and have the Manifest in
> that next part?  With such a chain of Manifests you can read the message
> MIME part by part and verify up to the part you have read:
> 
>   Last-part: HASH, more=yes|no

What if my mobile phone e-mail reader just wants to pull a part out of
the middle? Or just display a list of parts without downloading them?

I think this strategy becomes functionally equivalent to just putting
everything in one big PGP/MIME blob as before. See below for a different
approach.

> This requires only limited amount of look-ahead while composing a
> message.

I don't think this is actually a real constraint in the real world
anymore.  These days we measure RAM in GBs and storage in TBs, while
e-mail SMTP servers still commonly reject e-mail over 20MB in size.
Message size just isn't a computational constraint the way it used to
be.

But, even if it were, then you could just put your manifest at the end,
possibly with a hint in the header saying you planned to do (this is not
a security-critical feature, so an in-the-clear header is fine).

Cheers!
 - Bjarni

-- 
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/f8930960/attachment.sig>