On Oct 24, 2006, at 9:54 AM, Stephen Farrell wrote:
Consider the following two policies:
X: "Every email has at least one signature"
Y: "Every email has a signature of type A and a signature of type B"
Now consider a recipient that only supports verification of
signature type A.
Consider the following attack:
Bogus message with signature of type B.
This message is consistent with policy X, it is not consistent
with policy Y. This means that if our policy language can only
express policy X it will not be possible to tell the recipient the
information it needs to know in order to determine that the
message is bogus.
Huh? The recipient doesn't support signature type B and will
therefore not consider the message signed. Same as if the message
were an unsigned forgery or a real unsigned message, or has been
mangled etc. So I don't see the benefit in the recipient finding
out (via SSP) that the signer does use B, if the recipient cannot
(cryptographically) check that the message is accompanied by such a
signature and not just some random bits in the correct format.
There are two elements checked when DKIM_BASE and DKIM_POLICY are
used to validate incoming messages. Once multiple signatures bridge
an algorithm transition, then DKIM_POLICY expressed somewhere can
remove doubt about which algorithms should be present. In practice,
any algorithm transition may take years and may also involve more
than one alternative.
In cases where there is doubt:
a) the user may be asked to sort through questionable messages,
rather than having them rejected outright;
b) deprecated signatures may be accepted, when a supported non-
deprecated signature should have been present;
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
