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: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
