At 11:51 AM +0100 3/31/00, Ian Bell wrote:
The mode of the signature takes into account whitespace and line-end issues.
If you are
using OpenPGP/MIME to sign a zip file (for example), you do it in binary
mode, but you armor the output.
It is a requirement that in PGP/MIME messages the signature is
calculated over the canonicalized and encoded data. By the time you
calculate the signature, the zip file data is base64 with CRLF line
endings. So:
* Is it still possible to use a binary mode signature (I think the
answer is "yes")?
I would think yes. Thomas's comment notwithstanding, if you encrypt and
sign a binary file, you want to use binary mode. If you can't encrypt and
sign a binary file, then PGP/MIME is mostly worthless.
If so,
* Is there any point in using a binary-mode signature over data which by
this point is CRLF-terminated lines of us-ascii characters?
Maybe. It depends on the semantic comment of the file.
* Can this (unnecessary) use of binary-mode lead to
backwards-compatibility problems?
* If there are compatibility problems, shouldn't there be a "SHOULD NOT
use binary mode signatures" in the openPGP/MIME draft?
Consider this to be pretty much the same as text mode VS binary mode in FTP.
If you send a binary file in text mode, you can end up with problems,
depending on what the sender and receiver think constitutes a line end.
This ends up essentially being data corruption and an interoperability
problem. For example, if you send a binary file in text mode from a unix
system to an NT system, then the NT system will replace all 0x10
(pseudo-LFs) with 0x1310 (pseudo-CRLF). If you then pull it back to a unix
system in text mode, this will be undone. But if you transfer it in binary
mode, you have garbage added bytes. If you were really unlucky and you then
got the file in text mode on a Mac, then the 0x1310s will all become 0x13s.
If you send a text file in binary mode, then it might end up on another
system with the wrong flavor of line ends.
Needless to say, if you do this in a signature, this will cause the
signature to not match.
Other interesting forms of corruption are left as an exercise for the
reader. Amuse yourself by looking at all the text on canonicalization.
This isn't a standards problem. This is an implementation/user problem.
It's all related to the very idea of text mode. Arguably, text mode is a
broken concept. However, it's there for a reason, and that reason is that
there's no global agreement on what constitutes text, and that a binary
transfer of text will *also* cause "data corruption."
So, popping back to your questions, no, we have to have binary mode
signatures, or else PGP/MIME can't sign a binary file cross-platform.
If all parties are using the same rules of what text is, then it doesn't
matter what mode you use, as long as you use the same mode. If you want to
cross a text-rule boundary, you have to use the right mode.
Jon