,---
|4. Semantics of Multiple Signatures
|...
| When evaluating a message with multiple signatures, a verifier should
| evaluate signatures independently and on their own merits. For
| example, a verifier that by policy chooses not to accept signatures
| with deprecated cryptographic algorithms should consider such
| signatures invalid.
'___
The terms "deprecated" and "obsolete" have been defined for HTTP that
are fairly typical of other computer related definitions.
http://www.w3.org/TR/REC-html40/conform.html
An element has a status of "deprecated" when it will not be supported
some time in the future.
An element has a status of "obsolete" when support is currently being
withdrawn.
In this paragraph, the term "deprecated" should be changed to
"obsolete" to be consistent.
Currently DKIM lacks a defined mechanism to differentiate
"deprecated" algorithms. While one could insist distinctions of
supported/deprecated/obsolete are better done within a separate
policy transaction, such additional information should be conveyed in
conjunction with the key/signature information when possible to avoid
unnecessary overhead. DKIM already adds to the overhead, where
opportunities of reduction should not be ignored. When an algorithm
is considered "deprecated" (per the w3.org definition), there will
not be any advanced warning based upon the current DKIM draft. A
signer unhappy with protections afforded by what they consider a
"deprecated" algorithm can not clearly signal this. It may become
common for alternative services to be used for various recipients
where multiple signatures might become ordinary. A transition of
deprecated to obsolete by the signing domain may occur when the
verifier had not been warned and thus remained unprepared.
Although best done now, this signaling could be added sometime in the
future. Using consistent terminology at this time would be helpful
for these future definitions.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html