Subject: [openpgp] Another candidate pgp wg item: Media type

From: Tim Bray <[email-masked]>
Date: Mon, 13 Apr 2015 08:06:55 -0700

I submitted this and just remembered because it’s about to expire:
https://tools.ietf.org/html/draft-bray-pgp-message-00

This was motivated by work on an OpenPGP, an Android app, which deals in
PGP messages as chunks of text and uses the built-in Android “share” option
to route them around.  No MIME, no multipart.

It would be nice to be able to specify that the chunk-of-text is a PGP
message to facilitate dispatching to the right software.

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

---

From: Werner Koch <[email-masked]>
Date: Mon, 13 Apr 2015 18:40:12 +0200

> message to facilitate dispatching to the right software.

That is what a Content-Type is used for.  This is part of MIME but also
used by HTTP and other protocols.  No need to invent yet another content
type description.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Dominik Schuermann <[email-masked]>
Date: Mon, 13 Apr 2015 19:24:59 +0200

On 04/13/2015 06:40 PM, Werner Koch wrote:
>> It would be nice to be able to specify that the chunk-of-text is
>> a PGP message to facilitate dispatching to the right software.
> 
> That is what a Content-Type is used for.  This is part of MIME but
> also used by HTTP and other protocols.  No need to invent yet
> another content type description.

The problem here is that Android does not allow to set a Content-Type
when sharing data between applications. A MIME type however is the
most preferred way of indicating the type of data that is being
shared. See
http://developer.android.com/guide/components/intents-filters.html#Examp
leSend

Applications can receive data based on a filter that is defined in
most cases by a MIME type:
http://developer.android.com/guide/components/intents-filters.html#Examp
leFilters

So Android is heavily based on these Intent sharing actions and tries
to get away from a traditional file based OS. So instead of relying on
file endings it would be nice to have a MIME type indicating the content
.

I hope this provides more insight into the interoperability issue we
are facing.

Regards
Dominik

---

From: Werner Koch <[email-masked]>
Date: Tue, 14 Apr 2015 19:04:57 +0200

> most preferred way of indicating the type of data that is being

So what is the problem for an OpenPGP parser to do that on the decrypted
and de-mimed plaintext?  Why inventing another mechanism when we already
have a matured one.

Assume your suggestion is added: Soon after that someone else may
request that license information is important enough that it needs to go
into OpenPGP.  We would end up with our own meta data system.  With MIME
all that is instantly available.

Shalom-Salam,

   Werner

---

From: Dominik Schuermann <[email-masked]>
Date: Tue, 14 Apr 2015 20:59:03 +0200

We somehow talked past each other :D

I will try to explain the problem with a scenario:
1. You encrypt an image with OpenKeychain, so you open OpenKeychain
and go to "encrypt". The way it works in Android is that you now call
a method to open everything with MIME type "image/*". Then all
applications that serve images, like the gallery application pop up
and can be used to open an image.
2. You select the image from one of the apps which then returns the
data stream to OpenKeychain. OpenKeychain encrypts it using a
protected file storage.
3. Now the crucial step: Now this encrypted blob is shared to other
applications. Maybe you want to upload it via Dropbox. You are not
really supposed to save it anywhere on the disk, that's not Android's
model. So what MIME type should now be used to share this encrypted
blob? Following the RFC3156 we use "application/octet-stream" but
that's really unspecific. Recall that we are using no ASCII armor here.

The other way round it gets more problematic.
Consider decryption: You open OpenKeychain and want to decrypt a file.
So you only want to see the apps that serve the PGP-encrypted blobs.
Again, we can only use "application/octet-stream" per RFC, because
there is no specific MIME type for encrypted PGP-blobs.

Regards
Dominik

On 04/14/2015 07:04 PM, Werner Koch wrote:
>> The problem here is that Android does not allow to set a
>> Content-Type when sharing data between applications. A MIME type
>> however is the most preferred way of indicating the type of data
>> that is being
> 
> So what is the problem for an OpenPGP parser to do that on the
> decrypted and de-mimed plaintext?  Why inventing another mechanism
> when we already have a matured one.
> 
> request that license information is important enough that it needs
> to go into OpenPGP.  We would end up with our own meta data system.
> With MIME all that is instantly available.
> 
> 
> Shalom-Salam,
> 
> Werner
>

---

From: Werner Koch <[email-masked]>
Date: Tue, 14 Apr 2015 22:15:15 +0200

> that's really unspecific. Recall that we are using no ASCII armor here.

Okay, so your comments are about PGP/MIME.  I assumed you were talking
about

  5.9.  Literal Data Packet (Tag 11)
     [...]
     - A one-octet field that describes how the data is formatted.

where we discussed to add an 'm' format to describe that the content is
a MIME message.

If you want to indicate that the content is some OpenPGP data you should
use the the MIME types "application/pgp-encrypted" etc. along with the
above suggested format specifier.  You can of course do the same at the
outer level.

What needs to be changed for this?  

Updating PGP/MIME to avoid the required multipart/encrypted container is
a topic we should discuss.

Shalom-Salam,

   Werner

---

From: Dominik Schuermann <[email-masked]>
Date: Tue, 14 Apr 2015 22:43:32 +0200

On 04/14/2015 10:15 PM, Werner Koch wrote:
>> model. So what MIME type should now be used to share this
>> encrypted blob? Following the RFC3156 we use
>> "application/octet-stream" but that's really unspecific. Recall
>> that we are using no ASCII armor here.
> 
> Okay, so your comments are about PGP/MIME.  I assumed you were
> talking about
> 
> 5.9.  Literal Data Packet (Tag 11) [...] - A one-octet field that
> describes how the data is formatted.
> 
> where we discussed to add an 'm' format to describe that the
> content is a MIME message.

Not sure what this has to do with my problem. The Literal Data Packet
indicates the type of the data that is inside the encrypted blob not
the type of the encrypted blob. The Literal Data Packet together with
the actual data is encrypted and can not be accessed before decryption.
But yes, this is another problem for us and adding an "m" format
together with a MIME type would fix this. So +1 for this.

> If you want to indicate that the content is some OpenPGP data you
> should use the the MIME types "application/pgp-encrypted" etc.
> along with the above suggested format specifier.  You can of course
> do the same at the outer level.
> 

Maybe I misunderstand the RFC3156, but "application/pgp-encrypted"
only contains the version number not the encrypted blob. The actual
blob is inside "application/octet-stream".
Where is it specified that "application/pgp-encrypted" can also
directly contain the data? Please point me to the line in the RFC.
I think this comes from the fact that RFC3156 only talks about ASCII
armored data for email transfer.

Regards
Dominik

---

From: Werner Koch <[email-masked]>
Date: Tue, 14 Apr 2015 22:56:30 +0200

> directly contain the data? Please point me to the line in the RFC.

You are right, it is not formally specified:

  MIME media type name: application
  MIME subtype name: pgp-encrypted
  Required parameters: none
  Optional parameters: none
  
  Encoding considerations:
  
     Currently this media type always consists of a single 7bit text
     string.

but I see no strong reason not to use it for amored data unless it is
enclosed by multipart/encrypted.

We could update rfc-3156 to formally define an OpenPGP container or
improve the defintion of this media type.

Salam-Shalom,

   Werner

---

From: Dominik Schuermann <[email-masked]>
Date: Tue, 14 Apr 2015 23:43:36 +0200

On 04/14/2015 10:56 PM, Werner Koch wrote:
> MIME media type name: application MIME subtype name: pgp-encrypted 
> Required parameters: none Optional parameters: none
> 
> Encoding considerations:
> 
> but I see no strong reason not to use it for amored data unless it
> is enclosed by multipart/encrypted.
> 
> We could update rfc-3156 to formally define an OpenPGP container
> or improve the defintion of this media type.

Yes we should do that. Again: We need a MIME type for _non_-armored
data, so if we would use "pgp-encrypted" we would definitely not
follow RFC3156.

I am also not convinced that it is a good idea to use "pgp-encrypted"
for anything other than the version, it would require a parser to
differentiate "pgp-encrypted" with version-only and "pgp-encrypted"
with data.

So I would propose (following Tim Bray): pgp-message as a new MIME
type for data-only.

Regards
Dominik

---

From: Werner Koch <[email-masked]>
Date: Wed, 15 Apr 2015 08:36:20 +0200

> So I would propose (following Tim Bray): pgp-message as a new MIME

To be used for binary OpenPGP data so that standard MIME encoding can be
used?  Not distinguishing between signed and encrypted data is okay
because that avoid conflicts between the MIME type and the actual
OpenPGP message type.

What about keys?  Should they also be allowed in pgp-message?  I tend to
say no.  However 

  7.  Distribution of OpenPGP public keys

   Content-Type: application/pgp-keys
   Required parameters: none
   Optional parameters: none

   A MIME body part of the content type "application/pgp-keys" contains
   ASCII-armored transferable Public Key Packets as defined in [1],
   section 10.1.

which is unfortunate because it requires armored data and thus the
standard MIME encoding can't be used.

Add an "application/pgp-keydata" ?

Along with the removal of the micalg parameter this could be part of
3156bis or another RFC to extend 3156.

Shalom-Salam,

   Werner