On or about 11:52 AM -0400 8/24/00, Arnold G. Reinhold wrote:
>>The design goals: http://tipster.weblogs.com/designgoals
>>The crypto protocol: http://tipster.weblogs.com/tipsterblock/
>>
>>Both of these are open to debate.
>>
>
>First let me say something positive. I like your design goals. They
>are reasonable and clear. I have a couple of quibbles, but they are
>minor. On the other hand, I must say that I do not see how your
>crypto protocol is justified by your design goals. I'd like to see
>a justification for you protocol based on the design goals.
What would that look like? A sentence or two after each goal which
says "Tipster fulfills this goal by..."? I was thinking of doing
that.
>Will tipster as specified work? I don't think so, at least not well,
>based on your design goals:
>
>o Having the artist sign the block does not prevent theft (Goal 3).
>If the fan does not know (i.e. have a reason to trust) the artist's
>signature, the thief can use any sig. If the fan does know the
>artist's signature, his client can ask the server for a certificate
>signed by the artist. Either way, the artist's signature in the
>content is pointless (unless you are trying to snow the fans).
Yes, the trust model is not well defined. More on this below...
>o Goals 1 and 7 and maybe 6 (not to mention common sense) would seem
>to require that new servers can be added. Your protocol does not
>allow this for content that is already published.
Nor can it, I think, since that would conflict with goal 4,
persistence. I'm trying to make sure that, once encoded, a file can
always find its way back to the artist no matter how long since it
was released by its creator or how many times it's been downloaded
and then re-uploaded to Napster (or Gnutella, Freenet, etc.).
Maybe servers could be added by the fan's client software at the
direction of the artist after the authenticated connection is made?
Something like "Okay, you found me; now stamp the file with [THIS]
signature block, which is the most up-to-date." I'm not sure if the
extra complexity is justified, and letting fans modify the signature
block seems a dangerous precedent...
Since in a voluntary system the artist has no control over where the
file goes or how long it will be in circulation, I tried to build a
system where you could load the file up with multiple server URLs and
then revoke them one by one if/as necessary.
>o The requirement of certificate cancellation seems to imply a
>central server. That violates goal 7.
Yes, goals 6 and 7 are in conflict here, I think. I'm not terribly
happy with relying on a central registry, but I couldn't think of
another way for an artist to cut off a server, given that the
provider's URL may still be stamped on files which were created long
ago.
I judged that since revokation certificates can't be created by
anyone who doesn't possess the private key, the worst trouble a
malicious central registry could cause would be to _fail_ to
propagate a revokation cert. Since this should be easy for the
artist to discover, I thought this was a low risk.
>o Why does every server have to sign each piece of content? Why do
>you even care about the hash of the content? That seems to violate
>goal 2.
My goal #3, "difficult for thief/attacker to steal tips" should have
added the word "successfully."
While it's impossible to prevent someone from attaching their contact
info to someone else's file, my goal with Tipster's signatures was to
make such naughtiness easy to discover and prosecute.
If the artist discovers one of his files posted somewhere with
someone else's contact info on it, the signature makes it difficult
for the persons who run the malicious server to deny that they were
active participants. If the signature from the thief's server
matches the key used to sign the pirated file, that's a pretty
effective smoking gun. Not only did he sign the file, but he's
running a server which uses that same key to collect payments.
And here's where we get into the trust issue. Despite goal 7,
decentralization, I'm afraid lately I'm leaning towards a certificate
authority model, maybe similar to SSL. Given the above threat model,
all that is really needed is for the key to be signed by someone who
has checked the artist's credentials as a legal entity, making sure
they are someone who can be tracked down in meatspace by the cops and
lawyers if they abuse their cert by using it to steal others' tips.
>o Goal 4 suggests that only information that will never change
>should be included with content. Servers will come and go. All you
>really need is the artist's URL. Why add more?
Yes, an artist could maintain a single, stable URL. But most artists
aren't technically savvy enough to administer their own server, any
many are too low-budget to afford their own server, domain and
Verisign/Thawte certificate. So they're going to have to delegate to
others, and this is where I really want to be careful.
My initial motivation for designing Tipster was anger over how the
labels are screwing musicians. So I wanted to make sure to make it
as hard as possible for intermediaries (who I think are still going
to be necessary) in this new voluntary system to gain power over the
musician.
>I think one can design a much simpler system that meets your design
>goals. My suggestion would be to just have the artist's URL in the
>content and maybe a standard way for identifying the title of the
>work. If the artist obtains a URL that matches their group name
>exactly (www.moronenvy.com), that in itself could provide enough
>trust for transactions on the order of a dollar. The fan could check
>the artist's signature in other ways as well: from a commercial CA,
>from an artistic key server, from a key fingerprint printed on a
>concert program, from signed lists of artist keys circulated by self
>appointed notaries on music lists, etc.
>
>The fan's client could download a list of acceptable servers and the
>artist's signature from the artist's URL. Each server would get a
>certificate from each artist when the artist agrees to let the
>server collect for them. This certificate would be signed by the
>artist and could have an expiration date. Artists would then have
>two ways to revoke a server's authorization: remove the server from
>the list of acceptable servers on the artist's web site or refuse to
>renew the server's authorization. No central revocation server or
>CRL is required. Adding a new server would simply require signing a
>cert and listing the new server on the artist web site.
>
>There are details to be worked out o course, but I believe this
>would be a lot less complex and more effective than what you are
>proposing.
This sounds very similar to another suggestion I got for a simpler
system. The writer also suggested a system where the artists each
register their own URL, except that he proposed delegating the trust
issue to SSL.
http://tipster.weblogs.com/discuss/msgReader$58
A later enhancement used expiring server keys, as you suggest, to
make revokation certs unnecessary, an idea I'll probably adopt.
http://tipster.weblogs.com/discuss/msgReader$68
Thanks very much for the feedback, Arnold. I'm still digging. Based
on the comments I've gotten from you and others, I will be writing up
some of the pros and cons of the various plans on my site and
requesting another round of comment soon.
May I quote/post your emails? (Or is there a web archive of these
posts anywhere?)
Also, a new technology I've just been made aware of is TunePrint,
which claims to be able to make a unique hash of any song, based
purely on the audible signature of the song so that the "fingerprint"
is the same no matter how it is compressed or encoded. This has a
big potential for voluntary payments, I think, though I haven't
thought about it enough yet.
http://www.tuneprint.com
Thanks again!
-Jeff
--
--------------------------------------------------------------------------
|Jeff Kandt | Voluntary Payments: A Napster-friendly business |
|[EMAIL PROTECTED] | model for musicians. http://tipster.weblogs.com |
|[PGP Pub key: http://pgp.ai.mit.edu/pks/lookup?op=get&search=0x6CE51904 |
| or send a message with the subject "send pgp key"] |
--------------------------------------------------------------------------
