ietf-dkim
[Top] [All Lists]

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

2006-07-09 17:37:47
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(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)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.





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