On Wed, 24 Sep 2003, Some Guy wrote:

> Dan, I hope this critique is alright.  I may not have
> 100% unstood everything, but it seems like a few
> things could be improved.

> > DPK@<keyring>/url

> Instead of coming up with a new key type and having
> even longer URLs, would it be possible to just stick

You need a special new keytype to require the signatures,
for the same reason that you need a special keytype to be
signed. (SSK vs CHK).  

> 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"

> You could sigh something saying "These 10 guys are on
> the ring and it takes 7 to change something." 
> Inserters could then send this certificate with all
> their signature, but nobody could change to policy
> especially if the key was destroyed (unless the policy
> said so).

Yes.  And insert that as a normal CHK document.  There's
no way to change it, ever.

> > The problems with this proposal are mostly due to
> > the keyring CHK.  Any node
> > wishing to validate the signatures has to fetch the
> > keyring CHK... which may be
> > WAY away from their specalization.  (Or, in an
> > attack scenario: nonexistant.)
> 
> 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.

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)


> 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.

--Dan

Attachment: pgp00000.pgp
Description: PGP signature

_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to