I think that, while your concerns are valid, storage efficiency is a tertiary
criterion at best. Communications channels continue to grow in speed, as do
mass storage capacities. Disk space, for example, is currently proceeding to
drop below fifty cents a megabyte (I just bought a 527MB drive for $249 plus
tax). In this context, I think that the 33% expansion brought about by radix
64 encoding is a relatively small cost. I do not think that mandating
compression (especially with algorithms that may be patented) is worth the
additional layers of complexity, and additional time required to process
messages.
Also, remember that text is not the only content type we want to be able to
sign and/or encrypt. Keeping the cryptographic operations separate from the
content-related operations is a good thing, in my opinion.
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?
Unicode UTF-7 is an already existing canonical form for multilingual text.
It handles this perfectly easily in MIME already.
For example, what is the canonical form of a PostScript file? Are
the definitions of all of the fonts supposed to be included?
I think you are confusing documents in a philosophical sense with particular
instantiations of those documents. Signatures apply to particular instances
(just as they do on paper), as does encryption. Trying to reduce an arbitrary
document to an ideal Platonic form before performing cryptographic operations
is an impossibility. Interpretation of the content is the user's job, not the
cryptosystem's.
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.
I do not believe that the purpose of canonicalization is to ensure
the semantic content, since semantic content cannot be represented directly.
Canonicalization is simply a transport-independent representation of a
particular instance of a particular document. The same document may have
different representations, and those representations will have correspondingly
different canonical forms.
Suppose that I sign a JPEG-encoded photo. What does that mean? Is it
a picture of me? Did I take the picture? Is the picture a
faithful representation of some real-wold object?
This is all irrelevant to the cryptographic operations you may want to apply
to it. You sign the JPEG representation, not the semantics of the image.
Semantic information cannot be specified concretely (ask any semanticist :)).
All anyone really
know is that the encoded photo hasn't been modified since I ran it
through my fingers (metaphorically).
Precisely. This is generally the main things that people what to know,
though. If I get a message from you, I can verify that (a) it's from you, and
(b) that the copy I am looking at is unchanged from the copy you signed. Any
further interpretation is completely dependent on the other context of our
communication.
In summary, I am very concerned that we understand the implications
of signing a bucket of bits.
All signing a bucket of bits does is allow a recipient to verify that the
bucket of bits is unchanged from when it was signed. That's it.
I'm confident that the PEM/MIME spec does
a reasonably good job of describing the syntax of these complex objects.
I have much less confidence that we have a good handle on the semantics.
I do not think we can get a handle on the semantics, any more than we can get
a handle on the semantics of a signature made by a pen (witness the vast
volumes of contract & tort law :)). That's a separate issue, and is
completely dependent on the communicating parties in question.
Amanda Walker
InterCon Systems Corporation