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.
Sure.
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.
Exactly. There has to be something in the signed message contents that
indicates what signatures are acceptable, if any, in external referenced
objects.
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.
Well, in this particular case this happens to be something we (or at least I)
have thought through in considerable detail already. I don't mean to be rude,
but I certainly didn't need wider community examination to expose this
particular nuance of MIME. I was one of designers of MIME, after all.
This nuance isn't unique to MIME in any case. How many mail messages do you see
these days that incorporate one or more URLs in the text of the message? Lots!
This incredibly common usage (far more common than the use of MIME external
references) brings up all the same issues. The only difference is that there's
no infrastructure within with these issues can be addressed, whereas when MIME
is used there is.
This is also just the begining -- there are all manner and species of
interesting applications and mechanisms and procedures that arise naturally
from the wedding of security services (PEM or whatever) to email. None of
these issues have been dealt with in any context thus far, mostly because
without something like MIME there is little if anything you can do about it!
Here's an example of yet another possibly interesting future interaction.
Suppose you have an external reference which, in order to be valid, requires
the use of a particular retrieval mechanism that involves the sender signing
the retrieval request. In effect the originator of the message is asking the
sender to sign something for them in order to obtain the material. There are
many possible uses for such a facility. On the other hand, there are obvious
possibilities for abuse here -- getting someone to sign some fairly
arbitrary thing could be quite dangerous. (There is no mechanism in place
at present to request such a signature, so this is a nonissue for now. It may
become an issue in the future, however.)
The point where we seem to differ is in how such services should be handled in
the specification. I believe very very strongly in the "divide and conquer"
approach to protocol development. (MIME is a strong embodiment of this
principle.) This approach lets us take huge problems and break them down into
manageable, comprehensible, and ultimately solvable pieces. The security
multiparts mechanism is just such a piece -- it gives us the way to impose
security on top of MIME objects. Once this is in place, we can proceed to
define security semantics mechanisms that will let us extend the basic service
to cover all sorts of new applications.
Were we to try to specify the entire gamut of future services we could ever
build, we'd end up with an extraordinarily complex document that nobody, but
nobody, will understand. This is far worse than a simple document with
obvious properties -- a signature only covers the material that is signed,
and references within that material to unsigned things are inherently
unreliable.
Even worse, any such specification will be necessarily incomplete, in that MIME
(and plain text email for that matter) are open frameworks that allow for the
addition of all sorts of services. And in purporting that it is supposed to
*be* complete, such a document actually does a major disservice to the
community and may in fact be responsible for many more security problems than
it ever manages to prevent.
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?
This is an implementation issue. Moreover, it really has nothing to do with the
use of security multiparts per se -- you might be using MIME in, say, a secure
local setup where there's no need to sign anything, but any external references
outside of that setup are suspect. A user agent has to know what the local
policy is in order to resolve such references, signature or no signature. As
such, this is matter for the base MIME specification to deal with.
There is also another interesting security issue that up until recently hadn't
been discussed in any document I'm aware of. The act of accessing data through
MIME external references can itself be a problem -- suppose someone sends you a
mail-server external reference that specifies a threatening note to be sent to
whitehouse.gov. (This exact example was recently posted to the URI list.) This
could cause real trouble. Again, this has nothing to do with security
multiparts, but is a MIME security issue nevertheless, and the next version of
the MIME specification needs to address it. (Actually, I've already written the
prose for this, which I'll be happy to post if anyone wants to read it.)
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?
This is exactly what I don't want to get into doing. We currently have a simple
specification that provides a service whose characteristics are fairly obvious
-- it provides assurance of the directly included content of a message and
nothing more. If we get into trying to deal with all the possible extended uses
of these services we will get bogged down in minutiae. And worse, when you
attempt to grasp some minutiae you always miss others, and the resulting
document will inevitably lead to more security problems, not less.
Ned