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-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of McDowell,
Brett
Sent: Tuesday, January 11, 2011 2:33 PM
To: ietf-dkim(_at_)mipassoc(_dot_)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