ietf-openpgp
[Top] [All Lists]

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

2004-02-20 15:54:49

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).


I'm happy to consider this a bug, myself, if consensus says that's what the behavior should be. This is probably a case where there's code in there that was written by either Derek or Peter Gutmann and no one's changed it since then. :-)


2) 2440 says of the cleartext signature:

        Also, any trailing whitespace (spaces, and tabs, 0x09) at the
        end of any line is ignored when the cleartext signature is
        calculated.

   Again, PGP through 8 implements this differently than 2440 says,
   where trailing spaces are removed, but trailing tabs are not
   (again, PGP 2.x behavior).

I've seen comments that these details were inadvertent errors in 2440
that would have or should have been fixed, and requests to the WG the
change these two details in 2440bis to match the historical PGP
behavior (after all, PGP 5 predates 2440 and there is a huge installed
base of PGP 5-8).  I've also seen comments that the WG mustn't change
the published standard this many years after the fact to match
behavior already declared noncompliant.

No, this is not an inadvertent error. It was an intentional change.

PGP 5 did predate 2440 and there are a number of small changes between its behavior and what's in 2440. Moreover, this version is now seven years old and has not been supported in so long that I can't even remember how long it has been unsupported. It is not 2440-compliant, can't be because it predated 2440, is not supported by its producer, and really isn't germane to any discussion of 2440. Please stop bringing it up. It's dead. Thank you, I feel much better now.

The 2440 change in text signatures (adding in whitespace trimming) was one of a number of small things there that were debated as to what the right thing should be, rather than what went before. There are many good reasons for removing trailing whitespace at the end of anything that's text mode. It's the sort of thing that gets mangled easily and undetectably, as well as a covert channel. (I come from an era in which is was common practice for text editors to trim trailing whitespace when saving a file, and consider it a feature rather than a bug.)

However, I'd be perfectly happy to settle it once and for all by saying only normalize line ends, even. We can just not worry about the whitespace. In short, if the consensus here is that however well-meaning that change was, it was a bad idea, it's easy to fix. I can see that Unicode issues might turn this into a swamp in ways that just trimming spaces and tabs isn't.

Jon Callas pointed out in...

I'll repeat a broader opinion I have on this. I think that text mode should be an assurance that the signed data is in a particular format, so that it can be handled accurately, not a commentary on how to canonicalize.

The reasons I think this is a good idea are that it be an assurance include:

* If it's just an assurance, then you verify a signature the same way for text mode and binary mode. This is better for the code in a lot of ways.

* If it's just an assurance, and the assurance is wrong (because of bugs or incompatibilities), then you end up with a good signature over data that isn't exactly in the format you wanted. This is a much better failure mode than getting good data, but not knowing how to verify the data. It's a fail-soft situation.

        Jon