[ietf-dkim] Base issue: multiple linked signatures

[Stephen Farrell]

Doug,

You are repeating yourself, yet again. As far as I can see
all this was raised by you before and none of it achieved
WG consensus.

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.

Stephen.

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).
> 
> -Doug
> 
> 
> 
> 
> 
>