[openpgp] Re: Fwd: New Version Notification for draft-gall agher-openpgp-media-types-00.txt

Hi, Daniel!

On 10/12/2025 20:17, Daniel Kahn Gillmor wrote:
> On Tue 2025-12-09 23:36:30 +0000, Andrew Gallagher wrote:
>> Right, so the distinction isn't strictly required in the email use
>> case.
> 
> Really?  Or are you saying this because the only sensible way to sign a
> message is with unobtrusive signatures, and there would never be any
> reason to put anything other than an encrypted message in its own MIME
> part?

I'm saying there is no spec for putting anything other than an encrypted 
message inside a multipart/encrypted container, so the (claimed) 
content-type of the encrypted part adds no new information.

Obtrusive signed messages use multipart/signed, not multipart/encrypted, 
so can already be distinguished at the application layer.

> I certainly
> wouldn't want a compressed-only (or worse, a literal-only) pgp message
> to be considered acceptable content for an e-mail message that otherwise
> appears to be encrypted.

Neither would I - but as I said, the multipart/encrypted container 
already requires that the content is an encrypted message. If receiving 
implementations don't test for this already, a content-type header won't 
force them to.

>> While this would be simpler at the implementation level, I'm not
>> convinced it would add any user-facing benefits - and giving up MIME
>> entirely might cause new problems with legacy systems.
> 
> But the proposal to change the Content-Type subpart for RFC3156
> encrypted messages already causes problems with legacy systems.

Some disruption will be unavoidable, but I'm trying to minimise the 
extra problems created. I fear that dispensing with RFC1847 structure 
will add additional problems on top of the unavoidable ones...

> Anyway, i'm not talking about giving up MIME entirely.  I'm talking
> about simplifying an external MIME structure while actually committing
> to MIME more explicitly for the internal structure.

I do like this idea in the abstract, and if we were doing encrypted mail 
again from scratch we would probably do something like this instead of 
RFC1847 - but it would be a *much* bigger project.

> It's a feature that Alice can take (for example) a text file she knows
> is encrypted to Bob, and coerce Bob to decrypt it and treat its contents
> as a message/822 object?
> 
> I mean, that is the state of play today, but it seems unwise.

Distinct content-types don't prevent it though, because Alice can claim 
any content-type she likes in the cleartext part.

> I agree -- i'm talking about a MUA being able to distinguish between
> "this is an encrypted MIME tree" and "this is encrypted but is not
> (necessarily) a MIME tree". 

If it is a direct child part of a multipart/encrypted part then it is a 
MIME tree, otherwise it might not be. An MUA already has all the 
information it needs.

> It occurs to me that to fix this problem safely, we might actually need
> something cryptographically strong in the OpenPGP layer itself, not just
> in the MIME layer.
> 
> To try to establish what the desired API and semantics would be, I've
> recorded this observation over at:
> 
>     https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/142

I agree, context separation would be the only way to enforce it. Perhaps 
we should separate the threads at this point...?

A

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]