Re: [ietf-dkim] Base issue: multiple linked signatures

I don't think this can resolved until SSP is resolved and in many 
respect, this Linked Signature concept is related to SSP.
Quick examples:

1) Multiple signatures, linked or not linked, may be meaningless for 
strong/exclusive domain signature policies where 3rd party signings 
and/or mail "integrity issues" are not expected expressed via SSP.
2) Linked Multiple signatures allowed and expected by the primary domain
expressed via SSP.

etc.

In short, the primary domain must allow for its mail to be used in ways 
it might expect it to be used.
Just consider the possible decision process:

              1st party     2nd party   Linked?     Result

 VALID           YES          YES        YES        VALID
 VALID           YES          YES        NO         VALID?

 VALID           YES          NO         YES        INVALID???
 VALID           YES          NO         NO         INVALID?

 VALID           NO           YES        YES        VALID??
 VALID           NO           YES        NO         INVALID???

 VALID           NO           NO         YES        INVALID?
 VALID           NO           NO         NO         INVALID


To me, if the 1st party fails, then nothing else matters. But that might 
depend on the SSP where there be a Linked Signature Requirement 
attribute or flag.
Please keep in my mind that there needs to be a "benefit" or "payoff" 
for a wide adoption of verifiers to take place. Even of a system does 
not initially adopt SIGNING of mail, we might find that VERIFIERS might 
indeed be adding first verification before adding signing to the 
process.   The payoff needs to be shown via VERIFICATION first IMO.
---
HLS


DKIM Chair wrote:
> In discussions with the IESG to sort through their "discuss" comments, I 
> had a talk with Lisa Dusseault, and she had one point that I want to 
> bring back to the mailing list:  I don't think we considered, in our 
> discussions of multiple signatures, multiple *linked* signatures, which 
> could work TOGETHER to convey information, and the protocol doesn't 
> allow that sort of thing.  The way dkim-base is set up, I don't think 
> this could easily be added as an extension, and it'd be a significant 
> change at this point.  Here's the concept:
> * Signer puts on two signatures (maybe as two header records, maybe as 
> one that contains two sigs).
> * One of the signatures has minimal scope, maybe signing only "from:", 
> with l=0.
> * The other signature covers as much of the message as possible... most 
> headers, all the boby.
> * The two signatures work together.  If one verifies and the other 
> doesn't, the verifier can consider what was changed in the message, and 
> possibly use that information to deal with mailing list modifications or 
> whatnot.
> One way this might be used is to have one signature that covers the 
> subject header and one that doesn't, to allow the verifier to detect a 
> subject change and decide whether it's OK.  As the spec is now, the 
> verifier would just find the one signature (that doesn't cover the 
> subject) that works, and use that, not considering the other.
> The WG did discuss related things, so maybe we'll decide that this was 
> covered and dismissed, but it's a wrinkle that I want to make sure we 
> look at.  Let's beat this around for a week or so, and see where we are 
> with it, and what we do or don't want to do with it.
> Barry
>
> --
> Barry Leiba, DKIM working group chair  (leiba(_at_)watson(_dot_)ibm(_dot_)com)
> http://www.research.ibm.com/people/l/leiba
> http://www.research.ibm.com/spam
>
>
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html