-----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 just don't think the use-cases that require voting, multiple trustees, and so on are really all that likely in practice. 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-----
