ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Misc. fairly minor issues

2006-07-09 01:31:59

Hi Tony,

Tony Hansen 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.

I agree; the semantics of a DKIM signature had better not change
depending on which key query mechanism returned an answer.

Maybe we're talking at cross-purposes? (Or maybe not.) The fact is
that different instances of key servers will give different key
valid/invalid results when different verifiers query for the key
and its status. Even the DNS can do that with caching and/or
in the face of network problems. With some other types of server
there can be even harder cases (e.g. "onHold" from X.509 based
ones). That does change the signature result from say, good,
to presumably PERMFAIL, but is it a change in signature semantics?

Or, how about if the verifier, using X.509 based certificate
checking, has some certificate policies configured (those are
part of the certificate validation algorithm and will have
been processed inside the rfc3280 code in that case). I know its
a bit silly sounding but policyMapping extensions in intermediate
CA certs can then affect the certificate validation result.
This means that verifiers in some parts of the PKI (say outside
the US federal govt) will see the certificate as good, whereas
others (say those inside the US federal bridge CA domain) will
find the certifcate invalid. Several bridge CA setups do
actually use this kind of extension as it happens (not that
that's a good idea IMO, but its a fact, e.g. [1]).

Cheers,
Stephen.

[1] http://www.cio.gov/fbca/documents/altermanpaper.pdf


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