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(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html