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