Jonathan Clark wrote:
Now if you put the new key under a new selector, old messages keep pointing
to the old selector, and new ones now point to the new selector, so there's
no point to having multiple signatures for this usage.
Ah. You mean if you've also deleted the old key record from DNS. Well,
yes, but during a transition where the same entity is signing twice, I
would guess that deleting the old key would be a bit counterproductive
in that case.
Well, you don't delete the old key until all the messages signed with it
have reached their destinations or bounced. From the point of view of a
sender who is changing keys, once the new one is in place (under a new
selector) you might as well switch to using it, there's no value at all
in still using the old key, and hence none in signing with both keys
(in this case).
Well, you may want to sign twice for an extended period, say if
sig1 is rsa-sha1 and sig2 is rsa-sha256 and it takes a year or more
before you're confident that a sufficient number of peers have
deployed sha256 verifiers. And of course, we do expect another
such transition in <5 years (starting when the new improved NIST
hashing process reaches its conclusion).
And there remain the list-related multiple signature cases as
well in any case.
Result: keys-per-selector and multiple signatures are, for us,
different issues.
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html