A few days ago an issue arose on a cryptography mailing list about
a failing PGP signature on a software package being distributed.
The problem was traced to the fact that the signature was in text mode
on this binary package. However it raises some issues in the OpenPGP
spec treatment of text mode signatures.
Section 5.2.1 of RFC2440 describes the processing for signatures on text
documents as "The signature is calculated over the text data with its
line endings converted to <CR><LF> and trailing blanks removed."
There are two problems with this.
The first is that it does not make clear what constitutes line endings.
In PGP we treat CR LF, CR, and LF all as line endings and convert each
one to CR LF. Each of these is used as a line ending on one of the
architectures we support; CR LF on Windows, CR on Macintosh, and LF on
Unix. We don't restrict the conversion to just native line endings for
two reasons. First, in a true text document you will have only native
line endings so supporting the others will have no harmful effects; and
second, sometimes you run into text documents with non-native line endings
(because they were transferred in binary mode from another architecture)
and by transforming those line endings as well you increase the chances
of verifying a signature correctly.
I recommend that we specify this canonicalization rule.
The second issue relates to removing trailing blanks. This is an error in
the spec, as was pointed out by Ulf M=F6ller less than a month before RFC
2440 issued. Unfortunately in the busy time before the RFC this comment
was overlooked and the spec issued with this error. No version of PGP has
ever removed trailing blanks in canonicalizing a text document. (They are
ignored for *clearsigned* text documents, but that is another matter.)
This issue has caused problems for people from time to time since the RFC
has issued. I recommend that we solve the problem by changing the spec
to conform to how PGP has always worked. We should eliminate the words
"and trailing blanks removed" from the section above.
Comments?
Hal Finney
Network Associates