>> 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
