On 4/8/2011 2:29 PM, Paul Midgen wrote:
3.3: The rsa-sha256 algorithm is the default if no algorithm is specified.
Verifiers MUST implement both rsa-sha1 and rsa-sha256. Signers MUST implement
and SHOULD sign using rsa-sha256.
6.1.2: If the "h=" tag exists in the public key record and the hash algorithm
implied by the a= tag in the DKIM-Signature header field is not included in
the contents of the "h=" tag, the verifier MUST ignore the key record and
return PERMFAIL (inappropriate hash algorithm).
We have chosen a literal, perhaps rigid, interpretation that the key record
must fail validation if it implies lack of support for sha256, e.g. contains
"h=sha1;".
That said, it's reasonable for a signer to read the same sections and believe
it perfectly okay to implement but not advertise support for sha256. So we
have two problems:
I think all the salient points have been covered, but just to chime in and add
a
linguistic nit:
1. As Jim noted, implements means "in code", not necessarily "in use".
Operations choices are drawn from what is in code, but can be a subset. This
distinction is periodically a point of confusion when reading specs and I
suppose there is some way to prevent against it, but haven't seen language that
guarantees it, without being more verbose.
2. The h= mechanism is to protect against a bid-down attack. When looking for
what to strip from DKIM I thought it was a candidate until I understood this
purpose. I can be used for other reasons, but it's justification really is an
operational assessment of what's needed for adequate security.[1]
3. The spec cannot expect anyone's code to know about relatively strength or
preference among different algorithms. So the fact that someone does h=sha1
without sha256 is a strange choice it I'd strongly urge against having code
'know' that it ought to be ok.
4. "implies" linguistically wrong. The thing is stated explicitly, so
"specified" would be more like what it said.
d/
[1] As with all things email, customer complaints often trump good protocol
enforcement, of course.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops