Sponsored Link •
An alternative scheme we've defined in Davis [the next Jini release] is a new type of URL scheme we call HTTPMD, where the MD stands for message digest. An HTTPMD URL includes a message digest of the contents of the code. The digest is a cryptographic checksum on the data in a JAR file.
This scheme is intended to work with JAR files not with directory-based class hierarchies. There is no easy way to compute a digest over the entire set of directory trees from which HTTP can serve class files. If you are willing to serve things up as JAR files, the normal approach in Jini systems anyway, then you as the server locally compute the digests. You must have local access to the JAR file, so you don't have to worry about its integrity yourself. So offline, or online, or through any means that you trust, you get the JAR file and compute its digest.
Then what you send to me as the code base is an HTTPMD URL, which looks like a normal HTTP URL except that it also has this digest attached. And, again, the URL itself—the code base—is sent in-band as part of our communication. I know I got the digest you expected to send me. When I download the JAR file, I don't care about authenticating the server because I don't care where the data comes from as long as I get the right data. As for the idea of a cryptographic checksum, is it is nearly impossible for somebody else to come up with alternative contents that will have the same checksum.
I have a very high probability that if I get something from whomever, and it has the same checksum, that it is, in fact, the same data you expected to send. HTTPMD URLs are a cheaper mechanism than HTTPS URLs in the sense that I can use normal HTTP transfer. This doesn't have any affect on the HTTP server itself. I can use a vanilla HTTP server. The only change is that on the client side the URL protocol handler says, "As I download the contents from this vanilla HTTP server I will compute a checksum. And at the end I will check the actual checksum with the expected checksum. If they are the same, then I am happy. And if they are not the same then something bad happened and I should not use the code."
Both of these mechanisms, HTTPS and HTTPMD URLs, provide integrity of code. They do it in slightly different ways and have different performance implications. They are two example URLs. You can invent others. We set up the system so that you can just plug in new things and say which URLs should be trusted, which URLs give you integrity.
Bill Venners: What do HTTPMD URLs actually look like?
Bob Scheifler: An HTTPMD URL looks exactly like an HTTP URL, except the
scheme is HTTPMD and the URL is terminated with a semicolon,
message digest algorithm name, an equals sign, and the message digest.
So at the end it might look like semicolon,
a long stream of numbers.