--- Dan Merillat <[EMAIL PROTECTED]> wrote: > On Fri, 26 Sep 2003, Some Guy wrote: > > 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. > > 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? > > Oh, I _LIKE_ that Idea. Thanks :-) > So here's the proceedure: I ask for the public keys > of 4 trusted > developers, and create a keyring with our five keys > and a policy > (minimum=3). I send it to them to verify, and they > can see the hash. I don't think they need to verify that they're in the group, the hash proves that. I suppose you could put somebody on the ring, who never does anything for while, if you don't need his signature. > Now, to insert I take the data + keyring and sign > it, then send. > We use the same routing/verification code as a SSK, > since the keyring > is included. When anyone else signs it they do the > same thing > <data+keyring>/signed. It _SHOULD_ route to the > same place if NGR > is working well, or at least cross the path > sufficently well. Arg no, I still think before freenet lets you insert data you should have to prove that it is valid. 1) This suggestion would require nodes to hang on to two versions of the site until the new version was verified. 2) It would allow a single hostile member of the ring to do a SSK style DNS dirrectly on the site, uploading one random version after another. 3) Despite how well NGR _SHOULD_ route, it'd still be way better if data couldn't get marooned without verification data. Sure maybe two inserts might cross each other, but what are the chances of 10 of those happening? 4) I believe nodes cache inserts probabalistically too. So you may have to play with that code to get this to work, doing something like "once you cached any of the data you keep all the other pieces".
So here's what I suggest: You pick your four friends and the policy, they pick thier keys. A latest version gets distributed around, so everyone can verify it. They sign for it and give the inserter, the signatures, the keyring(in order), the policy, and the data. Those four things are never seperated. When the I request the site, I should get back those four things and use them to verify the data. Theoretically I could reinsert the site having those things. This leads to another point: the policy or the signatures should have expiration rules in them. Say version X of freenet is discovered to have a horrific security problem. So we update to version Y. A cancer node could theoretically return the old verification data and old data for version X to trick people into downloading the faulty version. He could also overwrite the site with the old version, if there were no versions. I know we do expire SSKs, I'm just pointing it out. It seems like you'd want to never accept an old version of a critical site. So where does the date go, in the signatures, in the policy, or both? > Ian, what's your take on this? Would you consider > this "sound" enough > to entrust distribution to? Here's one more idea, if you just wanted to use Freenet to save bandwidth, but didn't want to trust an SSK: put links on your trusted website to CSKs. __________________________________________________________________ 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
