Subject: Re: some requests

From: Thomas Roessler <[email-masked]>
Date: Thu, 25 Jan 2001 10:01:45 +0100

Kazu,

> Just in case you misunderstand my opination. I'm not objecting to 7bit
> restriction of Multipart/Security at this time. (Yes, I don't like it
> but the point is not that.) 

> I'm asking not to recommend (ie SHOULD) MIME encoding for "7bit"
> character set. ISO-2022-{JP,KR} is 7bit (not 8bit) and almost all user
> use it as raw (i.e. without base64) in daily life even with MIME UAs.

I'm trying to understand your point, but still have difficulties.
You are basically arguing that

(1) iso-2022-{jp,kr} is a character encoding which can be
    represented in 7bit data,
(2) base64 is the encoding best applied when MIME encodings are used
    at all, and
(3) this will make messages unreadable to most mail user agents used
    in Asia.

Is this correct?

I suppose that your preferred solution would be to mandate
binary-mode signatures, so there is no need to give extra protection
to trailing whitespace.  However, specifying this would mean that
most current implementations don't conform to the spec, unless I'm
severely mistaken.  Florian?

Anyway, we do of course have these two options:

- Break working implementations by mandating binary mode signatures.
- Break MUAs which aren't MIME-aware by requiring the application of
  MIME encodings when they aren't necessary from a pure MIME point
  of view.

What do people think about this?

While we are on it, I think we should restore the section from draft
-01 concerning "From " lines, and move it, so that section 3 would
look like this now (changed line tagged with "!", added lines tagged
with "+"):

------------------------------

3.  Content-Transfer-Encoding restrictions

   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).  Note that
   this also includes the case where a signed object is also encrypted
   (see section 6).  This restriction will increase the likelihood that
   the signature will be valid upon receipt.

!  Additionally, if body parts to be signed contain trailing whitespace,
   implementations SHOULD use either Quoted-Printable or Base64 to
   protect these body parts against corruption by transport or delivery
   agents.  Applying this rule also ensures that trailing whitespace in
   the data encoded cannot be modified without invalidating the
   signature.  Applications SHOULD ensure that no trailing whitespace is
   present after the MIME encoding has been applied.

      Note: Trailing white space does not alter the actual contents of a
      Quoted-Printable or Base64 encoded body part, or the meaning of
      MIME headers. However, the presence of trailing white space may
      trigger a compatibility problem which was introduced in [1]: With
      traditional implementations of PGP, trailing whitespace was
      included with signatures of canonical text documents.  [1] changes
      this behaviour in an incompatible way, by specifying that trailing
      white space is ignored in signatures of canonical text documents.

+     Note: If any line begins with the string "From", it is strongly
+     recommended that Quoted-Printable encoding be applied and that at
+     least one of the characters in the string is encoded using the
+     hexadecimal coding rule.  This is because many mail transfer
+     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.

   Data that is ONLY to be encrypted is allowed to contain 8-bit
   characters and therefore need not be converted to a 7-bit format.

      Implementor's note: It cannot be stressed enough that applications
      using this standard follow MIME's suggestion that you "be
      conservative in what you generate, and liberal in what you
      accept."  In this particular case it means it would be wise for an
      implementation to accept messages with any content-transfer-
      encoding, but restrict generation to the 7-bit format required by
      this memo.  This will allow future compatibility in the event the
      Internet SMTP framework becomes 8-bit friendly.

------------------------------

Cheers,

-- 
Thomas Roessler			    <[email-masked]>

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Fri, 26 Jan 2001 16:19:12 +0900 (JST)

Thomas,

From: Thomas Roessler <[email-masked]>
Subject: Re: some requests

>     represented in 7bit data,

Yes.

> (2) base64 is the encoding best applied when MIME encodings are used

99.999% e-mail communication in Japan is done without any MIME
encoding.  If Japanese HAVE TO chose one of two MIME encodings, 
we chose base64, not quoted-printable.

> (3) this will make messages unreadable to most mail user agents used

Not most. Some.

> severely mistaken.  Florian?

I considered about the binary signature.

- Since RFC 2015 doesn't say about the text/binary signatures, both
  signatures are valid.

- Some implementations (including Mew) are using the binary signatures
  actually.

- Some PGP/MIME implementations on UNIX (and/or Mac?) can't verify the
  binary signatures since they reply on PGP to canonicalize
  line-delimiters.

- But some of them (including exmh if I remember correctly) have
  already fixed this problem.

- I guess that PGP/MIME implementations on Windows don't suffer from
  this problem since its line delimiter is CRLF.

- OpenPGP changed the semantics of the PGP text signature. So, we
  should clarify the binary/text signature stuff.

> +     to distinguish this case, invalidating the signature.

This is worse than the original. Note that ISO-2022-* text can contain
lines which start with "From " since ISO-2022-* is a switching
mechanism for multiple character tables including US-ASCII.

This language is strongly recommending QP to any character sets
including ISO-2022-*, for which QP is not suitable.

And I believe the redundant encoding above should be a user choice,
should not be required by the spec.

--Kazu

---

From: Thomas Roessler <[email-masked]>
Date: Fri, 26 Jan 2001 11:38:15 +0100

> including ISO-2022-*, for which QP is not suitable.

It should be clear from the context that this note does not
recommend quoted-printable when you are using base64 anyways.

> should not be required by the spec.

Now, guess why this is in a Note section, and not in the body of the
text.  But we can even replace "strongly recommended" by
"suggested".

(And no, this won't be in draft-03 which I submitted yesterday.)

---

From: Thomas Roessler <[email-masked]>
Date: Fri, 26 Jan 2001 11:57:14 +0100

Here's the latest text:

  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.