Subject: Re: Let's resolve the end-of-line and whitespace question

From: Ian Grigg <[email-masked]>
Date: Wed, 17 Mar 2004 10:54:14 -0500

David Shaw wrote (back in Feb):
...

> 1) 2440 says of the canonical text signature (sigclass 0x01):
> 
>         The signature is calculated over the text data with its line
> 	endings converted to <CR><LF> and trailing blanks removed.
> 
>    This is different than what every version of PGP though 8 does.
>    These implementations do the <CR><LF> line endings, but do not
>    remove trailing blanks (essentially PGP 2.x behavior).

We've discussed his issue 2) elsewhere.  Issue 1) remains,
if I'm not mistaken.  Any comments?

Myself, I'm minded to say it should be either:

     i.   there should be no trimming, as the binary
          (as opposed to cleartext) signature form
          implies careful handling (mime/zip) and
          thus special care is less needed,

     OR

     ii.  it should be the same as the cleartext
          signature method, for less confusion.

(Unfortunately, both these require a compatibility
change.)

I personally am not fussed, but I concur with David's
original request, that it be nailed down so that we
can move forward and have the implementations match.

iang

---

From: David Shaw <[email-masked]>
Date: Wed, 17 Mar 2004 11:22:06 -0500

On Wed, Mar 17, 2004 at 10:54:14AM -0500, Ian Grigg wrote:

[settling the end-of-line issue for 0x01 signatures]

> (Unfortunately, both these require a compatibility

I'm not sure that the change will hurt compatibility.  Given the way
that PGP and GnuPG handle 0x01 signatures (by including their own
variation of canonicalized text as part of the message), we could pick
either of these with no significant problems.  Note that PGP currently
does (i), and GnuPG currently does (ii), and they manage to
interoperate most of the time.  (Not to say that there aren't other
implementations out there).

I would be perfectly content with either solution, with perhaps a
slight leaning towards (i) due to a desire to not mess with user
supplied input unless we have to.

David

---

From: Ian Grigg <[email-masked]>
Date: Wed, 17 Mar 2004 13:55:08 -0500

> supplied input unless we have to.

Right now, I'm inclined towards (i) myself as
a signing implementation could warn whether
there are trailing spaces, and a verifying
implemetation could try to trim spaces as
a fallback technique.

iang

---

From: David Shaw <[email-masked]>
Date: Tue, 30 Mar 2004 14:25:00 -0500

> David Shaw wrote:

[ i == no trimming whitespace for 0x01 sigs
  ii == trimming whitespace for 0x01 sigs ]

> implemetation could try to trim spaces as

Okay, so here's a proposal.  In section 5.2.1, the text currently
reads:

    0x01: Signature of a canonical text document.
        This means the signer owns it, created it, or certifies that it
        has not been modified.  The signature is calculated over the
        text data with its line endings converted to <CR><LF> and
        trailing spaces (0x020) and tabs (0x09) removed.
 
I suggest:

    0x01: Signature of a canonical text document.
        This means the signer owns it, created it, or certifies that it
        has not been modified.  The signature is calculated over the
        text data with its line endings converted to <CR><LF>.

This is the same as before but trailing whitespace is not removed.

Note that I'm only talking about 0x01 signatures here.  Cleartext
signatures, and the trimming therein, should be unchanged by this.

Rationale: there are good reasons to do whitespace trimming for
cleartext signatures (mail mangling, cut and paste mangling, etc).
These reasons do not apply to an 0x01 signature as it is not cleartext
- it is protected inside the binary or ascii armor shell.  In general,
if we have no good reason to tamper with user supplied input, I think
we should keep hands off.

David