ietf-openpgp
[Top] [All Lists]

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

2004-02-11 17:54:22

David Shaw wrote:
I'm not going to be in Seoul, but one thing I think would be good to
be discussed, whether on this list, in Seoul, or both, is the textmode
end-of-line and whitespace issues.


I'd agree that it needs to be tightened up.


This is not a severe interoperability problem by any means, but is an
annoyance that pops up now and again, and I think contributes in a
small way to the poor interoperability reputation that OpenPGP has.


Right.  For many cases, I guess this may be
a nuisance.  For my case, it is critical
functionality, and from time to time, we've
had to re-roll contracts to cope with this,
and/or put in complicated heuristics into
code to verify using multiple methods.

(The preferred path at the moment is to change
the source file such that whitespace is removed,
but that's not really possible for most apps.)



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

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.


Two notes:

a) it would be useful if the whitespace were
clarified to eliminate potential Unicode white
space.

<http://www.imc.org/ietf-openpgp/mail-archive/msg07714.html>

b) it would make some sort of sense, if any
real changes were made, to unify the definition
of whitespace to be the same in both.  But this
is minor, as one would think that we were not
anticipating any functional change to 2440bis
at this stage.


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.


The two implementations that I deal with both implement
2440bis as the (best available) standard.  If 2440 has
to be changed, then a lot of implementations would
have to be as well;  it's long since past that it was
routine to treat the behaviour of pgp as a de facto
standard.  Also, anecdotally, I think gpg has a
pretty significant market share these days, so we
would have to quote what behaviour it follows if
there was to be any change in 2440.


As for me, I don't really have strong feelings for any particular
outcome of this.  What I do care about is that once 2440bis is
published, that it is clear what the "right" way to do things is and
that there will not be questions later.  I don't want it suggested
that the issue wasn't looked at.


I agree.


> Jon Callas pointed out in
> <http://www.imc.org/ietf-openpgp/mail-archive/msg03753.html>,
> ....


I agree with the thrust of this.  Text should be
sent in the interchange format, and signatures
should be immediately verifiable on the data as
delivered.  It does mean that an implementation
should send data with whitespace trimmed, though.
And, that verification MAY try additional trimming
if it hasn't been already trimmed by a non-conforming
signer.

It would be nice to get such explanation into 2440bis.


iang