Talks
I went to only a few talks, and didn't feel deeply inspired by most of them. The most interesting was probably Lucky Green's on TCPA (partly because I was going to be on a panel with Lucky on that very subject the following week). I had a couple of gripes with it -- for example, S. 2048 (or "2^11" for short) doesn't mention TCPA or Palladium anywhere. Microsoft has also said that they don't want Palladium to be mandated by law; I'd still like to hear more about what they are doing to prevent that outcome.
There's a pretty interesting debate going on right now on the cryptography@wasabisystems.com list about Palladium. One of the interesting phenomena there is that Lucky will predict some very harsh and likely harmful-to-the-public use of Palladium, and other people will reply "You're just being paranoid! That's not in the spec!". And that answer is correct, in the sense that none of these things are in the spec. For example, the Document Revocation List (DRL) is not in the spec. (There is a side-discussion about the fact that there is no spec for Palladium, and in fact Peter Biddle said he's been referring people who ask for a spec here to Vitanuova!)
Now, a conflict results because Lucky predicts with some confidence that Palladium will be used to do things like the DRL. But it's also the case that the DRL is not "part of Palladium". As far as I can tell, it's something which application vendors would be able to implement under Palladium. (I'm sure the relevant blinding, hashing, and public-key encryption algorithms aren't beyond the reach of protocol designers; when you sent a document to some other party, it could be encrypted with a key which could only be had by authenticating with a server out on the Internet, which demands a Pd certificate and then demands from the Pd-aware application a hash of the document before providing a decryption key.
Of course, you can do something like
{E(SHA1(SHA1(d)+secret), d), SHA1(d)}
Say you're implementing Microsoft Word with a DRL server. So when you want to "Save For Publication" (to the outside world; ordinary Save could still be cleartext), you simply tell a particular DRL server SHA1(d), where d is your document. The DRL server responds by concatenating SHA1(d) with its private secret, taking SHA1 of that, and returning the result to you (over a secure channel). You use this value as your symmetric encryption key, and you encrypt the document and publish it along with SHA1(d).
When you want to decrypt, you need to begin by authenticating yourself to the remote server, in order that the remote server may know that -- if it decides to give you a decryption key -- you will only process the document according to policy, and not, for example, export a cleartext copy. Then, having authenticated your application, and having had the integrity of your environment attested, you tell the appropriate DRL server that you want to decrypt a certain document which has has the hash SHA1(d) -- which you know, because that value was included with the plaintext. The remote server knows that you are an unmodified Microsoft Word running on a machine in trusted mode, because of your authentication steps. The remote server also knows its own private secret. Now it looks into its revocation list and determines whether or not SHA1(d) appears in the list. If so, it returns "Sorry, that document has been revoked because <reason>"; otherwise, it concatenates SHA1(d) with its private secret, calculates SHA1 of the result, and returns that. This is the decryption key needed to decrypt and display the document, and the application is guaranteed to process the document only according to its policy because it has already proved that it is the original, unmodified version of Microsoft Word, running in a trusted environment.
What interests Lucky about this is that it is possible to implement this within Palladium. "Check with a revocation server before displaying this document" is a possible policy, and Palladium allows you to implement and enforce any policy which you can specify in hardware. (The particular protocol above is very crude; I'm just giving it off the top of my head, and it can be improved a lot.) Lucky hypothesizes that such revocation policies will be implemented in Palladium, because application vendors' customers will desire them, and so the application vendors will have an incentive to use Palladium this way.
After all, somebody pointed out during the Dmitry Sklyarov case that Adobe's customers for most of its products, and especially Adobe eBook products, are not the end-users of the documents, but rather the publishers of the documents. In the eBook case, Adobe's customers are not eBook readers (they get the Adobe eBook Reader software for free) but rather eBook publishers (they pay lots of money for eBook publishing software). This is very clear if you read Adobe's statements about the case -- in response to questions about why Adobe eBook Reader restricts you from doing many things (which more useful software like AEBPR does not), Adobe answers, in effect, that such were the requirements of Adobe's real customers, the publishers.
So Lucky thinks that publishers' design requirements will drive implementations of application software implemented under Palladium. And that would mean that, if publishers think document revocability is a good thing, major document-processing application vendors will want to implement document revocability, in order to keep their customers happy.
Lucky's critics point out that such revocation is no part of Palladium, is not in the Palladium spec, has not been predicted or advertised or advocated by Microsoft, etc. And Lucky thinks this criticism is irrelevant, because he's confident that this capability will be used in this way once it exists.
What is the DRL idea? The idea is that an application opening a document first needs to check in with a server on the Internet which will tell the application whether that document has been revoked or not. If the document has been revoked, the application will refuse to open it. So Lucky imagines a particular document suddenly unusable all over the world because somebody has decided to unpublish it.
