Dave,
Everyone accepts (maybe some reluctantly and with high DKIM concern),
the *policy semantics* separation between the AUID and SDID from
RFC4871bis.
My exception is the incorrect extended assertions there is no DKIM
created binding association between the 5322.From and the signature
signed by SDID:
DKIM doesn't create any binding between the RFC5322.From domain
and the "d=" value
That is simply not correct. Its not like the signer (d=) has a choice
in the matter.
For some reason (perhaps out of DKIM-BASE scope), the SDID, as the
responsible signer, must bind 5322.From to the signature. Perhaps it
will help to describe the DKIM mandate to bind the 5322.From to the
signature signed by the SDID?
- Is it for some higher security reason?
- Is it because it is RFC5322 requirement also?
- Is it because its something the MUA will see?
- Is it to prepare some future Identity Assessor module?
IMV, all this can be solved by being straight with the DKIM Mail
Integration intentions, not with continuous *denial* there is an
unique 5322.From binding association with the signature. It may be
"out of scope" reasons, but a binding association nonetheless.
--
HLS
Dave CROCKER wrote:
On 4/25/2011 9:18 PM, Murray S. Kucherawy wrote:
Double listing in the "h=" tag can not fully mitigate risks related to
appended header fields when messages are signed by a different domain than
the domain found in the appended From header field.
DKIM doesn't create any binding between the RFC5322.From domain and the "d="
value as you're doing. What you're talking about here falls into the realm
of ADSP or other policy-like assertions, not DKIM itself which is the topic
of this draft.
Perhaps I am wrong, but I believe that this point has been made and re-made
enough times to warrant not making it again.
If someone participating in this working group continues to make that error,
they are unlikely to change. And the mailing list archive has more than
enough
evidence of clarifying this point; more is not needed.
d/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html