Ben Laurie wrote:
" Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
the end of any line is removed when the cleartext signature is
Does this mean they should not be included in the signature, or also
that they should be stripped from the dash-escaped text?
They should not be included in the signature
calculations. It is an open question as to
whether they should stripped from the text or
not, up to each application. I would; but
Jon has posted on good reasons why it is not
the job of the application to change the doc
that is being processed (signed).
I suppose the above text could change "generated"
to "calculated" to make it clearer? That is, if
my interpretation is the consensus.
" 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."
Does this mean that one should insert an extra <CR><LF> before the
terminating line? I notice that at least some implementations do not.
No, there is no need to insert anything, just
not include the <CR><LF> that must preceed the
'-----' line in the signature calculation. In
this case I would say that there definately
should not be an extra line ending inserted,
as that is changing the document in a way that
is not reversable.
This is an artifact of the old days where
optimisations were cute, and it was I suppose
considered smart to save on calculating over the
last newline. It is particularly dumb, because
everything else about the job is line based,
but this is an exception with no value other
than creating an exception and thus annoying
the coders. None that I ever heard, leastways.
But there was a discussion about it a long time
ago, and no consensus to fix it up, so we are
stuck with the exception.