Ned, thanks for your detailed and informative reply.
Ned, you and I had some dialogue along these lines four or five months ago.
At>> the time, I was working on a proposal for the Army for battlefield
communications of multimedia objects, where there is insufficient bandwidth
to>> accommodate the traditional "push" type of e-mail architecture. I think
we>> convinced the Army that they needed something like the
multipart/alternatives>> capability to specify a URL to a high-res, full color
map, a medium res>> version of the same thing without all of low-level
details, and a bit mapped >> low-res thumbnail sketch. Then, depending on the
bandwidth and priority >> available at the moment, the user can download the
portion of the informaiton>> that is most relevent.
I just found out today that we won that contract. Suddenly I'm even more
interested -- I may have to actually do some of this!
There are definitely semantic problems with this, but few having anything do
with security. The primary semantic problem, of course, is that there's no
way>to indicate which part is which or why one should be selected versus
another.
Suppose you have a multipart/alternative structure of the form:
-multipart/alternative
-image/gif
-image/gif
-image/gif
Which image is which? It may be reasonable to assume the first one is
"simpler", but what does this really mean? How do you rank, say, a large
high-res black and white image versus a small color image?
Multipart/alternative doesn't address this. It assumes that the type and
parameter information is enough to make a choice between parts. Clearly this
assumption is untrue in general -- for that you more or less need to have
access to the stuff a URC contains (or will contain once URCs are
defined...).
Qeustion. I am assuming that I am sending a very simple mail message which
references these various files as external body parts. Would I necessarily use
mulipart/alternative in this construct? Clearly I don't want to have to parse
the message itself to determine which image parts are which, but how do I
indicate that in the reference, when the files aren't included? Does the
recipient even know that it is gif file, as opposed the MPEG2, for example?
As for security, various mechanisms are possible in this scenario. One type
of>security is provided when the URL to simply point something that's
effectively>signed or encrypted or both. In this case there are no less than
three possible>models for delivering the security service:
(1) Use something like SSL to secure the connection proper.
(2) The object itself is a MIME object, so it can be a security multipart.
(3) Use HTTP's content-encoding mechanism to provide security services.
Preserving the confidentiality wasn't the issue, nor the integrity of the
object itself. But rather, as you indicated later, to make sure that the file
that I the sender am referreing to is the same signed object that I intneded,
and that requires including the message digest along with the URL reference
somehow.
The other sort of mechanism is to use a Content-MD5 header within the signed
message to provide a digest of the object being pointed at. This mechanism is
already well defined -- all that's needed is the smarts in agents to perform
the necessary check. (My user agent has had this ability for some time...)
This>does depend on the URL pointing to a single, unique object (this is not
true of>all HTTP URLs), but would work out rather well when it does.
All the more reason to include the Content-MD5 header, if URLs can point to
different objects!
The semantics of all these combinations of services are quite different, of
course. Including a content-md5 assures that the object retrieved is what
message signed intended. Retrieving a signed object only means that its
signed>and nothing more -- the association with the current message may in
fact be>incorrect.
Exactly
[Discussion of CDPD snipped.]
This sort of thing brings up several more issues with message/external-body,
such as knowing the size of something before you retrieve it. However, I'm
not>sure I see any real problems on the security side.
I think that's the same concern I expressed above -- in the case of an
external body part, how do I find out enough about the object to decide
whether to retrieve it?
I hate to confess my almost appalling ignorance of the details of URL
formats,>> HTML tags, and all of the rest of the web paraphenalia, but I sure
would like>> to see someone come up with a good STANDARDIZED way to solve this
problem.
We already have one. Its called content-md5. See RFC1544 for details. Here's
an example of what one of these things would look like:
Content-Type: message/external-body;
name="doof.gif";
site="thumper.bellcore.com";
access-type=ANON-FTP;
directory="pub";
mode="image";
Content-type: image/gif
Content-ID: <id42(_at_)guppylake(_dot_)bellcore(_dot_)com>
Content-Transfer-Encoding: binary
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
This would all have to appear inside of a signed message, of course.
I'm a little confused. Is that one file you have defined, or two?
[Lengthy discussion of X.500 DNs vs. URLs deleted. I think you missed my point
-- I wanted a DN entry to contain a URL, so I can look up a document by name
and revision number, without worrying about the details of the site, access
type, etc., at least at this level of abstraction. But I've discussed that
subject on ietf-pkix, where it seems more appropriate.]
Regards, Bob
Robert R. Jueneman
GTE Laboratories
1-617-466-2820 Office
1-508-264-0485 Telecommuting