Re: cleartext signatures - trailing white space - proposal

[Werner Koch <wk@xxxxxxxxx>]

On Thu, 11 Mar 2004 20:40:56 -0500, Ian Grigg said:

>      Also, any trailing whitespace (characters <= 0x20) at the

Please don't define whitespace this way.  I know software using
control characters to separate fields (e.g. STX (0x02) or FS (0x1c))
in a line. Ignoring them in a signature (at the end of a line) might
very well change the content of the message (even if those fields are
empty).  

SPACE, LF, CR and TAB are the whitespace characters we have always
used in PGP and so should it be - that is also what most
programmers[1] understand under whitespace (cf. K&R).  VT and FF would
also belong to them, but given that we did not used them in PGP, I's
feel better not to add them now.

> Note 1.  I'd like "space" defined as a 0x20 to remove the possibility
> of Unicode spaces.

Agreed.

> Note 4.  And, to clarify Unicode, I suggest adding:


>      No exception for Unicode whitespace is defined,
>      and all Unicode characters SHOULD NOT be ignored.

With a list of white space caracters along with their encoding values,
we won't need that.

> 7.2. Canonical Line Endings

>      As with binary signatures on text documents, a cleartext signature
>      is calculated on the text using canonical <CR><LF> line endings.
>      The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
>      SIGNATURE-----' line that terminates the signed text is not
>      considered part of the signed text.

>      Also, any trailing whitespace (characters <= 0x20) at the
>      end of any line is ignored when the cleartext signature is
>      calculated.  No exception for Unicode whitespace is defined,
>      and all Unicode characters SHOULD NOT be ignored.

     Also, any trailing whitespace (the characters <SPACE> (0x20),
     <TAB> (0x09), <CR> (0x0D) and <LF> (0x0A)) at the end of any line
     is removed and replaced by the sequence <CR><LF> for the purpose
     of cleartext signature calculation.


  Werner


[1] Well, speaking of C programmers; don't know about Java.