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