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.
http://www.ietf.org/id/draft-moscaritolo-openpgp-literal-00.txt
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.
David