On Thu, 18 May 2006, Tony Hansen wrote:
agreed. Is this better?
NEW: If there are
NEW: multiple query mechanisms listed, the choice of query mechanism
NEW: MUST NOT change the interpretation of the signature. An
NEW: implementation MAY use recognized query mechanisms in any
NEW: order.
No. My view is that interpretation of the signature might actually change
if more advanced data is available. Its only base check as to if the
signature data verifies or not that would not change.
As a crude example, one mechanism might provide you with list of valid
sites that are allowed to verify the signature (i.e. sites that are
expected to receive the messages sent) and the other mechanism does
not have this strange feature. Now using either of the mechanisms you
can tell if the signature data actually verified (i.e. find public key
as per current system), but according to the first mechanisms you must
consider signature to not have been valid if receiving end is not listed
i.e. its different interpretation. Now the software that does not want
to support these extra features might choose to still support its syntax
record but only use it in case its the only mechanism listed as supported
because first mechanism provides records that are generally too large.
Also here different example where data is not the same at all but
interpretation would be. Lets suppose that signature includes public key
in its header field's optional tags and one of the mechanisms allows to
get the public key as usual per DK (then you will simply verify that key
you have in the signature is exactly the same as key you retrieved) where
as another mechanisms provides fingerprint of the same key. If we assume
that all other data provided by both mechanisms is the same then the
interpretation would also be the same - so in theory the implementations
system may choose to retrieve both public key and fingerprint (which does
not make much sense to me to) but the signer could prefer to see them
retrieve smaller data from fingerprint and as such would list this mechanism
first. On the other hand there may be software that will purposely not try
fingerprint (unless its the only record) for whatever reasons.
So the choice of what mechanism to use and in which order to try them is all
really up to the verifying software and depends on the list of mechanisms
and features in those mechanisms that it wants to support. The signature
may provide a preference in the eyes of the signature creator but I do not
see that that preference going with anything better then SHOULD in the
specification (and SHOULD is probably too strong).
william(at)elan.net wrote:
On Thu, 18 May 2006, John Levine wrote:
NEW: If there are
NEW: multiple query mechanisms listed, the choice of query mechanism
NEW: MUST NOT change the interpretation of the signature. An
NEW: implementation MUST use the recognized query mechanisms in the
NEW: order presented.
I can live with either of these sentences, but they don't make sense
togther. If all of the mechanisms will give you the same answer, why
shouldn't I be allowed to send out all the queries at once and take
the one the comes back first? Or if new ones are supersets of old
ones, prefer the more informative one?
All mechanisms must allow you to actually verify the signature crypto,
but I think the point is that it might not give you the same answer if
one of the mechanisms is more advanced. What would be expected is
that those systems that are using newer versions of software will
know how to use these new mechanisms whilte older systems will just
ignore them and use the ones they know about. As to doing queries
in parallel - if you know two mechanisms give you the same answer
(i.e. one is not more advanced or its advanced features are not
used by particular implimentation), then sure, go ahead.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html