ietf-mailsig
[Top] [All Lists]

Re: Good as the enemy of OK

2005-01-18 11:40:28

On Mon, 2005-01-17 at 18:17 -0800, william(at)elan.net wrote:

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,
basically its the same as #1 and provides no added security when its
possible for you to quickly revoke the key.

Curtailing abuse of the mail signature was to use per-user-keys.  The
TTL on these keys would need to be rather short, if to be effective
within a short period of time.  (The use of a fingerprint rather than
the full public-key would help reduce some of this traffic and the
resulting cache.)  The rate abusive messages can be sent requires a
rapid reaction if to be effective at thwarting this technique.

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 certificate 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.

The key, albeit shorter lived, has even greater opportunity for being
abused.  It only requires the simple sending of a message and the damage
can be rapid via this electronic medium.  That is far less effort than
stealing or cracking a certificate.  While some may view this signature
effort to be only useful for anti-phishing efforts, the signature also
offers the opportunity to defend use of the domain for large providers
as well.  The efforts needed to scale a per-user-key defensive strategy
would be prohibitive, and actually make revocation take longer.

A revocation mechanism may not be needed for tightly controlled
environments, but would be needed for large providers.  Should there
ever be a need to include this feature, using the negation or blackhole
approach would involve a much smaller effort and be much less
disruptive.  I think it could be added to either of the current
proposals.  

-Doug





<Prev in Thread] Current Thread [Next in Thread>