> 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