On Jul 14, 2005, at 11:29 PM, <domainkeys-feedbackbase02(_at_)yahoo(_dot_)com>
wrote:
--- Earl Hood <earl(_at_)earlhood(_dot_)com> wrote:
There should be some way to indicate that a key has been revoked.
It seems right now, revocation is indirect, by removing the
appropriate
DNS entry. However, a verifier does not know if the key was revoked,
temporarily unavailable, or never existed.
Hmm. I'll have to swing back on the draft, but at one stage the
plan was to use
the DK revocation method of continuing to advertise the Key RR with
an empty
public key value.
Would that satisfy your concerns regarding explicit revocation?
Revocation could be seen related to the replay issue. When there is
a large domain sharing the same key among many users, such key
revocation creates problems. Having a key per-user creates different
and perhaps equally serious problems. Revocation by modifying or
removing the key also requires short TTLs for the DNS record, which
exacerbate the effect of using a large number of individual keys.
In the mass-reputation draft, I suggested the optional use of a
u=<revocation-identifier> in the signature header to provide two
benefits. One benefit would be for the reputation service, where
there would be a means to identify abusive sources on the large
domain that consolidate any number of abusive messages, and to see
these accounts being handled by the providers. The other benefit
prevents there being a conflict of interest with respect the same
independent entity providing finger-prints on replay messages, and
domain reputations. The revocation-identifier would enable each
provider to establish their own individual account revocations,
without relying upon third-party threat information.
It is already common for providers to identify accounts using some
opaque manner. Adding the u=revocation-identifier offers a means to
standardize this technique. This would enable a means to eradicate
one of the most troubling problems plaguing email. There are methods
that can both inhibit replay attacks and lessen the overhead needed
to address the replay issue as well as protecting the network resources.
-Doug