AARG! Anonymous wrote: >His description of how the Document Revocation List could work is >interesting as well. Basically you would have to connect to a server >every time you wanted to read a document, in order to download a key >to unlock it. Then if "someone" decided that the document needed >to un-exist, they would arrange for the server no longer to download >that key, and the document would effectively be deleted, everywhere.
Well, sure. It's certainly how I had always envisioned one might build a secure Document Revocation List using TCPA or Palladium. I didn't realize this sort of thing would need explaining; I assumed it would be obvious to cypherpunk types. But I'm glad this risk is now clear. Note also that Document Revocation List functionality could arise without any intent to create it. Application developers might implement this "connect to a server" feature to enforce some seemingly innocuous function, like enforcing software licenses and preventing piracy. Then, after the application has been deployed with this innocuous feature, someone else might eventually notice that it could also be used for document revocation. Thus, Document Revocation List functionality could easily become widespread without anyone realizing it or intending it. This is a risk we should make think about now, rather than after it is too late.
