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).
OK, I see that now. Doug also mentioned mail forwarding and listservs.
Result: keys-per-selector and multiple signatures are, for us,
different issues.
Thanks for convincing me. I'm glad we aired the one key per selector
business as part of this thread.
And I formally change my vote on "x=" to 'dump it' :-)
Jonathan
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html