On Fri, May 19, 2006 at 11:26:10AM -0700, Ian Clarke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I think this is much more complicated than we need, at least for an > initial implementation of RSKs. > > All we really need is to standardize on a "revoked" key within an SSK > that will be checked before Freenet returns the contents of the SSK, > an explanation can be published to the revoked key. Like USKs, an > RSK would be a thin wrapper around SSKs. > > This means that those with the right to publish to the SSK can revoke > it. If you don't trust someone enough to publish to an SSK, why > would you trust them enough to revoke it?
I would trust a group of people to revoke it. Especially if I could boot off any malicious trustees (with the co-operation of the others). Putting all your eggs in one basket - a single revocation key - is a recipe for disaster. The revocation key would have to be given to multiple people for safety reasons. And it would therefore be more likely to be exposed than the insert key. And you could not tell who leaked/abused it when it was abused. Also, even if I do trust someone enough to give them the privkey, I don't see why I should _have to_ give them the One and Only Revocation Key; they don't need to know it. > > I just don't think the use-cases that require voting, multiple > trustees, and so on are really all that likely in practice. I'm thinking specifically of for a project freesite and for auto-updates here. So this is fairly serious stuff. There will need to be other mechanisms to secure auto-updates, but this is an important piece. The users cannot just go to the website to get the new key; if the private key for the freesite is compromized, the website may also be compromized (temporarily). And many users may not be able to easily get to it anyway. So it is useful to have a system for distributing a new key - not just because it allows us to add or remove trustees. > > Ian. > > On 19 May 2006, at 11:22, Matthew Toseland wrote: > > >RSKs will be implemented soon. Details: > > > >A "SIMPLE_REVOCABLE" metadata document contains: > >- A target URI. > >- A list of Trustee's > >- int: Minimum # biased votes to block the site > >- int: Minimum # votes to block the site > >- int: Minimum # biased votes to modify the RSK > >- int: Minimum # votes to modify the RSK > >- int: Maximum size of trustee explanations > >- boolean: HTML allowed in trustee explanations? > > > >A Trustee object consists of: > >- A USK URI for the Trustee's notifications. > >- int: Voting bias > >- String: Name of trustee > >- String: Comments on trustee > > > >When it reaches a SIMPLE_REVOCABLE, the node (the FCP client layer) > >will > >fetch all of the URIs for the trustees. It does not fetch them as USKs > >however; it fetches the first version first, and if that exists it > >fetches later versions until it runs out of versions. > > > >Normally, all the trustee URIs will produce DNF. However, sometimes > >they > >will return metadata documents of type REVOCATION_DETAILS. > > > >This consists of: > >- 1 byte: Trustee status code: > >KEY_BLOWN (0) = The RSK key is blown. > >NEW_KEY (1) = There is a new RSK. > >- URI: Explanation. > >- If status code == NEW_KEY, URI: New RSK. > >- If status code == KEY_BLOWN, optional URI: last known good version. > > > >If all the trustee URIs return DNF, then the user will not be alerted. > >If any of them have KEY_BLOWN, the user will be told, and shown the > >names of each trustee and their explanation's (in an iframe). The user > >is allowed to progress to the content anyway if he wants to. If enough > >trustees post KEY_BLOWN, they get a different (stronger) page. They > >can > >access the target if they want to, but only by manually copying a > >non-hyperlinked URI to the location bar. If enough trustees have > >NEW_KEY, with the same key, and none have KEY_BLOWN, then we send a > >permanent redirect to the new RSK location, and then process that. It > >must be an RSK. If the key is blown and there are enough votes for > >a new > >key, then we present the user with the key blown page, and with the > >new > >link on the bottom. > > > >The node will provide a reasonably easy way to post a revocation, via > >the web interface, and via FCP. > > > >Comments? Any way we can improve this? > >-- > >Matthew J Toseland - toad at amphibian.dyndns.org > >Freenet Project Official Codemonkey - http://freenetproject.org/ > >ICTHUS - Nothing is impossible. Our Boss says so. > >_______________________________________________ > >Devl mailing list > >Devl at freenetproject.org > >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > > iD8DBQFEbg3EQtgxRWSmsqwRAkwCAJ9UyGRvZIIZ2qJM0/qSS7TbFWY6KwCeO+gm > HpJeHNs+uhlsVG0gtuHpr+M= > =9rBF > -----END PGP SIGNATURE----- > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060519/762b2879/attachment.pgp>
