"william(at)elan" == william(at)elan net <william(_at_)elan(_dot_)net>
writes:
william(at)elan> I do not think this is quite correct. I really do
william(at)elan> not see a need for key revocation service. All
william(at)elan> that is necessary is to either remove key record
william(at)elan> from dns (or authorization server) or if you want
william(at)elan> stronger meaning that the key actually got into
william(at)elan> wrong hands, we could engineer additional flag
william(at)elan> saying that authorization record is for key that
william(at)elan> has been revoked.
The problem is that typically a key will be used to sign messages for
the entire domain.
I'me got some spammer using my key. He already has say 10 messages
signed; he can send those to as many recipients as he wants.
I notice the problem. Immediately I generate a new key and start
signing mail with it. However I'm left with two unfortunate choices:
1) Drop the old key immediately creating a problem both for the
spammer and for authorized mail I have in transit.
2) Waiting for my authorized mail to make its way through the system,
giving the spammer a longer time to send his spam.
As people have pointed out, per-user keys do provide some protection
against this attack.
I agree with you about this problem and the two choices you pointed.
But the original topic was on if Key Revocation service would help in
solving this problem and I don't think they can - you can choose to revoke
your keys but then your own email might be seen as being bad, basicly its
the same as #1 and provides no added security when its possible for you to
quickly revoke the key.
The reason for key revocation service for X.509 and S/MIME is because
those certificates are long-term (year or more) with expiration date as
part of the cerificate and certificate issuer and that those using
certificates do not check for each one if it has been issued or not.
So the only way to show which ones are no longer valid is through separate
service. But we do not have the same situation with MASS and key
revocation does not seem necessary.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/