[ietf-dkim] Base-02 //Deprecated Signature Version & New List

[Barry Leiba]

Douglas Otis said:
> There remains the issue describing a deprecated algorithm as being 
> ignored, which is identical to treatments for obsolete algorithms 
> (signature versions).  Perhaps there could be few minutes placed on the 
> agenda to allow an attempt to explain why this could become a problem.  
> The solution could be as simple as defining an optional c= tag 
> (concurrent requirement) in the key.

No, I'm not convinced we need to spend more time on it, I see no support 
for the idea that we should, and I see several people saying we shouldn't.

We decided a long time ago:
1. If a signer doesn't want to use an algorithm any more, it should 
simply not use it, and should cease publishing the keys that were used 
for it before.

2. If a verifier doesn't want to accept an algorithm any more, it should 
simply not accept it, and treat signatures with that algorithm as absent 
or invalid, depending upon how it chooses to interpret things.

3. We're left with the case where an algorithm is sufficiently 
compromised that an attacker can insert a valid signature with that 
algorithm, and yet the signer wants to keep publishing the public keys 
for a while because it's still within the reasonable verification time 
for some already-sent messages.  No one thinks this is a problem worth 
solving because the likelihood is low, the window is small, and the 
signer CAN resolve it by not publishing the key and letting the 
legitimate signatures that remain fail.


Unless there's more support for spending time on this again, it seems 
that Stephen and I agree that the issue is closed.

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba at watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam