files with different md5, but signature checks out ok?
Thu Nov 22 00:37:01 2001
-----BEGIN PGP SIGNED MESSAGE-----
On Monday 19 November 2001 15:08, Andreas Hasenack wrote:
> The only difference between these two files is that one has lines
> terminating with CR/LF, and the other uses standard unix format (only
> LF or CR at the end, can't remember which one right now).
> So, gpg seems to be ignoring these termination issues. How does it
> know this is a text file? How can it be sure?
In the signature there is a bit which indicates if the signature was
calculated in binary mode or in text mode (treats all line endings as
CR/LF). So it has to be specified during signature creation if the data
is text or binary data.
> This raises another question for me. Some MTAs mangle the messages,
> converting them to/from 8bit, for example, and other things. This can
> potentially corrupt signed messages, right?
Not if you sign the message _before_ it's encoded for transport.
But the right way to do it would be to follow RFC 2015 (resp. its
successor RFC 3156):
Multipart/signed and multipart/encrypted are to be treated by agents
as opaque, meaning that the data is not to be altered in any way .
However, many existing mail gateways will detect if the next hop does
not support MIME or 8-bit data and perform conversion to either
Quoted-Printable or Base64. This presents serious problems for
multipart/signed, in particular, where the signature is invalidated
when such an operation occurs. For this reason all data signed
according to this protocol MUST be constrained to 7 bits (8- bit data
should be encoded using either Quoted-Printable or Base64). Note
that this also includes the case where a signed object is also
encrypted (see section 6). This restriction will increase the
likelihood that the signature will be valid upon receipt.
Unfortunately signatures will still break if some buggy MTA
automatically converts messages from Quoted-Printable to 8bit.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----