On Jan 4, 2007, at 6:28 AM, Hallam-Baker, Phillip wrote:
That is a meta-argument.
At this point we have a last-call objection to close. 'We decided
differently' is not a valid move in a last call discussion.
If the point was argued and consensus reached there should be
someone who can give a rationale for MUST NOT as opposed to SHOULD
NOT.
The problem stems from a mandate to sign specific headers or require
that domains match within the 'i=' identity. Protection is
established by an association between the signing domain and an
originating entity digitally "recognized" by the recipient. The
mistake within the base draft stems from an erroneous
predetermination of which headers are to be signed and removal of an
ability to link headers containing different domains. "Repairs" can
not rely upon a signer making copies and thereby ignore recipient
recognitions, (the purpose of using different headers or perhaps even
"downgrading" headers).
The underlying premise used by the base draft is fundamentally
flawed. There is little if any protection afforded by a visual
recognition process anyway. The recognition process must be based
upon information held by the recipient. This approach means
protection is afforded by actions of the MUA or MDA. This could
exclude a transit MTA, unless protection identifies phishing attempts
by comparing message content against known valid signing domains.
Even that protection depends upon a type of recognition not covered
by any header, nor should this be limited to specific domain matches
either.
The base draft contains fundamental flaws with respect to a
protection strategy. Reconsider how protection can be afforded and
how private key sharing or zone delegation can be voided (an
expensive prerequisite that also removes normal freedoms).
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
