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.
--On July 8, 2006 8:57:53 AM +0100 Stephen Farrell
Just on this one. I think the others are mainly done or fairly
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.
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.
NOTE WELL: This list operates according to