----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
Note that this is a security requirement. 'This is too complex' is
not a valid rebuttal, nor is claiming not to understand policy.
The requirement here is that it must be possible to specify a key
record for an algorithm that is not widely supported without
compromising the value of the policy record.
+1
Phillip, I have to reread your MALLET messages to fully understand the
problem description to see if I have considered this in DSAP I-D. Can I
ask if conceptually, does this touch base with the same security issue?
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html#anchor16
4.4. DSAP Tag: a=<hash-algorithm>
The a=<hash-algorithm> tag defines the possible signature hashing
algorithms used by the domain DKIM message signer. The a= tag is NOT
optional.
The current algorithms are defined in DKIM [DKIM-BASE] section 3.3.
o rsa-sha1
o rsa-sha256
Example:
a=rsa-sha1,rsa-sha256;
The main purpose of the a= tag is to allow domain signers the design
and implementation opportunity to determine the highest strength
possible by a particular target verifier by looking the DSAP DNS
record for the target recipient domain host. If this query results
with no a= tag information, the default should be rsa-sha1 is the
highest strength possible.
Essentially, this is a negotiation and backward compatibility
concept. It is quite possible earlier pre-standard DKIM
implementations supporting only rsa-sha1 may still exist. The domain
DKIM message signer's desire is to achieve the highest protection
possible. Instead of signing mail with a particular algorithm and
hoping for the best, the signer can predetermine what the receiving
system can handle in terms of hashing strength.
This verifier lookup concept is best utilize for high-
value domains in 1 to 1 transactions. It would not be practice
Mailing List resigners with large distributions to use this
concept.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html