On Jun 2, 2009, at 2:38 PM, Jon Callas wrote: > > The only use I can see of it is the case where you have many live > messages out there, some of them with (e.g.) RSA and others with > (e.g.) ECDSA and you want to make all RSA messages start failing > now, and yet for some reason want to keep the RSA keys still in the > DNS.
This does not represent the intended use the key's algorithm list. While currently most receivers recognize rsa-sha256, they may not recognize ecdsa-md6. Removing indications of currently used algorithms by the key for a particular domain will allow bad actors to take advantage of a transition period. Receiving MTAs may make exceptions for ADSP when ecdsa-md6 is recognized as a valid, albeit unsupported algorithm. Rather than rejecting the message, it might be marked as having an unsupported signature algorithm. By having the key indicate specifically which algorithms are in current use, then algorithm exceptions do not need to extend across all domains. Just domains indicating the use of the newer algorithm should receive an exception indication. Just as in the days of base64 encoded messages, a post- process can be used to confirm the validity of messages having a newer algorithm signature. This post process check could even be offered as a web based service. Without this feature, people may soon find their inbox flooded by bogus messages indicating the use of new algorithm, that could have been mitigated extensively by having the key feature. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
