On Thu, 30 Mar 2000, Jon Callas <jon(_at_)callas(_dot_)org> wrote:
At 11:09 AM +0100 3/30/00, Ian Bell wrote:
2. PGP data formats
PGP can generate either ASCII armor (described in [3]) or 8-bit
binary output when encrypting data, generating a digital signature,
or extracting public key data. The ASCII armor output is the
REQUIRED method for data transfer.
So binary-mode signatures are forbidden, and remain so in the new draft.
I don't think so.
There are two issues here -- the "mode" of the signature and the format of
the output.
I realize that now from Thomas' reply!
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")?
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?
* 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?
Turnpike is not an openPGP client (we use the PGP sdk itself for our
cryptographic operations) - hence there may be more things here that I
have overlooked. My interest in openPGP primarily concerns
interoperability and new extensions (like the multiple signature draft).
--
Ian Bell T U R N P I K E Ltd