On Jun 4, 2009, at 4:32 PM, Murray S. Kucherawy wrote:
Disagree. This feature is about better informing recipients as to
the
status of the signature.
For the sake of enumerating implementations, the current libdkim
implementation does make a distinction between a signature that
failed to verify and one that couldn't be verified because the key's
approved hashes and the signature's methods don't line up and one
that simply failed DKIM verification.
So if I am to apply my earlier arguments, I have to support your
point because it puts more information in the hands of the assessor.
However, unlike x= and l=, I don't see any possible benefit in
making the distinction.
Whenever the DKIM key asserts the algorithm supported by the domain,
attackers are prevented from spoofing "unverifiable" signatures from
domains that have as of yet not made the transition.
For example, how can you tell an attacker that created a signing
algorithm of "rsa-whatever" from a site that accidentally posted a
public key with "h=watever"?
Consider the key's assertion represents a means to contain the level
of potential confusion that a algorithm transition might make.
Especially when being done within an exigent timeframe.
Are you sure you want to consider those as equivalent and apply the
maximum punishment rather than just treat the message as unsigned in
both cases?
It seems suitable to either reject or annotate a stern warning, those
messages where the domain refutes the algorithm claimed in the DKIM
signature.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html