With the ever popular talk of revokable keys, I'd like to propose an alternative as a thought experiment. It's got holes yet but does address some problems revokable keys have.
It's rather rough because I had just finished first-drafting it when I got called away on a server crash, so I'm sending what I have now before I forget it all. --Dan ----------- 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 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.) 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. 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) 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)
pgp00000.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
