On Jun 16, 2008, at 1:13 AM, Murray S. Kucherawy wrote:
On Thu, 12 Jun 2008, ietf-dkim-request(_at_)mipassoc(_dot_)org wrote:
Adding to this, Murray Kucherawy's draft captures the i= (identity)
parameter and a worthless s= (selector) parameter. The s=
parameter offers little value since the d= (key domain) parameter
is missing. Only the d= parameter (upon which the s= parameter
rests) represents a domain validated by a verified signature.
It's not worthless to an implementor or administrator interested in
figuring out why his/her mail isn't verifying properly.
And to resolve such issues, knowing which Key Domain is being used is
still important, but nonetheless ignored. If fact, the key domain is
likely needed to resolve issues for organizations that use sub-domains!
Any developer would love to have as much of the original data as
possible to reconstruct the failure scenario.
Your strategy appears to ignore the _least_ easily changed identifier
validated by a DKIM signature. Controlling resource costs for
collecting and distributing defensive information _requires_ stable
identifiers. Without some level of identity stability, any defensive
strategy will _explode_ due to enviable abuse. No database scheme can
scale to accommodate virtual identifiers that only exist within a
message!
Not everything in this working group is about crypto and security.
We implementors do sometimes think about other things.
While such a scheme might be seen as Sender friendly if adopted, this
would doom DKIM. Selectors devoid of the publishing domain offers no
value. To suggest otherwise would be in support of a false premise.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html