CODEWITHSUNDEEP
emaildkim
karamba
karamba

Reputation: 1

An ambiguos part of DKIM specification about header hash

I'm trying to sign email messages according to DKIM specification. I'm reading RFC 6376 and see there relatively straight way to create the signature, but there is a problematic part about DKIM-Signature header's tag b.

As I understand, it's value should be a base64 encoded signature of a hash, that is calculated against selected message headers, including DKIM-Signature, but without a value of the tag b. If it's correct, then I have some trouble understanding RFC here:

The header field MUST be presented to the hash algorithm after the body of the message rather than with the rest of the header fields

Here the RFC speaks about DKIM-Signature header. The text is from the chapter "3.7. Computing the Message Hashes".

If I understand it correctly, then it means I must calculate a hash of a block, which includes full message body, with the DKIM-Signature header appended to it's end (variant 1). But as I read in other sources, including answers here, it seems (because there's no clear algorithm in other sources) that DKIM-Signature header should be appended to the end of a list of message headers, that are selected for the hashing (variant 2). Then the ambiguity is: which variant is correct?

And finally, after 2 hashes are calculated, should I sign the second hash (hash of headers after disambiguation of a correct variant), as it seems things should work, or should I sign just the list of selected (and canonicalized) headers?

A common sense tells me that variant 2 should be the actual choice, and signature should be applied to the second hash, but I'm in doubts.

Upvotes: 0

Views: 497

Answers (1)

Kaspar Etter
Kaspar Etter

Reputation: 3518

The pseudo-code for the signature algorithm in RFC 6376 is wrong. It was corrected in Errata 5252:

   body-hash    =  hash-alg (canon-body, l-param)
   data-hash    =  hash-alg (h-headers, D-SIG)
   signature    =  sig-alg (d-domain, selector, data-hash)

What it means is that you first hash the canonicalized message body up to the length specified in the l parameter and then include this hash in the bh tag of the DKIM-Signature header field. Afterwards, you start a new hash with the header fields as specified in the h tag and canonicalized according to the c tag (an empty string is included for non-existent header fields, so that adding these header fields later on invalidates the DKIM signature) followed by the DKIM-Signature header field which you are about to add without the b tag. The resulting hash is the one you sign. This means that your second variant is the correct one.

Upvotes: 1

Related Questions