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
