Apologies in advance if this is the wrong place for this message - if it is and
you happen to know the right place, I'd be grateful for a correction.
I'm trying to implement DKIM as per RFC6376 and associated errata in my
mail server, but am having all manner of problems establishing clarity on
section 3.7 of the RFC.
I note in advance that I have read the erratum that corrects this part of the
pseudocode in section 3.7
data-hash= hash-alg (h-headers, D-SIG, body-hash)
to this instead:
data-hash= hash-alg (h-headers, D-SIG)
Question 1:
My first question is the exact meaning of this piece of pseudocode:
body-hash= hash-alg (canon-body, l-param)
Does this mean:
1: Pass the canonicalized body to the hash algorithm, then pass the value of
any l= tag to the hash algorithm as well.
-- or --
2: Pass the canonicalized body to the hash algorithm, restricting the amount
passed to the value of any "l=" tag.
>From the way the other two pseudocode items are written, (A) would seem to
be the correct interpretation, but that raises the question of what should be
passed - a binary form of the l= value? Or a string representation? And what
should be done if there is no l= tag at all?
Question 2:
I am puzzled by the reference to an item called "a-hash-alg" in the NOTE
part at the end of this section: "a-hash-alg" does not appear anywhere else in
the document, and since it has not been mentioned in an erratum anywhere
(as far as I could see), I assume it must have some specific meaning defined
somewhere else. Could someone direct me to a reference explaining this
term?
Question 3:
The main problem I am having is understanding exactly how the signing
process is meant to be handled: traditionally, you would either use your hash
algorithm (SHA-256 in this case) to generate a digest of the content, then
have your crypto library (OpenSSL in my case) generate a signature for that
digest. There are also "streaming" APIs available that perform the hashing
and signing as a combined task.
I would have assumed from the pseudocode that the intended action here
was to do one of the following:
* Pass d-domain, selector, and data-hash in that order to an SHA-256 hash
algorithm, then generate an RSA signature using the hash generated by that
process as its digest.
* Call a streaming RSA-SHA256 API passing each of the three items in the
correct order then finalizing the signature.
Either of these approaches *should* generate the same signature. The
problem comes from the NOTE section, where it says:
-- Cut here
When using such an API, the last two steps in the
algorithm would probably be combined into a single call that would
perform both the "a-hash-alg" and the "sig-alg".
-- Cut here
It is difficult to interpret this without knowing what "a-hash-alg" means, but
on
the assumption that it is a typo, that suggests that the pseudocode sections
"data-hash" and "sig-alg" would be rolled into one step -- but I can't see how
that could work, since "sig-alg" requires "data-hash" (which I understand to
be an actual hash result) as its input. The NOTE comment seems so at odds
with the two intended actions I described above that I am not sure which
approach is the one I need to take.
I have spent quite some time trying to perform internet searches to clarify
this
section, but it's historically something I do quite poorly, so if there is a
nice
clean explanation of this somewhere, I'd be really grateful if someone could
send me a link to it.
I'm sorry to send such a long message, but hope someone will feel charitable
enough to help me out on these issues.
Cheers!
-- David --
-- David Harris -+- Pegasus Mail --
Box 5451, Dunedin, New Zealand | e-mail: david.har...@pmail.gen.nz
Phone: Number provided on request only.
Things the newspapers could have said better, #997
"Mr Benjamin Porter visited the school yesterday and lectured
on "Destructive Pests". A large number were present."
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
