Thank you both for your input. To summarize... a receiver should not fail a message simply because the sender has "h=sha1" in their DNS and "a=rsa-sha1" on their signatures, even though that particular configuration isn't exactly expected by an acutely accurate reader of the RFC.
Yes? On Jan 11, 2011, at 6:30 PM, Murray S. Kucherawy wrote: >> -----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 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
