[openpgp] Re: Proposal for update to RFC3156 (PGP/MIME)

[Kai Engert <[e-mail]>]

Hi Andrew,

On 28.11.24 18:59, Andrew Gallagher wrote:
> We have previously discussed the possibility of updating RFC3156 to support v6 signatures. One particular concern is how to add the salt to the MIME header, but there is also the (long-standing) question of how to make PGP/MIME messages render more elegantly in naive clients (i.e. without displaying an unknown attachment).

thanks, I'm interested in a solution that avoids rendering an unknown 
attachment in naive clients.


> It occurred to me that since the `micalg` parameter in the `Content-type: multipart/signed` specification is fully protocol-specific, we can choose to put anything we want in there. And the easiest way to make it version-agnostic is to replace the digest algorithm name with an armored OpenPGP packet.
> 
> If we used an OPS packet, ...

As I understand it, this approach wouldn't avoid the "unknown attachment".

(When using an OPS packet, I assume you'd still have to deliver a 
trailing packet with the actual signature data in the second MIME sub part.)


> Alternatively, we could place the *signature* packet in the headers:
> ...
> The trailing signature MIME part is then redundant, however the multipart/signed spec requires one. So by analogy with multipart/encrypted we could add a fake “inline signature” MIME part, that PGP-aware MUAs could handle gracefully:

I understand this approach is your suggestion for suppressing the 
unknown attachment.

By using text/plain as the content-type of the second MIME sub part, you 
assume that naive clients will render it as inline text, not as an 
attachment.

That's a great idea.

I'm concerned this could potentially be used by a malicious sender to 
craft messages that intentionally display a different message to 
recipients based on the software they are using, with the intention to 
trick them.

To avoid that, could we require that the text/plain part must be empty?


> Daniel Huigens and I have tested by roundtripping both these constructions through postfix, Gmail and Protonmail -- they survived intact, and also displayed prettily. I haven’t tested whether a PQC-sized prefix signature header would survive such a roundtrip today, however support for such large headers would surely have to be implemented for ARC and DKIM signatures at some point. The OPS construction has the advantage that it will definitely work with PQC now, and the prefix construction has the advantage that it is pretty. Both have the advantage that the micalg parameter and the two MIME parts could be concatenated and streamed directly into the OpenPGP library with minimal pre-processing by the MUA.

Thanks Andrew and Daniel for your testing, the "pretty" rendering of the 
prefix construction sounds promising.

Do you think it's necessary for broad compatibility to use the modified 
micalg parameter as you suggested, or could the signature packet 
alternative be placed in a separate attribute of the content-type header 
like this?

Content-Type: multipart/signed;
  boundary="12345678”;
  protocol="application/pgp-signature”;
  micalg=pgp-sha256;
  signature-data="
   wpgGARsKAAAAKQWCY5ijYyIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6
   2azJAAAAAGk2IHZJX1AhiJD39eLuPBgiUU9wUA9VHYblySHkBONKU/usJ9BvuAqo
   /FvLFuGWMbKAdA+epq7V4HOtAPlBWmU8QOd6aud+aSunHQaaEJ+iTFjP2OMW0KBr
   NK2ay45cX1IVAQ=="

Thanks
Kai