On Mon, Jul 27, 2009 at 9:18 AM, Matthew
Toseland<toad at amphibian.dyndns.org> wrote:
> - RSKs: Important sites, particularly those distributing executables, need a
> revocation mechanism. This can be emulated with HTML UI elements, but is
> clumsy and problematic due to the various different error messages.
Adding HTML UI elements on SSKs as the exist now has a major problem:
if Mallory obtains Alice's privkey, his first order of business
becomes inserting a new edition of the freesite that points to a
different revoke key than the one Alice gave Bob, thus preventing Bob
from revoking the site in a meaningful manner.
I suggest something like the following, based on a chat I had with
saces. The idea is to retrofit revocation capability onto existing
SSKs without changing how SSKs work or breaking existing client
software. There are probably lots of problems with the details :)
Create a new keytype, RSK at . This is treated exactly like an SSK
internally (ie a translation layer similar to USKs), but has several
differences. First, the namespace is different (mangled internally
somehow) so that "RSK at crypto/foo" and "SSK at crypto/foo" are different
keys. Second, the null filename is allowed ("RSK at crypto/" is a valid
key). Third, redirects are not allowed.
The usage is as follows: the RSK@ keyspace represents the revocation
files for the SSKs with the same pubkey / crypto key. The null
filename ("RSK at crypto/") represents a revoke for the whole keyspace
(key blown, etc). Non-null filenames ("RSK at crypto/foo") represent
finer-grained revokes for things like broken inserts (if you screw up
an edition of a freesite and haven't yet inserted the fixed version,
for example). I'm less certain I like the fine-grained revokes, but
I'm mentioning them anyway for completeness; the remainder of the
proposal would work fine with or without support for them.
If the RSK key is found, then its existence indicates that the site
has been revoked. It would contain, at a minimum, a message saying
who revoked it. If I'm creating a freesite, and want to distribute
revoke privs, I would generate a set of RSK binary blobs (which say
things like "revoked by Alice" "revoked by Bob" etc), and distribute
those to the relevant people. I could even generate several blobs for
Alice, with different pre-defined revoke reasons.
(Optional extension) The RSK key could also include a set of places to
look for further information. For example, a set of SSKs owned by the
people with revoke privs, which could be used to implement voting
rules or similar. Then, everyone would get a copy of the same blob
that basically says "revoked by someone, see these keys for details".
It could then specify eg four SSKs to check, with a rule that the
revoke is valid if any two of the four are found. This could also
implement revoker-definable reasons: I give Alice a revoke blob that
says "revoked by Alice, see this SSK for the reason".
Default settings for how to handle revokes are tricky. I propose that
the key-revoke ("RSK at crypto/") always be checked, and an error
returned if found by default. There would then be a force-download
option to allow clients to download the data anyway. File-specific
revokes ("RSK at crypto/filename") are less important, and offer more
censorship possibilities, so they should not be checked by default.
If a client is prepared to intelligently inform the user about them,
it would turn on the option to check them.
The logic behind prohibiting redirects is that this is not a
general-purpose key, and we want to make DOS or spam attacks as hard
as possible. Furthermore, any revoke message ought to fit in 1k.
This would need some changes internal to the node, but no network
level changes or datastore changes. Because RSKs are just a different
way of turning a pubkey + filename into a block ID, they are treated
exactly the same as SSKs at a network and datastore level; all the
changes would be confined to higher levels, much like USKs. Beyond
simple code complexity issues, it is important that rare RSKs be able
to hide amongst normal SSKs for security reasons.
There is an argument in favor of some lower-level changes, but I think
it is outweighed by the problems such changes cause. Basically, if my
node is in possession of a revoke certificate for a key, it should
never drop the revoke cert from its store while keeping the key it
refers to. Otherwise, it's possible for the revocation of a site to
be lost while the site itself remains accessible. Obviously, doing
this would require some sort of low-level special treatment for
revokes. However, I suspect that this is rare enough not to be a real
issue.
The major other thing this would require is support for binary blobs.
At present, there are no user-level tools to handle them. As I see
it, the minimum requirements are:
- The ability to create a binary blob for a key and save it, without
inserting that key. There would need to be a simple form wizard that
generated revocation blobs in a correctly-formatted manner.
- The ability to verify a binary blob and read the data it contains.
This would require also knowing the key it represents (AIUI, the blob
normally contains the routing key but not the decryption key, just
like the datastore). If Alice intends to revoke Bob's site, she
probably wants to first check that the blob she is about to insert
will do that (inserting the revoke for the wrong site would be bad).
When she receives the revoke blob from Bob, she probably also wants to
check that the revoke message says what Bob said it did. This
verification step needs to not actually insert the blob.
- And, obviously, the ability to actually insert a blob that the user has.
Evan Daniel
