Eliot Lear wrote:
On 6/1/09 6:38 PM, Steve Atkins wrote:
I would assume that if it were added back it would look exactly like it
does now, but with some additional options other than "rsa".
Adding k= back or extending it to support other options would
both require RFC level effort, so I'd expect anyone doing that
would do the research on the history (or, more likely, be on
this mailing list right now :) ).
The problem is that it is almost a certainty that it won't be "if" but
"when". Why make work? This goes to Russ' point about algorithm
agility. On the other hand, I agree that having options with only one
value invites hardcoding and improper processing. Perhaps Russ would
like to comment further?
Let's make sure everyone is in synch about what is being proposed:
The suggestion is to drop a tag from the *DNS record*, /not/
from the *DKIM-Signature* header field.
What is the benefit of having the DNS record list possible algorithms?
A protocol like this has specification language that says "everyone MUST
support
algorithm P and MAY support other algorithms. When the data arrive, they
contain an indication of what algorithm has been used for this data."
The "MUST" ensure basic interoperability. The "MAY" permits extensibility,
based on mutual agreement. Requirements for supported algorithms can be
extended by enhanced specifications "MUST support algorithms P, Q and R".
It does not really matter how many algorithms are referenced in the
specification or how many might be in the future. The list is in the
specification. And the arriving data declare which algorithm has been used
this
time.
But what utility is there in having a signer list in an external record the
algorithms they might choose to use? Absent this justification, there is not
"when" for needing the feature.
As I recall, the argument in favor of this tag in the DNS was a security
concern
that a message might arrive with an "unauthorized" algorithm. For myself, I
was
never quite clear what actual threat this represented, in terms of feasibility,
likelihood or severity.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html