(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).
I thought so. I agree with Ned and Peter -- this is great stuff, and the
application to e-mail is probably only going to begin to scratch the surface.
This isn't my field, really, but I've been trying to get the people who are
involved in Object Oriented Design to consider these kinds of security
implications for some time.
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.)
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.
In the case of a quasi-static relationship, e.g., a baseline document, source
code, etc., the connection between the "message" (the linkage editor include
cards, by analogy) and the individual objects could be established and
confirmed by referencing the message digest of the individual signed objects,
so that ultimately you could build a digitally signed and verifiable bill of
materials for an entire software build, for example.
But if one or more of the constitutent parts is allowed to be altered
dynamically, and a new composite assembly results which is still supposed to be
valid, then it seems to me that some sort of a capability ticket or other
mechanism is required so that you can specify who is allowed to sign the
variable part and under what circumstances and still have a valid whole.
To be fair to Steve Kent, it is these kinds of semantic traps that can easily
escape the untutored eye, and why it is so important that the broader community
examine these kinds of protocols.
I haven't examined the spec to that level of detail, so I don't know. What
would a PEM/MIME implementation do if it was presented a signed message that
referenced a remote object without the kind of secure connection between the
two that you described? Would it validate the signature, thereby potentially
lulling the user into thinking that the entire assembly had thereby been
validated?
Since the answer to this questions didn't immediately leap off the page when
reading the spec, maybe we should have a more comprehensive statement or model
as to what is being assured and what is not?
Bob