GnuPG and trailing whitespace handling

[Russ Allbery]

Werner Koch <wk at isil.d.shuttle.de> writes:

> See RFC2440:

>    5.2.1. Signature Types

Aha!  That's where it is.  I was looking through RFC 2440 trying to find
this, but I was looking in the definition of text sections, the armoring
sections, and so forth.

>    0x01: Signature of a canonical text document.
>          Typically, 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 blanks removed.

I can verify that PGP 2.6.2 and PGP 5.0 do *not* do this for detached
signatures.  I and several other people went through a lot of debugging
with the first version of my PGP::Sign module when I switched to using
detached signatures rather than munging attached documents and suddenly
pgpverify stopped being able to verify signatures generated with PGP::Sign
for Usenet control messages (pgpverify munges the document and the
signature into a signed document with an attached signature and verifies
that).

After all of that, I wanted to make sure of what I was seeing, so I even
added this to PGP::Sign's test suite.  I take some test data without
trailing whitespace and generate a signature for it.  I then verify that
the signature is valid (this passes with PGP and GnuPG).

Then I munge the data by adding a trailing blank to every line, and the
signature generated on the unmunged data is checked against the munged
data with PGP.  PGP 2.6.2 and PGP 5.0 report bad signatures.  GnuPG
reports a good signature.

We first ran into this with that bane of all PGP implementations, sig
separator lines.

> I noticed one problem: the RFC talks about "trailing blanks" and
> "trailing whitespace" - maybe this is the reason for the problem.

Well, I'm specifically adding spaces, so unless they're interpreting
spaces as meaning something completely different....

And to repeat for the record, this isn't just PGP 2.6.2.  This is also PGP
5.0 (the US version; I don't know if the international version is
different).

It sounds to me like your implementation is correct according to the RFC,
and I think it's a considerably saner way of handling things anyway.  I
just wanted to run that particular note by people here before I put it
into documentation so that you're aware of the incompatibility and I get
caught if I made any stupid mistakes or just missed documentation.  :)

-- 
Russ Allbery (rra at stanford.edu)         <URL:http://www.eyrie.org/~eagle/>