[ietf-dkim] Consistency among keys using q= alternatives

[Eric Allman]

Stephen, I think I see your point, but only up to a point.  It would 
clearly be bad (ludicrous) to have the signature work on a key from 
one server type and fail on a key from another server type.  I 
suppose we could delete the sentence in question because that 
scenario is clearly not in the best interests of the signer.

I guess this should go on the issues list for the meeting.

eric



--On July 8, 2006 8:57:53 AM +0100 Stephen Farrell 
<stephen.farrell at cs.tcd.ie> wrote:

>
> Just on this one. I think the others are mainly done or fairly
> easy.
>
> Eric Allman wrote:
>
>>>> #17 3.5 "q=" says that different mechanisms MUST NOT change the
>>>> interpretation of the signature. I don't think we can require
>>>> that since different key services (e.g. xkms, scvp) may have
>>>> different information about the public key s.t. one says its a
>>>> good key and the other says not. Just deleting  the sentence
>>>> should be ok though.
>>>
>>> Agree.
>>
>> I disagree.  If you list multiple key query mechanisms, and the
>> semantics change depending on which one gives you the answer,
>> isn't this  just asking for trouble?  If you want different
>> semantics, you should  have two separate signature header fields.
>
> That might be a good idea all right, but if that's the plan we
> should say it, and say when a new DKIM-signature vs. a new
> q= value is appropriate (a hard problem, IMO).
>
> Even so though, say if someone defines q=xkms to mean "ask your
> local trusted xkms responder for a valid key for this domain".
> Now say the key is revoked using an X.509 crl but word spreads
> slowly (which it can, via different local timeouts, nextUpdate
> fields, ocsp caches, etc.) so that different verifiers will get
> different results for some time period. Does that count as
> different semantics? If not, then what does?
>
> So given that there will always be grey areas here I'm not sure
> how we can get all signers to do the right thing.
>
> One other thing - what "trouble" are we asking for if different
> verifiers get different results? Seems like it'll happen anyway
> after signature verification (at higher layers), so its maybe not
> that much of a problem if signature verification can also depend
> on local things like which q= a verifier prefers.
>
> Stephen.
>
>
>