(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.
We have a DKIM-signed mail stream that is "passing" with Receiver1 but failing
with Receiver2 and it's Receiver2 who has a "new" interpretation of the
requirement above. Here are the two interpretations, please let me know which
is generally considered correct (of if both are wrong):
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.
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 may have provided both too much and too little information, but this is the
interoperability problem we are facing at the moment.
Comments?
Many thanks!
-- Brett
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html