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