> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Alessandro Vesely
> Sent: Friday, October 21, 2011 4:40 AM
> To: [email protected]
> Subject: Re: [marf] New Version Notification -
> draft-ietf-marf-authfailure-report-03.txt
>
> On 20/Oct/11 20:16, Murray S. Kucherawy wrote:
> > So you're saying DKIM-Canonicalized-Body should always be the
> > complete body, and receivers of these reports should apply the
> > truncation based on the "l=" found in the third MIME part? That
> > seems a little convoluted to me.
>
> However convoluted it may seem, that's the formal definition that DKIM
> gives of the body canonicalization algorithms. Of course, both
> signers and verifiers know it is useless to canonicalize parts of the
> body that don't contribute to the hash. By skipping useless parts,
> they obtain the same result "as if" they had carried out a full body
> canonicalization and then truncation.
I agree that you can do it either way; the hash is the same through either
method. However, determining the "l=" (truncation point) for hash computation
by diving into the third MIME part of the report is probably not a good design.
To mitigate this, we either specify that DKIM-Canonicalized-Body is truncated
per "l=", or we have to add a DKIM-Canonicalized-Length field to tell the
report recipient where to truncate the canonicalized body when using the result
(or both, though that's redundant). I'd be fine with either.
> Report generators are in a different position, because what used to be
> an intermediate result is now visible. Pedantic programmers may
> conclude that they need to send the whole body by reasoning as I did
> above (uh... does that mean I'm pedantic?) You yourself adapted to
> write CRLF for an empty body, l=0 notwithstanding.
The implementation I have holds the canonicalized header and body in their
entirety, but the latter is truncated per "l=" if present. It handles "l=0"
and the empty body per the RFC.
> What I'm saying is that if we want it to be clear and indisputable
> that DKIM-Canonicalized-Body may/must be limited to the amount of text
> that contributes to the hash, we have to say so.
I'm fine with that; I think it's simpler, and it's extremely convenient for my
implementation. :-)
So I suggest the DKIM-Canonicalized-Body description be amended like so:
DKIM-Canonicalized-Body: A base64 encoding of the canonicalized body
of the message as generated by the verifier. The encoded content
MUST be limited to those bytes that contribute to the DKIM body
hash (i.e., the value of the "l=" tag; see Section 3.7 of [DKIM]).
Does that work for you?
-MSK
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
