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

Hi, Daniel.

On 09/12/2025 22:32, Daniel Kahn Gillmor wrote:
> 
> It would be relatively easy to relax that check, but yikes making sure
> the updated variant gets widely deployed -- we're talking many years, i
> suspect.

Almost certainly. :-(

> As for the replacement, i think application/pgp-message casts too wide a
> net.  I think whether the message is encrypted or not should be part of
> the media type, so i'd distinguish between on the one hand:
> 
>      Content-Type: application/pgp-encrypted-message
> 
> (which might happen to also be signed internally), and on the other
> hand, something like application/pgp-signed-message.
> application/pgp-signed-message would presumably not used in e-mail at
> all, presumably, since signed-only messages are better handled by
> draft-ietf-mailmaint-unobtrusive-signatures).

Right, so the distinction isn't strictly required in the email use case. 
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?

> That said, if you're going to make changes to the ungainly
> multipart/encrypted MIME structure, why not replace that whole
> pointless/messy/duplicative MIME structure in the first place?  A
> top-level Content-Type header of application/pgp-encrypted-message seems
> sufficient to me, and could even do away with the OpenPGP ASCII armor,
> in favor of the simpler, standardized Content-Transfer-Encoding: base64.

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.

> 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! :-)

> In
> RFC 3156, the clear expectation is that what is inside the message forms
> the content of a new message/rfc822 object.
> 
> Do we need a different MIME type for "encrypted message that when you
> unwrap it will itself be a MIME object" than for "encrypted message that
> could be anything when unwrapped"?

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. In the email case, we 
can already distinguish the "encrypted message" vs "encrypted file 
attachment" scenarios by the multipart/encrypted vs multipart/mixed 
container formats - but email is already very leaky so this is not a 
significant extra problem. What added benefit would a new content-type 
provide?

> For example, say i have an image/png lying around that happens to be
> OpenPGP-encrypted, and i want to send it as an attachment in an
> otherwise cleartext message.  what should the Content-Type of that
> attachment be?

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.

A

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