On 16/Oct/11 05:09, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: Alessandro Vesely
>>
>> Authentication-Results: authserv-id.example;
>> dkim=fail
>> header.d=DKIM-Domain-0.example
>> [email protected]
>> header.s=DKIM-Selector-0.example;
>> dkim=fail
>> header.d=DKIM-Domain-1.example
>> [email protected]
>> header.s=DKIM-Selector-1.example
>> header.b=MAynEEdThis/asWeLL==;
> [...]
>
> However, the canonicalized fields might need to be repeated,
> depending on whether different signatures use different
> canonicalizations or whether "l=" is in use. That's the
> complicated part.
Correct, I missed different canonicalizations. Body canonicalizations
are not signature-specific and at most two of them are needed, thus we
can get away with something like
DKIM-Canonicalized-Body: relaxed:
BLAHBLAH....
DKIM-Canonicalized-Body: simple:
blahblah....
Tag l= doesn't play, unless we want to report hashes too.
Instead, header canonicalization depends on both the h= and c= tags.
Quoting the sig-h-tag is cumbersome, and makes it difficult for
recipients to find the canonicalization they are looking for. A
possible solution may be to repeat the value of header.b, as a pointer
into the relevant signature
DKIM-Canonicalized-Header: 12345678:
BLAHblah....
If we don't need to optimize for reporting many signatures, we can use
the latter syntax also for the body, for the sake of uniformity.
Actually, we can as well use this syntax for any DKIM field.
>> The "authserv-id" token of the Authentication-Results field in
>> the second part SHOULD match the corresponding token of any
>> Authentication-Results field in the third part that was added by
>> the reporting verifier, and MUST NOT match the corresponding
>> token of any Authentication-Results fields in the third part that
>> had been added by some other verifiers.
>
> I'm not clear on why we'd need to say this.
Nor am I, honestly. I just point out that some similar consideration
ought to be addressed.
> Isn't the specification of the authserv-id already sufficiently
> clear, and it's obvious you'd need to use it properly and
> consistently for it to be meaningful?
Yes, you're right, RFC 5451, Section 2.3 says
The authentication identifier field provides a unique identifier
that refers to the authenticating service within a given ADMD. The
uniqueness of the identifier MUST be guaranteed by the ADMD that
generates it and must pertain to exactly that one ADMD.
But what are the relationships among authenticating service, verifier,
and reporter?
> Then again, if the recipient of this reports trusts who sent it,
> then the authserv-id doesn't really matter.
It's only use, AFAICS, is to relate the A-R in the second part with
one or more A-Rs in the reported message, which may be not obvious in
some edge cases. While the generation of debugging reports --those
sporting DNS RRs-- has to be integrated within the verifier, reports
sent for policy tracking purposes can also be sent by agents further
down a message's path. Policy methods, such as SPF, VBR, and ADSP,
are more plausible than DKIM for policy tracking purposes. A
reporting agent of this kind probably relies on existing A-R fields,
part of which it copies to the second part's A-R. However, it may or
may not wish to disclose the id(s) of those report-triggering A-R fields.
In that scenario, since RFC 5451's "authenticating service" may relate
to either the actual verifier or to a service that uses it, the
reporting agent is entitled to either reuse the authserv-id in the
message's A-R it relies on, or set its own unique id.
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
