[Webfunds-devel] ouch

Wed, 15 Sep 1999 12:11:29 -0400 (AST)

The following may effect our definition of the canonical hash,
as we may want emulate this bastardisation.  Also, watch out
for this in the signature checking code!  It doesn't matter
so much for the x509 code as we want to deprecate that just
as soon as we've got pgp code going.

In other news, the canonical hash is dead anyway,
the calculation is wrong in every file that had
trailing whitespace :(

I've rewritten the contact code completely, and have
fixed the above, and I'm introducing a version number
into the local file, so that I can change the hash
calculation method over time.

iang

>From owner-ietf-open-pgp@imc.org Wed Sep 15 03:35:34 1999
Date: Wed, 15 Sep 1999 08:57:06 +0200
From: Werner Koch <wk@isil.d.shuttle.de>
To: ietf-open-pgp@imc.org
Subject: dash-escaped text (7.1)

Hi,

there is a ambiguity in the definition of cleartext signature:

|7.1. Dash-Escaped Text
| [....]
|   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 is not clear whether this line ending is has to be added by the
creation process and later to be removed or whether it simply does
not go into the calculation of the hash.

The problem with this is, what to do when we have to encode a message

 a) of size 0
 b) without a trailing line ending

I agree that both cases are rare but case b) happens from time to
time.  Solutions for this are:

 a) A header line telling something about the orignal text when this
    text has one of the above problems.
    Advantage:  Compatibility to existing implementions
    Disadvantage: A extra header line in a few cases and special code
                  to handle these cases.

 b) Add the text to the RFC:
    "A newline is supposed to be added and subsequently removed".
    Advantage:  Very easy and clear definition.
    Disadvantage:  Not compatible to existing implemantations

 c) Add a RFC version number as header line and use b)
    Advantage:  Easy
    Disadvantage:  Still need the extra code for OpenPGP 1.0 and
                   makes all signatures larger.

For compatibilty reasons I would prefer solution a)

What do you think?

   Werner

--
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013