[ietf-dkim] Base issue: multiple linked signatures
stephen.farrell at cs.tcd.ie
Thu Jan 4 07:34:17 PST 2007
You are repeating yourself, yet again. As far as I can see
all this was raised by you before and none of it achieved
Feel free to try convince Barry and I otherwise, *off-list*,
but please do not continue to try to reopen closed issues
on the list.
I see all this as being covered by issues 1265, 1272 (raised
by you and accepted), 1274, 1285, 1288 and probably others
(I got bored in the issue tracker). I see no WG consensus to
re-open those issues.
PS: I repeat, please feel free to convince us that there's
something new here, but not on the list.
Douglas Otis wrote:
> 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).
More information about the ietf-dkim