(Momentary non sequitur -- would/does MIME support the notion of a hypertext
document, where the relationship between the parts doesn't change, but the
contents of one of the parts might?
Yes it does. MIME includes the concept of an object that is nothing but a
reference to something else, and that something is usually obtained by using
some other protocol (e.g. ftp). This could then be embedded inside of some
species of multipart that specifies the relationship between parts (e.g.
multipart/parallel, where all the parts must be displayed in parallel).
In the security multipart extension to MIME its the reference that gets signed,
not the remote object. The remote object is a MIME object and thus can itself
be a signed entity, of course, and once you retrieve it you can verify the
signature that's on it. (Alternately, the security could be provided by the
network link itself.) However, the signature is co-resident with the remote
entity, not with the message that references the entity.
This is not a problem in and of itself -- you want the signature to be resident
with the entity so that the entity can be updated by an authorized person
without invalidating the message's signature. However, this setup is vulnerable
to attacks where the reference is maliciously redirected to a different entity
that is also signed. (Use of a secure retrieval protocol may or may not address
this issue.)
For example, suppose you're providing election ballots during a primary where
you send some people references to the democratic ballot and others the
republication ballot. Now suppose that someone manages to redirect the
reference from the democratic ballot to the republication one. Both ballots are
signed, possibly even by the same agency, so the signatures verify. So things
look OK as far as the signatures go, but you've managed to really mess up the
election. (Its not clear in the real world that some people would even notice
that the redirection had occurred ;-)
Put another way, there are really three things you want to secure here:
(1) The message.
(2) The remote object the message references to.
(3) The connection between the two.
You can of course combine (1) and (2), but only as the expense of removing the
ability to update the content after the message is sent. If you elect not to
combine them you need (3), and this is one of several things that's on my to-do
list once the basic security multipart mechanism is in place. This isn't at all
difficult to address (think for a moment about MIME's content-id field and
you'll be well on the road to a fairly trivial solution), but it will take some
additional specifications and the definition of at least one new content-type.
(I'll leave it as an exercise to the reader as to why a new MIME type is
required -- this can be a test of your knowledge of MIME...)
One of the problems that I have with some
of the existing products on the market (I won't slander anyone by name) is th
they digitally sign the variable fields of a standard form, but don't protect
against changes to the form itself.
The security multipart mechanism is almost the opposite -- we have a means by
which you can secure the relationships between the objects and you can secure
the objects themselves, but not the connection between the relationships
embodied in the message and the remote objects!
A MIME document could potentially include a
standard form (signed by its creator), the signed variables fields document,
and a signed enclosure form which binds them all together. Is this
possible/supported within the current PEM/MIME spec?)
This is supported now by the basic mechanisms that lets you sign a group of
objects together rather than one at a time. However, this doesn't let you
update a particular part of the group without invalidating the signature. You
need both the ability to reference an outside object as well as to verify that
you're referencing the right outside object.
Neat stuff, isn't it?
Ned