Subject: [openpgp] Tag indicating a MIME content

From: Werner Koch <[email-masked]>
Date: Thu, 07 Jul 2016 10:14:17 +0200

Hi,

I recall that an indication for a MIME content has been proposed many
years ago but might have been forgotten.  Thus I propose this small
change for 4880bis:

--8<---------------cut here---------------start------------->8---
diff --git a/middle.mkd b/middle.mkd
index 033f11f..5519be3 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -2156,7 +2156,8 @@ ## {5.9} Literal Data Packet (Tag 11)
     may need line ends converted to local form, or other text-mode
     changes.  The tag 'u' (0x75) means the same as 't', but also
     indicates that implementation believes that the literal data
-    contains UTF-8 text.
+    contains UTF-8 text.  If it is a 'm' (0x6d), then it contains a
+    MIME message body part [](#RFC2045).
 
     Early versions of PGP also defined a value of 'l' as a 'local'
     mode for machine-local conversions.  RFC 1991 [](#RFC1991)
--8<---------------cut here---------------end--------------->8---

MIME has several advantages: Interpretation of the plaintext can be done
without considering the context (e.g. part of a PGP/MIME message or
standalone).  The encoding of the message can be described without
resorting to the unprotected armor header.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 7 Jul 2016 12:35:06 +0200

I support this.

Nitpick, should this be "an" rather than "a" m?

 - V

Werner Koch([email-masked])@Thu, Jul 07, 2016 at 10:14:17AM +0200:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

---

From: Wyllys Ingersoll <[email-masked]>
Date: Thu, 7 Jul 2016 09:15:29 -0400

+1 on the "m" proposal.

-Wyllys Ingersoll

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 07 Jul 2016 10:35:17 -0400

> resorting to the unprotected armor header.

<nohats>

I support this proposal.

Should we also be deprecating 't' in favor of 'u' now that UTF-8 support
is ubiquitous, and charset munging can be problematic?

   --dkg

---

From: Derek Atkins <[email-masked]>
Date: Thu, 07 Jul 2016 10:50:32 -0400

Hi,

+1 on this proposal, but in response to Vincent I would propose that we
just remove the article completely, so it reads:

  ...  If it is 'm' (0x6d), then ....

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Jon Callas <[email-masked]>
Date: Thu, 07 Jul 2016 12:12:56 -0700

+1 on the proposal.

I'd even go further with what I think DKG is saying that "text mode" is something that OpenPGP carries as baggage back from the FTP days when you had "text" (that could even be six bit or worse, like RAD50) versus "binary." Dump as much of that as is reasonable, please.

	Jon

---

From: David Shaw <[email-masked]>
Date: Thu, 7 Jul 2016 21:26:34 -0400

> On Jul 7, 2016, at 4:14 AM, Werner Koch <[email-masked]> wrote:
> 
> Hi,
> 

I am in favor of this (I vaguely recall when it was originally suggested).  I do have one suggestion though - this field (like the literal packet filename and timestamp) isn't covered by a signature, so can be changed invisibly in transit.  That's not news, but I think it might be worth calling that out explicitly to avoid future surprise.

Perhaps something like "Note that the formatting octet, the file name, and the date field of the literal packet are not included in a signature hash and thus are not protected against tampering in a signed document."

David

---

From: David Shaw <[email-masked]>
Date: Thu, 7 Jul 2016 21:32:22 -0400

> 
> On Jul 7, 2016, at 6:35 AM, Vincent Breitmoser <[email-masked]> wrote:
> 
> I support this.
> 

+1 on the nitpick.  It should be "an", as "m" starts with a vowel sound.

David

---

From: Werner Koch <[email-masked]>
Date: Fri, 08 Jul 2016 08:46:37 +0200

On Fri,  8 Jul 2016 03:26, [email-masked] said:

> Perhaps something like "Note that the formatting octet, the file name,
> and the date field of the literal packet are not included in a
> signature hash and thus are not protected against tampering in a
> signed document."

Thanks for the reminder.  I'll create a issue for this.

Salam-Shalom,

   Werner