Charles Lindsey wrote:
BTW, would it be useful for a signature to contain some feature to
indicate whether it claimed to be a 1st/2nd/3rd/whatever-party signature?
I believe the following proposal was stamped as issue #1542.
http://mipassoc.org/pipermail/ietf-dkim/2008q1/008816.html
Understanding the sensitive nature of this, I will try to propose this
delicately.
Proposal:
DKIM signing domains who wish to implement restrictive signing policies
such as DKIM=STRICT or ALL and have a desire for verifiers to
aggressively handle this policies, SHOULD consider adding a SSP=STRICT
or SSP=ALL tag to the DKIM-BASE key record.
The goal is to reduce verifier DNS overhead by short circuiting the SSP
discovery steps 2/3 which is only necessary when the transaction state is:
a) valid 3rd party signature, or
b) no signature which can result from a broken signature.
The following sub-steps should be added to step 1:
1a) If we have a valid 3rd party signature or no signature resulting
from a failed DKIM-signature validation, and the key record
contains a tag SSP=strict, then the message is Suspicious and
the algorithm terminates.
1b) If we have no signature resulting from a failed
DKIM-signature validation, and the key record contains
a tag SSP=ALL, then the message is Suspicious and the
algorithm terminates.
If no SSP= tag is present in the DKIM key record, the verifier should
continue with step 2.
Discussion:
I believe Jim agreed that this would "reduce the number of SSP lookups a
bit" however, he felt this may be an implementation or deployment
consideration and/or we might review this after the initial SSP-01
specification is completed. He also correctly indicated with a less
concern, there would still be a need for an SSP record and now a dual
management of SSP; A SSP= tag for the DKIM key record, and a SSP record
itself. The policy in both places must match.
I agree with all Jim's point.
However, in the effort need to make SSP viable, acceptable, less
complex, its usefulness well understood for consideration, and
hopefully, we can get it to a point where everyone is the same page,
then considerations like this should be put on the table now.
If many domains (which I believe they will be many) will be considering
DKIM with the intent to operate in strict or all signing mode, we could
lose the opportunity to correctly and efficiently deploy the combination
of DKIM and SSP to everyone's benefit and satisfaction.
If we don't wish to consider this now, I can see an I-D proposing an
update to RFC 4871 to add the SSP=strict|all tag. Is that the better
approach?
Follow up comment:
This proposal will also help make this multiple From: issue a moot point.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html