On Mon, Mar 11, 2024 at 6:50 AM David Harris <[email protected]> wrote:
> 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? > (2) It's a pseudocode function to which the value of the "l=" tag (if present) is a parameter. The result is a hash of canon-body; digest all of it if l-param is not present, otherwise digest the first l-param bytes only. > 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? > Looks like this is a typo, perhaps warranting an erratum of its own. It should be just "hash-alg". > 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. > The signature is the result of base64-encoding the RSA encryption of the data-hash. The data-hash is the result of passing the canonicalized headers, in order, to the SHA algorithm. The canonicalized headers include, at the end, the incomplete DKIM-Signature field that's under construction. You then append the base64-encoded form of that signature to the incomplete DKIM-Signature field and attach it to the message. In some cases (e.g., OpenSSL) , the call sequence would be: * create a digest object (one API call) * feed it the header fields and so forth, as described (N API calls, depending on how you do the work) * finalize the digest (one API call) * encrypt the digest using the specified key (one API call) Some APIs (e.g., GNUTLS, as I recall) provide a different interface, allowing you to do all of that in a single call. I believe the NOTE you're citing is just emphasizing that the four-step method and the one-step method are equivalent as far as DKIM is concerned; as long as what you end up with is an RSA encryption of the SHA digest, you have what you need. -MSK
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
