On Dec 14, 2007, at 10:51 PM, Hector Santos wrote:
Hector Santos wrote:
Nevertheless, this breakdown should be adjusted to recognize that
an invalid signature is equivalent to no signature per the
specification.
It did. Read the message again.
More to the point Doug. The reason I showed it separate was to
illustrate there is a high confidence validation (non-repudiation)
when there a true no signature state versus the condition where the
state is artificially altered from a failed signature to non
signature. The later introduces less confidence where the former
yields full confidence. When you fold it, you have false positives.
In short, it makes the ALL and STRICT policies less reliable. It
weakens the policy.
Does that make sense?
Neither an "invalid signature" nor "no signature" offers a safe or any
significant difference for non-repudiation. Your assumption appears
based upon a invalid signature offering greater confidence in a
message source than would no signature. Giving a message with a
broken signature credit is a dangerous policy. Nevertheless, this
view seems supported by RFC 4781 section 4.2 Interpretation states:
"Signers SHOULD NOT remove any DKIM-Signature header fields from
messages they are signing, even if they know that the signatures
cannot be verified."
Section 4.2 is not clear that this prohibition on signature removal is
to be for issuing a "different" message from the one originally
signed. In addition, there are cases where a From email-address might
legitimately appear in a message which is either not signed, or signed
by a different domain. There is a practical aspect in regard to
credits and the potential for abuse as well.
When initially structured to give messages with bogus signatures
credit, this ensures DKIM will be abused in this manner. Removing
invalid signatures avoids being seen as a domain that "intentionally"
produces invalid signatures, and being categorized as a domain issuing
"bogus" DKIM signatures. Protecting resources needed to validate DKIM
signatures will likely need to avoid sources producing "bogus"
signatures. If this comes to pass, then Section 4.2 of RFC4781 would
be offering fairly poor advice. The mistake of giving credit to
invalid signatures ensures why not removing invalid signatures is
ultimately bad advice. Giving _any_ credit for an invalid or bogus
signature ensures a method for abuse. : (
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html