On Wed, 10 May 2000, Thomas Roessler <roessler(_at_)guug(_dot_)de> wrote:
Does anyone see a reason why we should not start getting
the OpenPGP/MIME and multipart/mixed signature drafts into
the RFC process?
Should the issue of binary versus text-mode signatures be addressed?
RFC1847 had the design objective of aiding single-pass signature
verification. To that end, it defined the micalg paramater so that the
client could pre-calculate the hash over the MIME data.
RFC2015 and RFC2015bis clients know what hash is required for the
signature, but they don't know what data has actually been hashed. The
line endings will always be CRLF because of the MIME canonicalization,
but trailing spaces may or may not be included in the hash depending on
the signature mode.
Possible improvements to openPGP/MIME could therefore be:
1) Simply state the problem, and indicate that for one-pass processing,
two hashes will have to be prepared - one for binary-mode signatures
and one for text-mode signatures.
2) Mandate which form of signature must be used. Trailing spaces are
often significant in email/news (sig-seps, RFC2646), so a binary-mode
signature might seem preferable. However, existing PGP/MIME clients
may be using either.
3) Define a "pgp-mode" parameter, pgp-mode=binary or pgp-mode=text and
ensure that new clients add the parameter to the multipart/signed
header. If the parameter is missing (RFC2015 messages), then one-pass
clients will have to prepare two hashes.
I feel that 3) is the most satisfactory fix to the problem, but that at
least 1) is incorporated into the draft before it is sent to last call.
--
Ian Bell T U R N P I K E Ltd