--- Dan Merillat <[EMAIL PROTECTED]> wrote: > On Wed, 24 Sep 2003, Some Guy wrote: > > > > DPK@<keyring>/url > > > Instead of coming up with a new key type and > having > > even longer URLs, would it be possible to just > stick > > > with SSK format but just sign the keyring once > with > > the private key and then throw it away. > > good god NO. There's no way to know it's been > "thrown away"
The SSK URL format could have been saved, if you used this throw away technique, but yes I understand your objection. You don't want to trust anyone more than the rest of the signers even for a second. Anyway, it seems if you come up with some new authentification, it will provide a superset of the functionality of SSK, so eventually SSK might be redundant. > > This data should be routed to the same place as > the > > rest of the data. I see no reason why that's not > > possible. > > Clumping is bad. We don't want to introduce a way > to force > an unlimited amount of "related" data to one node. This data is very related!!! In fact, neither the data nor the certificates are of any value by themselves. The node with the data needs the certificates before it can even upload the data one hop. I'm sorry, but I see no reason why they should be stored somewhere else. The node caching the data needs them to validate an insert and to upload for a request. Why should it throw the thing somewhere out there to retrieve later? > If done this way, it's an even easier attack then > the 10-15 > bit flooding attack I was discussing earlier. > Generate random > keyrings until you find one in the appropriate > keyspace, insert it, > and sign lots of random data with it. (Under 32k, > same as a SSK) Ahh, insteresting point about the SSK DNS; I didn't think of that. There's nothing We can do about that though is there? The DNS issue is important. You have a choice: A) All certificates have to be handed in together, so they can be checked on the way to the target. B) A mutually annoymous group can insert thier certificates seperately. A will solve most our problems, and resists the possible floods from rouge members. B is cooler, but it may have to have something to prevent a rouge member of the ring, bombing nodes, by making junk certificates. Something like a limited number of certified slots, could be cached so the rouge cann't resend indefinately. Or wait let's combine our ideas!!! Store the individual signatures in different places, but to insert actual data, one first must collect those signatures and the policy to send with the data so you can validate it on it's way in. This would allow the individual signers only to DNS thier own signature. This seems like the best you could do. It'd still be possible to do a seperate DNS on the hash space using a seperate SSK attack though. > > Not if you use my suggestion. You could possibly > make > > it to where if "9 of 10 want to change the policy, > > they can." This could lead to a string of > > certificates required on insertion, but otherwise > the > > URL wouldn't change. Implementing this may be > pain in > > the butt. > > That was my suggestion, actually. Please re-read > the proposal > again. I was talking about my suggestion with the throw away key. I'm just tring to come up with a shorter key format so you can have 100 signers without a 5000 character URL. Here's better idea to keep the keys short. URL= HASH(<key1><key2><key3>..<keyn>policy_blablabla)/page.html This should keep the URLs from exploding. Sound ok? Cool discussion!!! __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und Klingelt�ne f�rs Handy bei http://sms.yahoo.de _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
