[ietf-dkim] Base issue: multiple linked signatures
hsantos at santronics.com
Tue Dec 26 09:21:28 PST 2006
I don't think this can resolved until SSP is resolved and in many
respect, this Linked Signature concept is related to SSP.
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.
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.
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
> 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 Leiba, DKIM working group chair (leiba at watson.ibm.com)
> NOTE WELL: This list operates according to
More information about the ietf-dkim