At 11:50 PM -0400 8/23/2000, Jeff Kandt wrote:
>On or about 12:49 PM -0400 8/23/00, Arnold G. Reinhold wrote:
>>Certificate revocation is one of the thorniest issues in public key
>>cryptography. Maybe you can solve it in this narrow context, but I
>>would avoid it if there is another way and I believe there is.
>
>I agree, and as I really want Tipster to be as decentralized as
>possible, I wish there was a better way. Someone suggested putting
>expiration dates on the keys, but that doesn't work because we want
>the signatures on the file to remain valid for a long time -- years
>or decades maybe, or as long as a file is likely to be traded around
>between fans.
>
>>The phrase "why not put in some crypto to give the fan some feeling
>>of security" really gets my fur up. There is no reason not to
>>design a system that really works. I support your overall goal,
>>but you will severely damage your credibility and the credibility
>>of voluntary payment models in general by abusing crypto in this
>>way.
>
>I'm sorry if I failed to take the proper reverential tone when
>referring to crypto; please be assured that I take the crypto behind
>Tipster very seriously, even if I'm not a professional at it. I'm
>not sure what makes you say I'm "abusing" crypto.
>
>My point was that one _could_ simply place an unsigned URL on the
>file, but both the fan and the artist would probably prefer if we
>could make it at least somewhat resistant to tip theft, and for that
>we can use the toolset provided by cryptography.
>
>Anyway, and more importantly, when you say "There is no reason not
>to design a system that really works," are you're saying that
>Tipster won't work?
>
>>Thanks for the invitation. I think I've said my piece on the
>>philosophy. If you want a critique of your cryptographic design
>>(and are prepared to listen) I prefer a forum where other
>>cryptographers are present.
>
>Yes please! That's why I posted it here.
>
>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.
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).
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.
o The requirement of certificate cancellation seems to imply a
central server. That violates goal 7.
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.
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?
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.
Arnold Reinhold
