Re: MIME media type literal packet in OpenPGP

David Shaw <> Fri, 11 March 2011 19:49 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p2BJnLeG041530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2011 12:49:21 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p2BJnL2G041529; Fri, 11 Mar 2011 12:49:21 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.4/8.14.3) with ESMTP id p2BJnIEN041524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Fri, 11 Mar 2011 12:49:19 -0700 (MST) (envelope-from
Received: from ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id p2BJnFZP022884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Mar 2011 14:49:17 -0500
Subject: Re: MIME media type literal packet in OpenPGP
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: David Shaw <>
In-Reply-To: <>
Date: Fri, 11 Mar 2011 14:49:15 -0500
Cc: IETF OpenPGP Working Group <>
Message-Id: <>
References: <>
To: Vinnie Moscaritolo <>
X-Mailer: Apple Mail (2.1082)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by id p2BJnJEM041525
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

On Mar 11, 2011, at 1:39 PM, Vinnie Moscaritolo wrote:

> * PGP Signed: 03/11/2011 at 10:39:52 AM
> Greating;
> I just posted an informational draft about some minor changes that the PGP sdk
> is now supporting.   comments and complaints are welcome.
> be kind, this is my first time doing this.

This looks reasonable enough to me.

I'd add a note to the Security Considerations section that when using this method on a signed document, the MIME type is changeable without invalidating the signature (since the signature hash does not cover the literal packet metadata).  This could allow an attacker to force a particular content handler to run (say, by changing text/plain to image/jpeg).  When encrypting (or signing+encrypting) the MDC helps you here, but for a signed (only) document, there is an opening for mischief.

Also, a minor typo:

   By providing more information beyond the existing binary and text
   formats this extension and can enable the automated selection of an
   appropriate media viewer for the decoded content.

"...and can enable..." should probably be "...can enable...".

I like this bit:

   o  The MIME media type MAY have an OPTIONAL null byte termination.
      Any data that follows such a null byte should be discarded and not
      considered part of the MIME media type.

That effectively leaves open a possibility of having a third (hopefully small) string in that field, which may be useful someday.

Implementation-wise, there is a minor gotcha here as GPG actually allows nulls in the filename.  By default, GPG ignores the filename field, but there is an option (--use-embedded-filename) which tells GPG to actually use that field for the filename, and it will interpret a null as a literal "\0" (i.e. backslash plus zero).  I wouldn't worry terribly much about it, but if this draft is adopted we'll have to update GPG to handle it.