[openpgp] Re: Fwd: New Version Notification for draft-gall agher-openpgp-media-types-00.txt
Daniel Kahn Gillmor <[email protected]> Tue, 09 Dec 2025 17:32:24 -0500
| Newsgroups | gmane.ietf.openpgp |
|---|---|
| Message-ID | <[email protected]> |
On Tue 2025-12-09 18:42:14 +0000, Andrew Gallagher wrote:
> IMO we should deprecate the use of `application/octet-stream` in
> PGP/MIME. From my initial experiments, it seems that Apple Mail with the
> GPGTools plugin does not recognise any content-type other than
> `application/octet-stream` for the encrypted part, but Thunderbird will
> happily decrypt such a message without complaint, and Mutt also appears
> to handle it correctly.
You're describing an update to the multipart/encrypted structure of RFC
3156, right?
other tools also explicitly check for application/octet-stream and
decline to treat the message as encrypted if that's the case. Here's
gmime, for example:
https://github.com/jstedfast/gmime/blob/master/gmime/gmime-multipart-encrypted.c#L323
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.
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).
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.
that would also likely take years to reliably deploy, but the time to do
that is now, so that it's ready for wider deployment years from now.
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. 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"?
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?
--dkg
_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc
(application/pgp-signature, 324 B)
-----BEGIN PGP SIGNATURE----- wr0EARYKAG8Fgmk4o3gJEHgLhU7ZwrSWRxQAAAAAAB4AIHNhbHRAbm90YXRpb25z LnNlcXVvaWEtcGdwLm9yZ2f6G4fSbN4N3ew6Im9vsBkUnz607fsV6I7WKu0DPdbc FiEEY6wRjlsuXWbIioWneAuFTtnCtJYAAK9OAP49sLQiWB/Pb3LQ/irS/q3rg6pu ThxpAH2g6zChwmZyiwEAtc5dM1Ooetog5R7kgEcICfRyVH6KbIaFL4M5ApymOwk= =2DhH -----END PGP SIGNATURE-----