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
generated.
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.
Jon