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.
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...).
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.
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.
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.
My favorite combination would be to use something like SSL to secure the
connection and a content-md5 to enforce the relationship between the message
and the remote object.
A similar concern has popped up in the Cellular Digital Packet Data (CDPD)
world, where the user gets charged by the packet for the information that is
either send or received. If an unknowing correspondent sends the CDPD user a
simple mail message asking for an opinion and includes a 400K spreadsheet, the
charges could be ruinous. The more reasonable strategy is to communicate the
short, urgent portion of the message, and let the user retrieve the details
once he gets back to his hotel room or wherever.
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.
And in the ietf-pkix forum as well as the Information Security committee of
the American Bar Association, I have been trying to whip up some enthusiasm
for including a URL to the Certification Authority's on-line policy document
within the certificate that is issued by the CA, together with a message
digest of the policy, since an OID is not necessarily sufficient to capture
any subtle changes in the policy.
This is effectively equivalent to including a content-md5 header in a
signed message/external-body.
In all of these cases, it is important to tie down the URL to a specific
document by including a message digest of the external body part within the
signed message or certificate. Since the originator of the document could
easily replace it with another version which was also signed at about the same
time, not having the message digest tied to the URL means that the recipient
can easily be spoofed by a replaced version.
Exactly. This is what having a content-md5 header in the external-body buys
you. The only real difficulty you have to be aware of is the possibility that
HTTP will resolve the same URL to different things depending on client (not
server) capabilities. This has to be blocked somehow if this mechanism is to be
effective. The obvious way to block it, of course, is to simply offer only one
version of the object!
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'd really prefer an X.500 solution, where instead of a URL there would be a
distinguished name of the document. That way, when someone decides to take
down one file server and move all of the document somewhere else, users
wouldn't be left with a bunch of useless, dangling URLs. But I'm not holding
my breath.)
First of all, a URL is just a packet of protocol-to-use/how-to-use-the-protocol
information. There's nothing that says a URL cannot contain a DN. In fact URLs
containing DNs have been defined already (e.g. the LDAP URL).
Second, the naming system a URL happens to employ doesn't say squat for about
its long-term stability. You seem to think that DNs somehow magically confer
this stability on things. Operational experience, in fact, indicates that
exactly the opposite is true -- the overall stability of X.500 services, on the
Internet today, all of them based on DNs, is *simply* *dreadful*. The surveys
I've seen have said that only 30% of the X.500 stuff that's supposed to be out
there is actually available at any given time. My personal experience with
these things, which happens to be considerable, tells me that 30% is what you
get on a *good* *day*.
General Web services, on the other hand, are vastly more reliable than this.
They have to be because nobody will use a service that doesn't work 2/3 of the
time. (This obvious flakiness also makes X.500 solutions an increasingly tough
sell...)
Now, I happen to use X.500 a lot and I like X.500 a lot. My company sells
products based on X.500 and LDAP. We are devoting an ever-increasing amount of
time and resources to this area.
But as far as delivering data objects to users on demand, let's *please* try to
be realistic. There is a clear winner in this area, and its URLs and the Web
and the protocols the Web is currently based on. There is no longer any chance
at all that the world is going switch to using X.500 and DNs in URLs for this
sort of thing. The market has chosen, and that's that.
URLs are everywhere. Magazines, newspapers, radio, TV, movies, tee shirts,
skateboards, you name it. There's now a URL painted on a dumpy old park bench I
see every day when I drive to work. (It replaced an advertisment for something
called T&A Video...)
The dangling URL problem is a real problem, yes. But DNs are not a solution to
this problem -- operational experience indicates that if anything they will
only make it worse. And work on a real solution -- the URN -- is well underway,
with various prototype and protocols already being deployed for test purposes.
But URNs are not based on X.500 or DNs either. And I doubt very much that this
will change.
X.500 and LDAP are still ahead in the white pages game, and because of this I
expect URLs for X.500 and LDAP to be quite useful in some contexts. Hopefully
X.500 and LDAP will be the winners in the certificates game as well -- its too
early to tell.
Security solutions have to deal with the procotols people actually use. And
URLs embody the protocols people actually use. So let's secure them.
Ned