Possible clearsign problem

Tue Sep 14 19:53:39 CEST 1999

I have installed GPG 1.0 on an HP-UX 10.20 system, and been playing with it.
(I used HP's ANSI C compiler and --disable-dynload to build it; I couldn't
get it to work with dynamic loading.)

I've seen a couple of issues when clearsigning text :-

a) When I clearsign text using GPG, and verify it using PGP 5.0 (installed
   on a different machine), the cleartext output by PGP is missing the final
   newline.

   When PGP 5.0 clearsigns text, it appears to add an extra newline before
   the '-----BEGIN PGP SIGNATURE-----' header line, whereas GPG does not
   do this if the last line ends in a newline.  For example :-

   Cleartext (==== delimiter is not part of the cleartext) :-
====
This is a test.
====

   GPG signed output :-
====
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a test.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (HP-UX)
Comment: For info see http://www.gnupg.org

iD8DBQE33tXCXO/Gi/HRVx4RAvjtAKCcx/ELIXJBt7B9FPZwmUbLYJCE5gCfbxI3
SB2xZo8FchHmcpnxOFd9KyQ=
=iAnq
-----END PGP SIGNATURE-----
====

   PGP 5.0 signed output :-
====
-----BEGIN PGP SIGNED MESSAGE-----

This is a test.

And when PGP 5.0 verifies the signed text, it then strips off the additional
line it inserted, restoring the cleartext to the orginal value.

The result is that cleartext signed by GPG is output by PGP 5.0 without the
final newline.

b) If I have cleartext which does not have a newline on the last line, and
   clearsign it with GPG, GPG _does_ add a newline before the
   "-----BEGIN PGP SIGNATURE-----" header line.

   But when it verifies the signature, it does not strip the newline back off -
   thus the cleartext it outputs is not the same as the cleartext it was
   given in the first place...

The two problems appear to be related.  I would say that (b) is a definite
bug - what comes out should be the same as what goes in when clearsigning.

Having looked at the section 7 of RFC2440, it could be argued that GPG does
follow the spec, but the text is rather ambiguous :-

>The cleartext signed message consists of: 
>
>   The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a single line, 
>   One or more "Hash" Armor Headers, 
>   [GnuPg: An optional "NotDashEscaped" Armor Header.] 
>   Exactly one empty line not included into the message digest, 
>   The dash-escaped cleartext that is included into the message digest, 
>   The ASCII armored signature(s) including the
>   '-----BEGIN PGP SIGNATURE-----' Armor Header and Armor Tail Lines. 
...
>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. 

It could also be argued that if the newline before the
'-----BEGIN PGP SIGNATURE-----' line is not considered part of the signed
text, then PGP 5.0 is correct in not outputting it.  And thus is correct in
adding an extra newline when it signs the text, so it can be removed later
and leave the original cleartext as-is...

So the question is whether GPG or PGP 5.0 is compliant with the RFC ?

If GPG is compliant, then it still has a problem with case (b), because it
adds a newline when signing and then does not remove it subsequently.  (Yet
it must add a newline, because the '-----BEGIN PGP SIGNATURE-----' must be
on a line of it's own, yes ?)

If PGP is compliant, then modifying GPG to always add a newline when signing,
and always remove a newline when subsequently outputting, should fix problem
(b) (provided it doesn't add a second newline !) and make it compatible with
the RFC as well...

Either way, it would be a good idea to modify the RFC to make it clear which
of the two cases applies :-
 i) A newline is supposed to be added and subsequently removed
ii) The cleartext is to be unchanged, but the final newline is to be gnored
    purely for the purposes of calculating the signature.  (In which case
    you need to specify how to cope with the case when the cleartext does not
    end in a newline.)

Cheers, Bob
-- 
Bob Luckin      bob at ti.com      "Coder, adapt.  FTP Ada, redo C"