SSP-02 does not provide a useful mechanism for coping with algorithm
transisions.
In a transition from algorithm A to B there will be the following conditions:
A set of receivers RA that only supports algorithm A
A set of receivers RAB that supports algorithms A and B and accepts both as
secure
A set of receivers RB that considers only algorithm B to be acceptably secure.
A set of senders SA that always sign with only algorithm A
A set of senders SAB that always sign with both algorithm A and B
A set of senders SB that always signs with only algorithm B.
Note that if the set RA is large, as will inevitably be the case at the start
of a transition any sender in the set SB will effectively lose the benefit from
DKIM. Equally insiting on algorithm B is not feasible unless the set SA is
acceptably small.
It follows then that the choices for senders are constrained by the deployments
of receivers and vice-versa.
At the start of the transition all senders and receivers will fall into sets SA
and RA by defnition. In this case the only viable choices are SA, SAB, RA, RAB.
Without the ability for a receiver to determine the type of sender they are
dealing with the following problems arise:
Attacker knows that receiver is in set RA:
Attacker can impersonate any sender in set SAB by inserting a bogus
signature for algorithm B that recipient cannot check.
Attacker knows that receiver is in set RB:
Attacker can impersonate any sender in set SAB by inserting a bogus
signature for algorithm A that recipient will not trust
It follows therefore that the system is DEADLOCKED without the ability for the
receiver to distinguish a sender in set SAB from one in set SB. No party can
ever upgrade their algorithm.
This situation can be remedied by allowing the sender to:
1) specify that multiple signatures are used.
2) specify a constraint on the DKIM selectors for each signature.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html