I went back and looked at a random sampling of the PGP encrypted mails I've received over the last couple of years. 100% of them were multipart: Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; The encryption U/I in my MUA (Kmail) describes what it calls "Inline OpenPGP" as deprecated and has (IIRC) for the almost decade I've been using it. I don't know what larger problem you're trying to solve, but I don't think I'm having it. Making everyone else change to something different "because Android" doesn't seem like a great idea. Personally, I don't carry keys I care about on a phone anyway, so I'm not sure how broad the use case is. Scott K On Monday, October 13, 2014 03:55:40 PM Tim Bray wrote: > I confess to ignorance of the history of PGP and MIME and so on. However, > there is empirically a problem here which the existance of a media type for > an ASCII-armored PGP-encrypted message would be helpful in solving. Let me > provide the narrative. This use-case is Android-specific, but it feels > like an example of a larger problem. > > 1. On Android, there’s this incredibly useful primitive where you can > prepare a thing called an Intent and fire it off at the system saying “send > this to the right software”. The Intent can specify an individual app by > Java classpath, or a specific URI, or a specific action identified by name, > or a specific media type, or various combinations that make sense. Apps > can register with the system saying “I can handle image/jpg” or “I can > handle URIs starting with youtube.com” and so on. An Android user looking > at pretty well any screen usually has a “Share” button, which will arrange > to route whatever they’re looking at appropriately. > > 2. There are a software libraries in many different languages that will > take a plain-text message and from/to keys and emit a PGP message in binary > or ASCII-armored form. For transmission over text-oriented message > channels such as chat apps and webmail, the ASCII-armored form is generally > preferred. Many such channels have no notion of multipart payloads. It is > beneficial for users to be able to use an arbitrary text-oriented messaging > service to carry encrypted payloads. > > 3. There is useful software that does encryption/decryption/key-management, > and would like to be able to register with the system saying “I can help > with PGP messages”. Similarly, it would be nice for someone who gets an > encrypted message to be able to hit a Share button and have the decrypt > software pop up. (It actually does now, because crypto apps register > interest in */*, but then the user has a long list of alternative apps that > also do */*; a more specific media type would be better). > > If there were a media type for ASCII-armored PGP messages, all these pieces > would fit together with a better UX. > > Ned, I think that what you’re arguing is that naked ASCII-armored messages > shouldn’t be used; instead use RFC3156 multipart. Except for, if we can > have a media-type for the naked kind, we can integrate this stuff between > multiple textually-oriented messaging apps immediately, right now, no > waiting. Waiting for the implementors of all these apps to learn the > virtues of multipart and then implement is unattractive, when there’s an > alternative we could use right now. > > On Mon, Oct 13, 2014 at 11:37 AM, Ned Freed <ned.freed@xxxxxxxxxxx> wrote: > > > Back story: There are starting to be a few decent crypto apps, desktop > > > > and > > > > > mobile, that put a pretty face on OpenPGP > > > encrypt/decrypt/verify/key-management. I posted a couple example > > > screencasts in https://www.youtube.com/channel/UCZYI0JHoJCILEegRJsWufXQ > > > > > > On Android, it would make it easier to stitch these things together if > > > there were a way you could ask the system “Here's a PGP message, > > > > identified > > > > > by media type, are there any apps registered to handle that media type?” > > > > > > Typically, everything is ASCII-armored. > > > > > > By PGP message, I mean the bits betweeen > > > -----BEGIN PGP MESSAGE----- > > > and > > > -----END PGP MESSAGE----- > > > > > > RFC 3156 registers application/pgp-encrypted but only as a part of a > > > multipart/encrypted top-level media type, so it wouldn’t be appropriate > > > > to > > > > > use that (I think). > > > > > > So: > > > > > > 1. Am I missing something? > > > > Yes. You appear to be missing RFC 3156, PGP/MIME, where the approach is to > > use > > a multipart/signed wrapper around whatever content you like followed by a > > application/pgp-signature object. > > > > > Is there a media-type suitable for standalone > > > ASCII-armored PGP messages? > > > > What would you propose that media type be? If you make it some random > > application type, clients are likely not to display the content. If you > > make it > > some subtype of text, you might get a better result - or not - but then > > you're > > showing people with unextended clients a bunch of crypto crap. And for all > > I > > know it may well fool existing PGP clients into not looking for embedded > > PGP > > blocks. > > > > The bottom line is that I find your assertion that there are now some > > "decent > > crypto apps" that prefer to use PGP ASCII armor to be more or less > > self-contradictory. > > > > But in any case, at the time this stuff was designed, the sentiment was > > that PGP wanted to have nothing to do with MIME. Which led directly to the > > present state of affairs. > > > > > 2. If not, would it be a sane idea to register such a media type? It > > > > would > > > > > make life easier anywhere that dispatching by media type is used. > > > > > > Assuming this is sane, I’d be happy to cook up a draft. > > > > It takes a lot for me to object to registering a type - I think the value > > of > > having labels for stuff, even stuff like this that I regard as very badly > > designed, outweighs almost everything. > > > > But this is one where I really don't see any value. About the only thing > > such a > > type does is make it possible to avoid having to scan every message > > looking for > > embedded PGP blocks. But it will be many years before PGP usage switches > > to > > this type, assuming it actually deploys, which given past experience it > > most > > likely won't. > > > > And in the meantime you'll still have to support both ASCII armor and RFC > > 3156's multipart/signed format, if for no other reason than RFC 3156 is > > the way > > to go if you want to sign something more complicated than a block of text. > > > > So why not work towards the use of RFC 3156 signatures instead? Especially > > if your goal is to make this stuff more user-friendly. > > > > Ned