On Fri, 14 Jan 2005, Douglas Otis wrote:
The point was not wanting to wait for a key to expire used by many
accounts. Such a key will likely be retained for more than a week to
ensure delivery of mail. A spammer could send themselves the various
spam they wish to distribute and, even if the account is closed, they
could send millions of copies of these messages from elsewhere and
receive confirmation until the expiration of the key. A spammer would
only need 50 accounts to continue their spamming for year by abusing the
signature. Without being able to immediately respond to a problem,
defending the signature's reputation or seeing a benefit from the use of
a signature would be made difficult.
I do not think this is quite correct. I really do not see a need for key
revocation service. All that is necessary is to either remove key record
from dns (or authorization server) or if you want stronger meaning that
the key actually got into wrong hands, we could engineer additional flag
saying that authorization record is for key that has been revoked.
You seem to be concerned that the authorization record would be cached and
as such it'll not be possible to immediatly see that its no longer valid.
While this is certainly a possibility, typically dns records are not
cached for quite that long (24 hours at most) so while they certainly
can use window of opportunity to send some email, I don't think this
will be a serious problem and reducing authorization record caching time
to say 6 hours can be done quite easily as well.
2nd situation you describe (if I understood) are replay attacks using mail
with existing signature used long time after here key itself has not been
compromised. For this I should note that existing signature should have
timestamps and expiration date after which authorizing it is no longer
recommended. And to prevent tempering both of those should be part of the
signed data - this is actually exactly what I have done with META-Signatures
since "+=" indicates part of signature header that is also in signed data
(as opposed to normal "=") and if you look at my specs they specifically
indicate that timestamp, expiration and signer address and three tags
that SHOULD be signed.
So again, could you explain why exactly do you think that we need a
revocation service for what are intended to be short-term signatures?
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net