Re: [openpgp] Put Signature in an Email's Header

[Daniel Kahn Gillmor <[e-mail]>]

Sorry for the long delay in following up on this discussion:

On Wed 2023-08-09 10:32:20 +0200, Kai Engert wrote:
> On 08.08.23 19:09, Andrew Gallagher wrote:
>> I’d be wary of such a double-encapsulation, it feels fragile.
>
> This is what we currently do when combining a signature and protected 
> headers:
>
> multipart/signed (application/pgp-signature)
>      multipart/mixed (protected-headers)
>          headers
>          payload
>      signature data
>
> And the new suggestion is:
>
> multipart/mixed
>      signature-as-a-header
>      multipart/mixed (protected-headers)
>          headers
>          payload
>
> Given that both use two layers around the payload, why do you consider 
> the new suggestion more fragile?

Calling the above two schemes (A) and (B), and assuming that each line
in the schema above is intended to represent a MIME part, i'll observe
that (A) has been tested and shown to be problematic for viewing in some
widely deployed MUAs (Outlook being the most visible).

For this reason, the recommendation that LAMPS has settled on in
https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ for
signed-only messages using the multipart/signed construct is scheme (C):

 multipart/signed (application/pgp-signature)
     payload (protected-headers)
     signature data

That is, there is *no* separate MIME subpart for headers for a
cryptographically protected message, and the headers that are protected
in a signed message can simply be injected onto the payload MIME part
directly.

Sending a test multipart/signed PGP/MIME mesage from Thunderbird 115.2.2
(on debian) i see that the actual result is yet another approach, scheme
(D):

 multipart/signed (application/pgp-signature)
     multipart/mixed (protected-headers)
         payload
     signature data

I don't think there's anything to be gained from (D) over (C).

Scheme (B) (kai's "new suggestion" above) is also problematic, even if
the "signature-as-a-header" is not its own MIME subpart.  It's
problematic because users expect a message to have a single
cryptographic status, which means that the signature is best offered
over the entire message -- and this wrapper looks like it is *not* a
cryptographic envelope at all.  (please see
draft-ietf-lamps-e2e-mail-guidance for discussion of the cryptographic
envelope).

If anyone wants to experiment with the kind of scheme referred to in the
subject line, in particular trying to synchronize with the types of
constraints that are necessary to keep DKIM signatures intact, i don't
think it's a bad idea.  But i don't think you need any alternate MIME
structure to do it.

          --dkg