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

[Andrew Gallagher <[e-mail]>]

On 6 Dec 2024, at 21:25, Kai Engert <[e-mail]> wrote:
> 
> 
> (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.)

Correct.

> 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?

We could, but that wouldn’t stop naive clients from displaying it. We’d have to refuse to process the message at all if this condition were violated. We’d also need to be careful about how to define “empty” in a fault-tolerant way.

Alternatively we could display both parts, but render the second part separately to make it clear that it is not signed over, to prevent a new efail vector.

That said, this would still only close off one such attack vector. So long as we support multipart/alternative an attacker will always be able to create invisible salamanders.

> 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=="

I worry about duplicating the algorithm info in both the micalg parameter and the embedded signature packet, so if we were to do this I’d use a generic micalg value. But also, adding a novel parameter to multipart/signed would require an update to RFC1847 as well. I haven’t tested whether this would cause any actual issues in practice, but I think it would be safer to be conservative unless there’s a compelling reason to define a new parameter.

A