On Mar 2, 2007, at 8:23 AM, Hallam-Baker, Phillip wrote:
From: Douglas Otis [mailto:[EMAIL PROTECTED]
Without being able to specify the critical elements that must be
found within a superseding signature, there is no assurance that a
spoofed and unsupported signature has not replaced the stronger
algorithm. Spoofing could be accomplished by simply listing a
different query mechanism.
The question is whether the information is expressed in the policy
record directly or in some other form.
There have been several objections made to including algorithm
information in the policy record. I agree with them. Specifying the
same information in two places creates the possibility of
inconsistency. It means that the policy language needs to be much
more complex etc.
There are several ways in which the restriction can be specified
without including the algorithm information in the key record
directly. The simplest is to specify a lexical restriction on the
set of key selectors as proposed on the list.
The suggestion to include the superseded tag/parameter within the
deprecated key involves roughly the same level of complexity. This
could specify d=d/<selector> and accomplish the same thing. The
direct specification of the superseded tag/parameter will not depend
upon the use of DNS either. This would also leverage the information
already contained within the deprecated signature. It would not be
as onerous as all that.
Since there is possibly some ambiguity here I suggest ammending the
last point to read:
* In particular not require the policy record to
provide for the direct description of any
cryptographic or cannonicalization algorithm
I can agree with this statement, but it should not preclude a
reasonable method for specifying superseding algorithms either.
There should be less concern for the cryptographic signing and hash
algorithms, but other algorithms not even be specified within the
signature header may prove problematic.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
