Subject: I-D ACTION:draft-ietf-openpgp-mime-06.txt

From: [email-masked]
Date: Wed, 11 Apr 2001 07:01:16 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: MIME Security with OpenPGP
	Author(s)	: M. Elkins, D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-mime-06.txt
	Pages		: 13
	Date		: 10-Apr-01
	
This document describes how the OpenPGP Message Format [1] can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC1847 [2].
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[email-masked]> with
the single word 'subscribe' in the subject.  An archive of the
working group's list is located at <http://www.imc.org/ietf-openpgp>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-06.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-mime-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-mime-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: John W Noerenberg II <[email-masked]>
Date: Wed, 11 Apr 2001 10:22:23 -0700

>	Filename	: draft-ietf-openpgp-mime-06.txt

I have requested Jeff and Marcus review -06, and submit it to the 
IESG for promotion to Proposed Standard as soon as possible.  Thanks 
to everyone for your contributions to this!  Thanks especially to the 
editors who have worked diligently to get it to this point.  We'll 
have congratulations all around when the draft gets its RFC number.

Forgive my US-centric quote, but all the time I spend on PGP I think 
about what PGP means to everyone on the net, in the US and elsewhere. 
Dr. Lessig's observations about privacy and freedom of speech are 
never far from my mind.

best,
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   Two hundred years after the framers ratified the Constitution, the
   Net has taught us what the First Amendment really means.
   -- Lawrence Lessig, "Code And Other Laws of Cyberspace", 1999
   ----------------------------------------------------------------------

---

From: Florian Weimer <[email-masked]>
Date: 14 Apr 2001 01:33:53 +0200

> 	Filename	: draft-ietf-openpgp-mime-06.txt

I know it's too late know, but while reviewing the current USEFOR
draft, I discovered that the explanation

|   Multipart/signed and multipart/encrypted are to be treated by agents
|   as opaque, meaning that the data is not to be altered in any way [2],
|   [7]. However, many existing mail gateways will detect if the next hop
|   does not support MIME or 8-bit data and perform conversion to either
|   Quoted-Printable or Base64.  This presents serious problems for
|   multipart/signed, in particular, where the signature is invalidated
|   when such an operation occurs.  For this reason all data signed
|   according to this protocol MUST be constrained to 7 bits (8-bit data
|   MUST be encoded using either Quoted-Printable or Base64).

of the 7 bit constraint fails to mention the binary/text mode
signature interoperability problem which can only be addressed if
there aren't any 8-bit characters.

(USEFOR currently overrides the analogous requirement in RFC 2015.)

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

---

From: Thomas Roessler <[email-masked]>
Date: Sat, 14 Apr 2001 09:55:29 +0200

On 2001-04-14 01:33:53 +0200, Florian Weimer wrote:

>>   Multipart/signed and multipart/encrypted are to be treated by
>>   agents as opaque, meaning that the data is not to be altered
>>   in any way [2], [7]. However, many existing mail gateways
>>   will detect if the next hop does not support MIME or 8-bit
>>   data and perform conversion to either Quoted-Printable or
>>   Base64.  This presents serious problems for multipart/signed,
>>   in particular, where the signature is invalidated when such
>>   an operation occurs.  For this reason all data signed
>>   according to this protocol MUST be constrained to 7 bits
>>   (8-bit data MUST be encoded using either Quoted-Printable or
>>   Base64).

> there aren't any 8-bit characters.

Eh?  It may be because I didn't have any coffee so far, but somehow,
I don't understand what you are trying to say here.  

The text/binary mode interop problem is related to trailing
whitespace.  It is not related to the presence or absence 8bit
characters.  The next section basically says that, and makes
suggestions on how to fix things:

   Additionally, implementations MUST make sure that no trailing
   whitespace is present after the MIME encoding has been applied.
   
   Note: In most cases, trailing whitespace can either be removed,
   or protected by applying an appropriate
   content-transfer-encoding. However, special care must be taken
   when any header lines - either in MIME entity headers, or in
   embedded RFC 822 headers - are present which only consist of
   whitespace: Such lines must be removed entirely, since replacing
   them by empty lines would turn them into header delimiters, and
   change the semantics of the message.  The restrictions on
   whitespace are necessary in order to make the hash calculated
   invariant under the text and binary mode signature mechanisms
   provided by OpenPGP [1].  Also, they help to avoid compatibility
   problems with PGP implementations which predate the OpenPGP
   specification.

   Note: If any line begins with the string "From ", it is strongly
   suggested that either the Quoted-Printable or Base64 MIME
   encoding be applied.  If Quoted-Printable is used, at least one
   of the characters in the string should be encoded using the
   hexadecimal coding rule.  This is because many mail transfer and
   delivery agents treat "From " (the word "from" followed
   immediately by a space character) as the start of a new message
   and thus insert a right angle-bracket (>) in front of any line
   beginning with "From " to distinguish this case, invalidating the
   signature.
	    
Of course, implementations are free to find other
standards-compliant ways of protecting whitespace - however, I doubt
they'll find such ways.

> (USEFOR currently overrides the analogous requirement in RFC 2015.)

I hope you're joking.  Could you please send the relevant sections
from the latest usefor draft to this list?

-- 
Thomas Roessler			    <[email-masked]>

---

From: Florian Weimer <[email-masked]>
Date: 15 Apr 2001 19:12:22 +0200

Thomas Roessler <[email-masked]> writes:

> characters.

OpenPGP textmode signatures are not very well-defined.  First of all,
OpenPGP requires text to be encoded in UTF-8, a requirement which is
hardly followed in practice.  In addition, there are at least four
Unicode characters relating to line endings: U+000A, U+000D, U+0085
(NEXT LINE or NEL, somehow related to ISO 6429), U+2028 (LINE
SEPARATOR, native to the Unicode standard).  Especially U+0085 could
be considered as a line terminator by some implementations which are
closely related to an EBCDIC environment (AFAIK, this control
character is used to represent a line-terminating EBCDIC control
character when using one of the bijective EBCDIC <-> ISO 8859 maps).

So 8-bit data signed by a text-mode signature should not include the
following octets: 0x0a, 0x0d, 0x85 (ISO 8859 represenation of NEL),
the octet sequence 0xc2 0x85 (UTF-8 representation of NEL), and the
octet sequence 0xe2 0x80 0xa8, which is the UTF-8 representation of
the LINE SEPERATOR character.  This does not include any legacy ;-)
East-Asia encodings (which might be used instead of UTF-8 for encoding
the signed text), and overlong UTF-8 sequences (which are not
permitted in theory, but implementations might disagree).

Given these problems, I think it's not wise to assume that text-mode
signatures are binary-transparent in any way.

> I hope you're joking.

No, I'm afraid. :-/

> Could you please send the relevant sections from the latest usefor
> draft to this list?

I think you've already found them.  I've raised this issue as well on
the list, hopefully it is addressed properly.