Matthew Toseland wrote: > When accessing the RSSK, the client will automatically fetch each > trusted person's SSK. Normally we will get a DNF on each of these. This > indicates success, and the result is that the node will follow the > redirect.
Are you sure it's a good idea to assume success if a revocation can't be found? An attacker might be able to temporarily DoS the revocations. How about this: the RSSK contains an expiry period (say, a week - the expiry periods must be long enough to allow for very loose clock synch). The user fetches each SSK, which contains a status field (OK/revoke/panic). If the status is OK and the SSK has been updated more recently than the expiry period, the vote is counted in favour. If the SSK can't be found or the status is revoke or the SSK is older than the expiry period, the vote is counted against. If the status is panic, the redirect is not followed. This method fails safe when publishers forget to update their SSKs, but the redirect will start working again as soon as they remember. It also gives publishers the option of destroying their keys if there isn't time to insert a revocation (reminds me of the old days on this list, with Travis Beman talking about attaching thermite to his hard drive... but anyway...) Cheers, Michael
