Subject: Media type for PGP message?

From: Tim Bray <[email-masked]>
Date: Mon, 13 Oct 2014 10:24:08 -0700

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

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? Is there a media-type suitable for standalone
ASCII-armored PGP messages?
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.

---

From: [email-masked]
Date: Mon, 13 Oct 2014 11:37:36 -0700 (PDT)

> -----BEGIN PGP MESSAGE-----
> and
> -----END PGP MESSAGE-----

> 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

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.

> 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

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 14 Oct 2014 00:12:02 +0200

> if your goal is to make this stuff more user-friendly.

I support this -- 3156, for all its warts, alleged or true, is implemented
in a few MUAs and works. FSVO works, but nothing else comes even close
today.

Mutt, my MUA, had a hell of grokking the first post; because the data
between the PGP markers was quite far from parseable as cryptotext. It
does that dreaded scanning, compared to which 3156 is elegant.

Regards, 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Now I'm concentrating on a specific tank battle toward the end of World War II!

---

From: Tim Bray <[email-masked]>
Date: Mon, 13 Oct 2014 15:55:40 -0700

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.

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 13 Oct 2014 20:25:58 -0400

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:
> > > Back story: There are starting to be a few decent crypto apps, desktop
> > 
> > and
> > 
> > > there were a way you could ask the system “Here's a PGP message,
> > 
> > identified
> > 
> > > multipart/encrypted top-level media type, so it wouldn’t be appropriate
> > 
> > to
> > 
> > > use that (I think).
> > > 
> > > So:
> > > 
> > > 2. If not, would it be a sane idea to register such a media type?  It
> > 
> > would
> >

---

From: "John Levine" <[email-masked]>
Date: 14 Oct 2014 00:58:00 -0000

>received over the last couple of years.  100% of them were multipart:

You might want to check stuff that's PGP signed.  In my experience, the
majority is still ASCII armored, not MIME.

R's,
John

---

From: Tim Bray <[email-masked]>
Date: Mon, 13 Oct 2014 18:32:10 -0700

As I noted, there are many text-centric messaging channels that are in
wide use but are not in any sense email.

Um, I’m suggesting registering a media type for a message format that is:

- specified in a standards-track RFC (See RFC4880, sections 2.4 and 6)
- widely supported in software in a variety of programming languages
(references on request)
- currently being used in deployed apps (once again, see
https://www.youtube.com/channel/UCZYI0JHoJCILEegRJsWufXQ)

Media types are supposed to be useful for dispatching payloads in
well-known formats to the appropriate software modules.  Why is this
controversial?

Anyhow, this discussion has revealed that there apparently isn’t a
registered media-type for this purpose, so I’ll write a draft and
we’ll have something concrete to argue about.

On Mon, Oct 13, 2014 at 5:58 PM, John Levine <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAlQ8dSoACgkQkEiFRdeC/kUYkQCfeGeIH7jsz5JiWRFSSPgSKZZu
> 9lgAniY4RINAwBKJH9/4V4X/MIGnAkPi
> =q6OX
> -----END PGP SIGNATURE-----
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Oct 2014 21:35:56 -0400

--On Monday, 13 October, 2014 20:25 -0400 Scott Kitterman
<[email-masked]> wrote:

> 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:
> 

Interesting.  We must be seeing different communities.  Very
subjectively, I'd guess that about half of the PGP encrypted
(whether signed or not) and almost all of the
signed-but-not-encrypted messages are in ASCII armored form, not
multipart/encrypted.  I have speculations about the reasons for
both, but the bottom line in:

-- multipart/encrypted isn't as successful as we had expected

-- The ASCII armor format which, IIR, predates
multipart/encryption and may make up part of the reason for
Ned's observation that the PGP community didn't like MIME very
much, is still alive an well.

Ned is obviously correct -- ASCII armor doesn't do a thing for
complex, structured, messages while multipart/encrypted was
designed to handle them and does. But that fact has never
eliminated the cases in which the message payload is a singe,
text-style, body part and standalone PGP processors can created
a signed and/or encrypted block of text that is then pasted into
(really instead of) a conventional message.

   john

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 13 Oct 2014 23:15:26 -0400

> (really instead of) a conventional message.

Virtually everyone I'm getting encrypted/signed mail from is running Linux or 
some other Unix like operating system and using GnuPG.  That may account for 
why I see what I see.  I did go back and look at a few signed mails and they 
are multipart as well:

Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-
signature"; boundary="..."
Content-Disposition: inline
....

Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

...

Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Description: Digital signature

YMMV, of course, but from where I sit at least it seems to be ~all one way.

Scott K

---

From: t.p. <[email-masked]>
Date: Tue, 14 Oct 2014 12:01:47 +0100

----- Original Message -----
From: "Scott Kitterman" <[email-masked]>
To: "IETF-Discussion Discussion" <[email-masked]>
Sent: Tuesday, October 14, 2014 4:15 AM
> why I see what I see.  I did go back and look at a few signed mails
and they

I agree on the multipart/signed but also see

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:33.0) Gecko/20100101 Thunderbird/33.0

or

X-Mailer: Apple Mail (2.1878.6)

or the tell tale

Content-Type: multipart/signed;
 boundary="Apple-Mail=_37F6A3569C-4B34-48C7-8721-BF783436929";
 protocol="application/pgp-signature"; micalg=pgp-sha1

which look like other communities.

Tom Petch

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 14 Oct 2014 14:11:46 +0200

> which look like other communities.

That's (samples #2 / #3) GPGMail frantically keeping up with Apple's
incompatible ABI/API changes in Mail.app. Mostly the same people but on
a BSD UNIX that can show .ppt ;-)

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Are you still an ALCOHOLIC?

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 14 Oct 2014 18:32:34 +0200

On Tue 14/Oct/2014 00:55:40 +0200 Tim Bray wrote: 

> 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.

Among the "virtues of multipart", one is to be content-agnostic, so
that it is not necessarily text what gets delivered upon decription/
verification.  Another one is to be wrappable in turn, allowing
possible misinterpretations as unsigned footers are appended to signed
stuff.

Would it be worth having a generic template for generating media types
for simplified containers which have a single leaf of a given type?

For example, both article.txt.gz and signed_picture.png.asc look like
monopart something.  Would it be enough to say "text+gzip" and
"image+pgp-signature" for monopart subtypes?

Just wondering
Ale

---

From: Tim Bray <[email-masked]>
Date: Thu, 16 Oct 2014 13:51:31 -0700

A new version of I-D, draft-bray-pgp-message-00.txt
has been successfully submitted by Tim Bray and posted to the
IETF repository.

Name:           draft-bray-pgp-message
Revision:       00
Title:          The OpenPGP Message Format
Document date:  2014-10-16
Group:          Individual Submission
Pages:          6
URL:
http://www.ietf.org/internet-drafts/draft-bray-pgp-message-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bray-pgp-message/
Htmlized:       http://tools.ietf.org/html/draft-bray-pgp-message-00

“Real” HTML: https://www.tbray.org/tmp/draft-bray-pgp-message-00.html

Abstract:
   RFC 4880 specifies the encoding for encrypted OpenPGP messages.  This
   document registers an Internet Media Type for these messages.

---

From: t.p. <[email-masked]>
Date: Fri, 17 Oct 2014 09:22:39 +0100

Tim

I realise that the Applications Area is redundant and will soon be
exterminated, but, perhaps, it just might linger on long enough to
provide a home for a discussion of a new media type:-); the apps-discuss
list could just do.

Tom Petch

----- Original Message -----
From: "Tim Bray" <[email-masked]>
To: "John Levine" <[email-masked]>
Cc: "scott" <[email-masked]>; "IETF-Discussion Discussion"
<[email-masked]>
Sent: Thursday, October 16, 2014 9:51 PM
Subject: Re: Media type for PGP message?

Abstract:

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Oct 2014 10:49:17 -0400

t.p. <[email-masked]> wrote:
    > provide a home for a discussion of a new media type:-); the
    > apps-discuss list could just do.

Tom, that's exactly the opposite of what the IESG said.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tim Bray <[email-masked]>
Date: Fri, 17 Oct 2014 08:10:27 -0700

I’m actually a little out of touch with the drill on a media-type
registration daft.  Does it need a WG?

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Oct 2014 16:14:38 +0100

> registration daft.  Does it need a WG?
No (it can even be an Informational document on Independent Stream), 
although ask Barry and Pete for their preference.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Oct 2014 11:56:32 -0400

> registration daft.  Does it need a WG?

AFAIK, it doesn't.
And the App area isn't going away, so even if it needed a WG, I'm sure there
is a place for it.

---

From: S Moonesamy <[email-masked]>
Date: Sun, 19 Oct 2014 16:28:47 -0700

Hi Tim,
At 08:10 17-10-2014, Tim Bray wrote:
>I'm actually a little out of touch with the drill on a media-type

The short answer is no.

You could send the registration request (RFC 6838) to 
https://www.ietf.org/mailman/listinfo/media-types and run the draft 
through [email-masked] if you are aiming for a RFC.  I suggest 
contacting one of the Application Area Directors for the process details.

Regards,
S. Moonesamy