I am am much more concerned about the factor
of 2 to 4or more that is the usual improvement in efficiency from
text compression. It seems rather cavalier to simply wave the back of
our hand to such issues.
Text isn't special in this regard, though. Audio gets a 12:1 compression
with MPEG level II audio compression, 24-bit continuous tone photos can
get 100:1 with JPEG, and so on.
Insofar as this is an issue, it's strictly a MIME issue, not a PEM issue.
For example, adding a multipart/compressed body type, for example. PEM should
not get involved in the contents, only the representation. This is precisely
what the MIME/PEM proposal allows. By separating content operations and
cryptographic operations, it allows improvements in eithe. If we hash out
compressed text body types for MIME, MIME/PEM gets to use them automatically.
Now I have somewhat mixed feelings. On the one hand, it seems to me
that if you transfer control from a MIME agent to a PEM agent
for canonicalization and signature, and then back to MIME for
compression, and then back to PEM again for encryption, and then
either PEM or MIME for expansion to a 7 bit format, then this
seems terribly complex. On the other hand, I buy Amada's argument that
the cryptographic operations should be insensitive to the content type.
I view the likely scenario more along the lines of MIME canonicalizes and
formats the data, hands it to PEM for signature and/or encryption, and makes a
multipart out of the result. It's at least as straightforward as current PEM,
and a lot more flexible.
This seems like another case of lowest common denominator. Sure, I
always like to have things for free, but someone invents a
better mousetrap and I have a lot of mice to catch, I'm willing to pay
him for his idea (just as sooner or later, we all work for a living
and would like to continue to get paid).
On the other hand, cost-free reference implementations are a key part of
getting any technology adopted on the Internet. This is, to a large degree,
why PGP is deployed more widely than PEM: people can experiment with it before
they buy, and people on a shoestring can still use the free tool, even if it's
not as slick as the commercial alternatives. PEM is only now starting to get
deployed to any significant degree, thanks to RSA loosening up the
restrictions on RSAREF. I don't want to keep going around with vendors on
this kind of thing for the baseline standard. Extensions, sure. The
baseline, no.
[birthday attack discussion]
Once again, this is not anything special with regard to text. Birthday
attacks are a general problem, not something that can be solved by trying to
canonicalize text. Consider an image, flipping LSBs until the digest matches
another image. Any hashing function will have collisions; the most we can do
is try to minimize the ability to construct them on purpose--this is in my
opinion completely separate from content representation issues.
Things were simpler when messages were printed on one-dimensional
ticker tape.
Well, we could all go back to lemon-juice invisible ink for messages, too :).
Nothing is perfect. I claim that MIME/PEM is, while imperfect, better than
PEM Classic, and of immediate utility. It is for this reason that I am
pushing for it, even if we all agree that it's just a milepost along the way.
OK. But if a signature doesn't mean anything, why are we trying so hard
to affix them to messages?
A signature means that the content one person is looking at is the same as the
content another person signed, to an astronomically high degree of
probability. That's it. Anything else is interpretation of what that content
implies, and is dependent on the context of the signature. These implications
cannot and should not be defined by PEM. PEM is mechanism, not policy (even
X.509, when you get right down to it). Many policies can be built on top of
one mechanism.
With no mechanism, though, policy questions are moot.
I want to nail down the mechanism. That doesn't mean it's all I want to do,
but it's definitely what I want to do *now*, since any further progress
depends on it.
Amanda Walker
InterCon Systems Corporation
PGP Key fingerprint: 594F63C03B52DC4E37E9160DE733CD87
PEM MD5OfPublicKey: 8E4A21B7025943DE2EDC7CC038B3D6B1