Hal,
The point is that when PGP/MIME was created with PGP 2.x (RFC1991),
the PGP/MIME canonicalization was such that it didn't matter which
type-byte you used; the hash would be the same. The problem is that
OpenPGP (RFC2440) changes the definition of a text signature (please
excuse me for not quoting the exact type-byte value).
Because of this change, it is possible to create a text-signature with
OpenPGP that will fail with PGP 2.x (and vise-versa). The major
difference is that RFC2440 specifies that you do not hash trailing
white-space (whereas in RFC1991 trailing white space was included in
the hash).
So here is the problem. PGP/MIME specifies text canonicalization to
make binary and text signatures hash into the same value for RFC1991
signatures. However, this is not the same for RFC2440 signatures.
The problem is that implementations want to be able to hash the
message in a single-pass, before they read the signature type-byte
from the signature. Moreover, implementations want to hash the
message only once.
So, how do we maintain compatibility of PGP/MIME between RFC1991 and
RFC2440 versions of PGP, while maintaining the pre-hash, single-pass
processing? As have been argued, there are a few ways to do this:
a) specify a canonicalization and require binary sigs.
Unfortunately this invalidates a number of implementations
that currently use text sigs.
b) specify a canonicalization that matches text and allow
either binary or text sigs. Unfortunately this has the
problem that RFC1991 and RFC2440 have different ideas of
what should be included in a text-mode signature.
c) Change the PGP/MIME canonicalization requirements to match
RFC2440 text-mode. This has the effect that previous
messages (and probably many implementations) wont be
PGP/MIME compliant.
I don't know what the best way is.
-derek
hal(_at_)finney(_dot_)org writes:
There is something I'm still missing.
The signature block at the bottom of the PGP/MIME signed message has
a signature type byte in it, text vs binary. Is it your assumption
that the value in this type byte should control the hashing of the
textual data which is earlier in the message?
I don't know if this has to be true, but it may be helpful for
implementations if it is true.
In that case there are two possibilities. One is to mandate the value
in this type byte, and thereby mandate the hashing which is done in the
message. Receivers would hash the message data according to the spec,
and then when they came to the type byte, they could either ignore it
or check it and complain if it is the wrong value.
The second possibility is to allow either value in this type byte, and
thereby require that the receiver read the signature before it goes back
and hashes the data (or else hash the data both ways).
Are these the alternatives as you see them?
Hal
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord(_at_)MIT(_dot_)EDU PGP key available