Re: Media type for PGP message?

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(_dot_)freed(_at_)mrochek(_dot_)com> 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