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

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?

This seems to me to be an argument *to* distinguish these things, not to
leave them ambiguous.

> And as I mentioned earlier, if you're going to split up "pgp messages" 
> into pgp-encrypted-message and pgp-signed-message types, you'd also need 
> types for compressed and literal messages, which are neither encrypted 
> nor signed. In what use cases would the application layer need to make a 
> decision based on these differences?

It depends on what you think the point of OpenPGP is.  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.

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

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 suppose one additional thing to consider is that an OpenPGP-specific
>> Media Type like application/pgp-encrypted-message doesn't necessarily
>> guarantee what the cleartext is once the OpenPGP data is unwrapped. 
>
> I'd consider that a feature! :-)

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.

> I'd say no. Putting the file type of the encrypted data outside the 
> ciphertext as a matter of course is an information leak, and I don't 
> think it should be encouraged in the general case.

This isn't the general case: it's the e-mail case, and the normal
expectation *is* that the cleartext is a MIME object.  Isn't it better
to defend against slapping an encrypted backup into what looks like an
e-mail message and having it treated that way?

> If I have an image/png lying around that happens to be in a 
> password-protected zip file, then the content-type is application/zip 
> and it goes in a file attachment of a multipart/mixed. The content-type 
> of the file contained inside the zip is not mentioned, nor should it be. 
> I think the same should apply to a pgp encrypted file.

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".  I'm *not* asking for the MUA to be able to
see any more details about the encrypted object than that without
decrypting the message itself.

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
   
That is probably orthogonal work to the work you're describing here, but
it might be part of some sort of bundle of additional e-mail
cleaup/integrity work.

        --dkg

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