Zem writes:

Alice the music critic buys copies of new content at relatively high prices from the creator, or close sources. When Bob requests a copy of a particular file, Alice encrypts it to Bob's public key and signs the encrypted copy, selling him this 'reviewed' copy for reproduction cost + profit. Bob can verify he's received a good copy, but he can't redistribute Alice's reviewed version without revealing his secret key.

Four points: First, I want to reiterate that the original idea of the so-called "recursive auction" is fatally flawed. Apparently Eric Hughes was aware of this, but it never sunk into Bob Hettinga's thick head. All this talk of editing and reputation is a different idea with a different goal. The original recursive auction was simple, as Hettinga described it: you sell the first copy for a lot, the next for somewhat less, the next for even less, and so on. That doesn't work. End of story. Second, your idea above for preventing redistribution doesn't work. Aside from the workaround you came up with, using a throw-away encryption key, it is easy to redistribute the signed data. When the file was encrypted to Bob's key, using PK cryptography, what actually happens is that a single-use key is generated, which we'll call K. This is a symmetric crypto key, like for AES or 3DES. K is encrypted with Bob's public key, and then the file is encrypted using K. So all Bob has to do is to reveal K when he redistributes the Alice-signed, encrypted file. This allows everyone to read the data and see that Alice did sign it in encrypted form. The fact that K produces a meaningful decryption of the AES encrypted file is itself proof that K is valid, but if more is needed, it is easy to release additional information to prove that K is a valid decryption of the PK encrypted part. Third, there are better cryptographic ways to do what you want. You can use Chaum's designated confirmer signatures, which Alice can issue such that only Bob can confirm the signature. Or you could use the ring signatures from Rivest et al, which produce a file which could have been signed either by Alice or Bob, meaning that when Bob redistributes it there is no actual evidence that Alice signed it. (That's how the designated confirmer signatures work, too.) Neither of these approaches requires the data to be encrypted, just signed. Or even simpler, Alice can avoid signing entirely, making the file available for download to subscribers who authenticate with SSL. The key exchange in this case involves Bob sending K to Alice, encrypted with her public key; and the fact that she decrypts it proves to Bob that she is who she claims. But this is not a transferable proof because Bob could have forged it all. Fourth, Eric Hughes pointed out the fundamental flaw in this whole approach, many years ago. As others have pointed out, Bob can simply distribute Alice's files under his own name, and quickly gain a reputation for faithfully passing along Alice's information. If Alice threatens to cancel subscribers who do this, Bob redistributes under a different identity. Now we are back to watermarking to try to figure out which subscribers are passing along her reports, with all the countermeasures and counter-countermeasures that entails. There is no evidence that the content protector can expect to win such a battle.