On Tue, 20 Dec 1994 Jueneman(_at_)gte(_dot_)com wrote:
Therefore, the appropriate sequence of steps should be:
[...]
Just as an aside, PGP does compression before encryption using the zip
algorithm. As Ned pointed out, different compression schemes are needed
for different kinds of documents. The reason JPEG compresses real-life
images better than the Lempel-Ziv based GIF is because JPEG uses an
algorithm tailor-made for real-life images. In the process JPEG loses
some detail, but not enough that a human would notice or even care.
Even MIME/PEM doesn't care because it signs the compressed data, not
the original pixels.
The one type that compression would be very useful for is text, but I note
that most text e-mail messages are quite small (a few k in length). So the
gains through compression would not really be worth it, especially on modern
high speed modems. As Ned said, the MIME working group has thought about
compression in the past but has lacked the time and the volunteers to do it.
Rest assured though that when the MIME working group gets around to it,
no change would be necessary to the MIME/PEM spec. Changes will be needed
to MIME/PEM implementations, but only at the MIME level, not at the PEM
level. The "pain" of upgrading MIME/PEM implementations will pale into
insignificance compared to the pain of upgrading all of the straight MIME
implementations. PEM will be the least of our worries!
With regard to the canonicalization problem, there is much more to
canonicalization than just the ASCII/EBCDIC and CR/LF issues.
Um ... you have a broader definition of canonicalization than the one used
in MIME circles. To the MIME working group, it refers to a standard form
for representing the content of messages which is independent of the
line ending weirdnesses of particular systems. Except for text types where
line ending issues are very important, MIME doesn't say anything about
"this thing is semantically equivalent to that thing".
Once we get outside the straight RFC822 environment, then the issue of foreign
alphabets arises. Even within the Roman alphabets, how do we handle the
relatively simple case of umlauts, s-zet, c-cadilla, n-tildes, etc?
MIME has extensive support for labelling character sets. In fact, this was
one of the main reasons MIME was invented in the first place. I suggest you
go and read the MIME RFC's. It explains all these issues (and more) and the
reasons for them. By using MIME, PEM is getting all of these things
"for free" and doesn't need to define its own mechanisms.
Assuming that the purpose of canonicalization is to ensure that the same
results, i.e., the same semantic content, will be implied by a signature
across various platforms, then I think we have to at least stop and think
a bit about what the semantic content of a complex MIME object really IS,
and what we are implying when we sign it.
MIME says nothing about the semantic content of messages, and neither should
MIME/PEM. Semantics is something for the users to argue about. MIME/PEM
provides a way to get an arbitrary structured document from point A to
point B together with a signature that says "the bits that went in point A
are the same as the bits that came out at point B". Any other interpretation
of those bits and the signature on them is up to the user.
Cheers,
Rhys.
--
Rhys Weatherley, Queensland University of Technology, Brisbane, Australia.
E-mail: rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au "net.maturity is knowing
when NOT to followup"