Alessandro Vesely wrote: > On 17/May/11 20:17, Dave CROCKER wrote: >> The proposed change tries to move some of the processing into >> the parameter, and hence is not an interface specification (unless, >> for example, the goal is to tell the caller to truncate the body, >> rather than have the subroutine do the truncating. > > Yes, I put the remaining changes quickly and badly just to suggest > that, IMHO, there is room for improvement. In particular, hash-alg > looks like an overloaded function that can take two or three > parameters, but its definitions are hard to spot.
I am not proposing a change, but it may be stated as: More formally, pseudo-code for the signature algorithm is: canon-body = canon-alg(c-param, body-content limited by l-param) pvt-key = pvt-key-alg(d-param, s-param, from.domain) bh-param = body-hash-alg (canon-body, a-param) b-param = data-hash-alg (pvt-key, h-headers, a-param, D-SIG1, bh-param) signature = sig-alg (D-SIG2, b-param) Where D-SIG1 is the "pre-prepared" DKIM-SIGNATURE header with all the tag= params but without the body hash (bh-param) tag, D-SIG2 is the "pre-prepared" DKIM-SIGNATURE header with the bh-param but without the b-param (data hash) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html