Re: [Ietf-dkim] Question regarding RFC 6376
On Mon, Mar 11, 2024 at 2:04 PM David Harris wrote: > Thank you for taking the time to answer my questions - most appreciated. > > Your answer has addressed questions 1 and 2 for me. I'm still unclear on > certain aspects of question 3, though: > > [...] > > The pseudocode for "sig-alg" says: > > signature= sig-alg (d-domain, selector, data-hash) > > I took this as meaning that the d-domain and selector strings need to be > passed to something before the data-hash; the problem was what that > "something" was - I had been assuming that it was a third hash that was > then > signed, yet the rest of the section says (in more than one place) that > only two > hashes are required. > > Having read through your response, which describes the process as I was > originally expecting to follow it, I now wonder if this is another case of > the > pseudocode having confused me as it did in question (1)... Are we perhaps > intended to read "d-domain" and "selector" as parameters that are used to > choose the appropriate signing key, rather than as input to the signed > data > itself? > Yes. The d-domain and selector are used to compose the DNS name at which the verifier will look for the public key, so naturally that tuple also identifies the corresponding private key you need to use when signing. I suppose you could think of it this way as well: signature = sig-alg(private_key(d-domain, selector), data-hash) ...where the private_key() function yields the private key matching the (d-domain, selector) tuple. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Question regarding RFC 6376
Thank you for taking the time to answer my questions - most appreciated. Your answer has addressed questions 1 and 2 for me. I'm still unclear on certain aspects of question 3, though: On 11 Mar 2024 at 8:54, Murray S. Kucherawy wrote: > 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. The pseudocode for "sig-alg" says: signature= sig-alg (d-domain, selector, data-hash) I took this as meaning that the d-domain and selector strings need to be passed to something before the data-hash; the problem was what that "something" was - I had been assuming that it was a third hash that was then signed, yet the rest of the section says (in more than one place) that only two hashes are required. Having read through your response, which describes the process as I was originally expecting to follow it, I now wonder if this is another case of the pseudocode having confused me as it did in question (1)... Are we perhaps intended to read "d-domain" and "selector" as parameters that are used to choose the appropriate signing key, rather than as input to the signed data itself? Again, my thanks for your help. Cheers! -- David -- -- David Harris -+- Pegasus Mail -- Box 5451, Dunedin, New Zealand | e-mail: david.har...@pmail.gen.nz Phone: Number provided on request only. Sign seen in a Vienna hotel: "In case of fire, do your utmost to alarm the hotel porter." ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Question regarding RFC 6376
On Mon, Mar 11, 2024 at 6:50 AM David Harris 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 Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] Question regarding RFC 6376
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
