Re: [Ietf-dkim] Question regarding RFC 6376

["Murray S. Kucherawy" <[e-mail]>]

On Mon, Mar 11, 2024 at 6:50 AM David Harris <[e-mail]>
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