> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alessandro Vesely > Sent: Wednesday, October 19, 2011 4:07 AM > To: [email protected] > Subject: Re: [marf] New Version Notification - > draft-ietf-marf-authfailure-report-03.txt > > Not formally. Section 3.4 of RFC 6376 specifies canonicalization with > no mention of l=. OTOH, Section 3.7 says > > In hash step 1, the Signer/Verifier MUST hash the message body, > canonicalized using the body canonicalization algorithm specified in > the "c=" tag and /then/ truncated to the length specified in the "l=" > tag. [emphasis added] > > Does the definition of DKIM-Canonicalized-Body in Section 3.2.3 have > to specify that "the canonicalized body MAY be truncated to a length > greater or equal to the value of (the highest) l="?
I don't see how that emphasis is important. The canonicalized form is truncated by whatever "l=" says, if it's present. If two signatures use the same canonicalization and have the same "l=" value (or absence thereof), then the body canonicalization is the same. In any other case, they're different. For the common factoring you're after to work, you'd need a way to say "this canonicalized for applies to this set of signatures, but not the others". That sounds like it could get horribly messy. > > Actually in the context of the report, I would trust the report's > > A-R and none of the quoted ones. I know for certain where it > > originated. And in that sense, the "authserv-id" doesn't really > > matter here. > > I agree that it is sound to have the results of apposite checks in the > report's A-R. That really depends on how the report's A-R is going to > be specified. One possibility is to implement a meaning of "here's > why I'm sending this report". Such semantics would exclude, for > example, spf=pass if the reported failure is a broken signature. > Indeed, that's not relevant for debugging, and for generic policy > tracking it might be as good to know as, say, Received: fields. > > In any case, the contents of the report's A-R ought to be specified > and exemplified in the I-D, IMHO. Isn't it safe to assume any negative result in the A-R portion is the reason for sending the report? For example, if you give me one in this context that's "spf=pass dkim=fail", I'll know why you're sending it. Maybe you can craft an example that shows what ambiguity you're trying to resolve? _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
