[Top] [All Lists]

Re: cleartext signatures - trailing white space - proposal

2004-03-16 10:36:52

On 14 Mar, 2004, at 10:28 AM, Werner Koch wrote:

On Fri, 12 Mar 2004 09:23:44 -0800, Hal Finney said:

After signing this message, I've added a CR and 5 spaces to the above
line, which will obscure the word DON'T on some systems. The signature will still verify if we strip CR with the whitespace, but a superficial
look at the message may produce the wrong impression.

Right.  So better forget about cleartext and only use binary
signatures; then another application is reponsible to take care of
such things ;-)

I think Hal gives a beautiful example of a thing that digital signatures both can and can't solve. If someone signs a message that has in it obscured meaning, it's not the signing program's fault the meaning is obscured.

And yet, a properly verifying signature shows that the signer was up to no good, and whatever the outcome, the perfidy is there for anyone to see.

In the past, we have discussed other semantic attacks where an encrypted and signed message is decrypted and then publicly displayed for all the world to see, possibly to the consternation of the sender. I think that this "attack" is in this case the purest form of justice.

However, this doesn't get us any closer to what we should do.

I think the discussion has drifted away from what *trailing* characters, if any, we should have stripped. Remember, it's only trailing characters we should trim.

It is also interesting to discuss what happens in weird files -- ones that mix different types of line ends, but that's not strictly relevant. Even thought this is adding fuel to a fire I'm trying to squelch, I feel compelled to add in that there are some file systems that are record-oriented. In those a line-end is an out-of band thing. Deciding what a line-end is, and therefore what is trailing is an implementation-specific issue, anyway.

The argument I see against trimming anything <= 0x20 is that it makes it difficult or impossible to sign a file with a form feed or vertical tab. That the RFC/draft itself is such a file is an amusing irony. So there goes that proposal.

Here's another proposal, which I have edited in, and is thus now my default solution:

5.2.1 is made more explicit thus:

   0x01: Signature of a canonical text document.
       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 spaces (0x020) and tabs (0x09) removed.

In 7.1, the confusing and arguably (I have argued this) silly text

   Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
   any line is ignored when the cleartext signature is calculated.

is changed to

   Also, any trailing whitespace -- spaces (0x020) and tabs (0x09) --
   at the end of any line is removed when the cleartext signature is

Should this not be acceptable, here is a more radical suggestion:

How about if I remove any trimming requirments (since this is inconsistently done) and put in an implementation note that says that implementations might want to do text massaging on textmode signatures, and trimming trailing whitespace (for some suitable definition of whitespace) is a reasonable transformation that an implementation might want to do. I'm thinking I'd also put in that there are also other reasonable checks a signer could do, such as checking for overstriking, scanning tags for foreground and background colors being close, deceptive statements such as "This is a verified PGP message" and so on. I think I'll leave out that a complete scanner requires solving the halting problem.

I am happy to entertain even more solutions, especially the one where we just removed any text about trimming or ignoring trailing anything.