Dan, I hope this critique is alright. I may not have 100% unstood everything, but it seems like a few things could be improved. > ----------- > > Decaying Partial Keys > > The idea here is that a DPK address references a CHK > that consists of a keyring > and some metadata. (How many signatures required, > experiration rate, etc) > > > 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. 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). > > In order to insert a DPK, you have to have a key > that's on that keyring, then > sign that data with a timestamp. > > The data is inserted similar to a SSK with the node > validating the signature. > Unlike a SSK, however, it's not retrievable. In > order to retrieve it, other > members of the group must insert their signatures of > the data. (As specified in > the keyring) > > The way it works: Everyone can inspect the keyring > and see who's involved. If > a developer is compromised, you simply refuse to > sign the data. Obviously, the > process is inefficent, hence the "decay" part. > > Automate the retrieval and signing of the data. > Designate one "uploader" who > pushes it both on the DPK and on his personal SSK. > The other members' scripts > download from his SSK and publish their signatures. > This way it's easy enough > to update the website. > > If the uploader is rogue, or you wish to quit > propagating the data, quit > signing it. When it's requested, and the node finds > it, it validates the > timestamps on the signatures, deletes the old ones, > and if there's still enough > signatures to make it valid, return it. > > If there's not enough signatures, pass the request > on but include the > still-valid signatures you have. If someone else > has it, they add your > signatures to it. If there's enough, return it. > Anyone who has the key as it > goes by merges the returned signatures to their own > copy. > > (Obviously signatures have to be inserted to their > full HTL) > > 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. > The drawbacks: When a developer leaves (amicably or > not) you have to change the > DPK@<keyring> to compensate for that. This may mean > publishing on multiple > keyrings during the changeover period. Obviously, > the number of required > signatures must be greater then one, and probably > less then all. Figuring out > the right number could be difficult. > > The other possibility is to include the keyring > encoded on the URI, or enough > fingerprint bits from each key to recognize it. > Again, when you lose a > developer you have to change the keyring, which > means changing the URL. 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. > The keyring can't be a SSK or DPK itself. If it's a > SSK, all the trust issues > go right out the window, since the owner of the SSK > can change the keyring to > whatever he wants. If it's a DPK, how do you verify > the signatures on it? > Does it refer to yet another DPK? > > Before blasting this proposal: consider this. > Revocable keys have EXACTLY the > same keyring distribution problems. When I go to > RSK@ (Revokable signed key), > how do I know who can revoke it? You can't include > the keyring as part of the > RSK, since then anyone could insert it with their > own keyring. If it's > external (a CHK) then you have the same fetch-a-CHK > as part of an insert that a > DPK has. > > The primary reason for decaying affirmation rather > then revocation is that > the trust model is different when routing is > impacted (be it due to a hostile > environment or a bad network day). If the > signatures can't get to a DPK, it > slowly becomes unusable. If the revocations can't > get to a RSK (or nodes > can't get to the revocations) then the Rogue data > stays in the network (at > least in some places) If all the data winds up in the same place, then a DSA would keep the Rogue Data unreachable too, at least in the steady state. > > The other is a matter of network cost: If a RSK is > to be revoked, EVERY hit to > that RSK has to hit EVERY possible revocation > signature, as well as the keyring. > If a DPK is to be kept alive, only the publishers > have to hit it with new signatures > from time to time. (And every hit has to get the > keyring, a shared cost) __________________________________________________________________ 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
