> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of McDowell, Brett > Sent: Tuesday, January 11, 2011 2:33 PM > To: ietf-dkim@mipassoc.org WG > Subject: [ietf-dkim] RFC4871 interoperability conflict over "h= " tag > > (if this doesn't belong on this list, please let me know) > > RFC 4871 states: > > > h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to > > allowing all algorithms). A colon-separated list of hash > > algorithms that might be used. Signers and Verifiers MUST > > support the "sha256" hash algorithm. Verifiers MUST also support > > the "sha1" hash algorithm.
The "a=" value indicates a signature generation algorithm, and the definition of that algorithm indicates which hash (message digest) method was used as part of that algorithm. Thus, in essence, the "a=" in the message and the "h=" in the key have to line up for verification to complete. For example, if you send me a message signed with "a=rsa-sha1", then when I retrieve your key, I expect to see no "h=" value there, or a value that includes "sha1". > Interpretation #1: The sender must support both, but doesn't need to > use both. It could be h=sha1, h=sha256, h=sha1:sha256, or h=*. The > receiver however MUST support either. Therefore the receiver should be > not fail verification just because the explicit tag in the DNS record > says "h=sha1" instead of the "h=sha1:sha256" which is expected. You're saying a bunch of different things here: "The sender must support both, but doesn't need to use both." True. "It could be h=sha1, h=sha256, h=sha1:sha256, or h=*." True except the last, as "*" isn't valid by that tag's ABNF. "The receiver however MUST support either." True, inasmuch as "either" is a subset of "both". :-) "Therefore..." Depends on the signature. If the record says "h=sha1" but the signature says "a=rsa-sha256", I'd fail it. > Interpretation #2: The sender must support both, which means the > sender must either not have an h= tag in the DNS record (defaulting to > h=sha1:sha256) or it must explicitly list "h=sha1:sha256" and therefore > the sender should adjust their public key records vs. the receiver > adjusting their infrastructure to verify "h=sha1" (btw, this is for > messages that contain "a=rsa-sha1" in the DKIM-Signature header). I think you're mixing implementation with policy. The "h=" tag in a key record is an expression of policy that this key can only be used with the specified hashes. It is not a statement of what the signer implements. -MSK _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
