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
- Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)