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

[Bart Butler <[e-mail]>]

Hi dkg,

I think the point of B (where IIRC the outer layer was supposed to be multipart/signed and to denote the cryptographic envelope) was to try to avoid all the signature.asc and other useless invented files floating around by formatting the signature as a MIME header rather than a MIME part which unaware MUAs/MTAs do not know how to process and end up rendering as files. If it breaks Outlook though that is of course a large and maybe fatal problem.

The point of the encapsulation was to avoid all the complexity that arises from mixing signature headers with the headers it signs, such as occurs with DKIM.

The LAMPS recommendation is essentially the PGP/MIME status quo, right, where signature data is a separate MIME part and we get all the existing artifacts?

I agree that D serves no purpose.

-Bart

------- Original Message -------
On Thursday, October 19th, 2023 at 8:42 PM, Daniel Kahn Gillmor <[e-mail]> wrote:


> 

> 

> 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
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp