Clearsigning (again)

brian moore bem@cmc.net
Thu, 25 May 2000 14:39:15 -0700


I know there is very little in the RFC regarding clearsigning and that
PGP-MIME is better.  But Network Solutions wants clearsigned (and so do
many Usenet readers since multipart MIME is evil on Usenet), so I need
it to work properly.


>From the fine man page:
-t, --textmode Use canonical text mode. If -t (but not --textmode) is used together with armoring and signing, this enables clearsigned messages. This kludge is needed for PGP compatibility; normally you would use --sign or --clearsign to selected the type of the signature. But this doesn't wholly work. [thorin:~] 2:10:46pm 193 % echo foo | gpg -t --armor --sign You need a passphrase to unlock the secret key for user: "brian moore <bem@cmc.net>" 1024-bit DSA key, ID 88322B51, created 1998-10-17 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 foo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5LZbaN3/OJIgyK1ERAm/3AJ99ETFfFOvIS+necd4awNO5S255EACghazh p9oyByxGr6xctlsQTU7C4zk= =myQV -----END PGP SIGNATURE----- The problem is that with PGP, the same sort of thing will have an empty line after the 'foo'. PGP5 will verify the above, but it will be missing the end of line: [thorin:~] 2:12:53pm 200 % ls -l foo -rw------- 1 bem bem 3 May 25 14:12 foo [thorin:~] 2:12:56pm 201 % od -x foo 0000000 6f66 006f 0000003 The trailing newline placed there by 'echo foo' (which emits 4 characters) is gone. Again, I realize that RFC2440 isn't clear at all about 'clearsigned' messages but I believe interoperability is important. How does the above behave with PGP6? If it behaves as PGP5 does, then I think gnupg needs to change. The relevant wording in 2440 I see is: 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. That seems to imply "insert an extra newline here when signing and discard it when you verify". There is also a problem in lines ending with TAB (which, alas, I know because NSI seems to send forms with TABs at the end of the line for reasons known only to them): [thorin:~] 2:15:13pm 211 % echo "foo " > foo # that's a tab [thorin:~] 2:15:14pm 212 % gpg -t --armor --sign foo You need a passphrase to unlock the secret key for user: "brian moore <bem@cmc.net>" 1024-bit DSA key, ID 88322B51, created 1998-10-17 [thorin:~] 2:15:25pm 213 % pgpv foo.asc Opening file "foo" type text. BAD signature made 2000-05-25 21:15 GMT by key: 1024 bits, Key ID 88322B51, Created 1998-10-17 "brian moore <bem@cmc.net>" "brian moore <bem@thorin.cmc.net>" "brian moore <bem@news.cmc.net>" This seems to be contrary to RFC2440: Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. Spaces at the end of the line -are- ignored correctly. But tabs are not. If there's consensus that these two things need fixing, I'll submit a patch, but so far I've had no response to these even being problems. :( Again, both of these are needed to work with Network Solutions, which is why it's annoying me. If I manually ":%s/^I$//", and insert a blank line at the end of my forms, yes, I can then submit them to NSI and have them verify, but that seems goofy. -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves.