-----Original Message-----
From: Rolf E. Sonneveld
[mailto:R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl]
Sent: Thursday, April 28, 2011 12:01 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary
Right. I strongly believe in the layered approach. However, that's
exactly the problem here. Like with IP and SMTP and any layered
application, the upper layer is dependent on what the lower layer
provides it with. If DKIM only enforces:
d= and
verification status
to be output, then the layered applications you describe (ADSP, domain
reputation, whatever) doesn't (always) have the means to do their job.
Or maybe they would have sufficient information if there was a single
DKIM signature present and all singletons are only once present in the
header.
But that's not true. ADSP asks the question: Did this message have a valid
author domain signature? The output of a set of "d=" names that verified is
sufficient to answer that question: Either the author domain is in that list,
or it isn't.
Since signatures can break for more reasons than you can count, the only
valuable signature is a good one. Thus, a reputation implementation should
only be interested in domain names whose signatures passed. The output thus
also satisfies that requirement.
The only utility in revealing failed signature information is forensics. That
sort of debugging function doesn't need to go in a protocol specification.
However, in practice we will see multiple DKIM signatures, with
possibly multiple From's. Which of the From's is associated with which
of the successfully verified signatures? For the d= payload, this
question is not interesting. But for the still-to-be-designed layered
applications, this question can become quite important.
There are three easy answers to that:
a) The specification presumes valid input, and warns signers and verifiers to
be sure that those rules have been observed.
b) If an application is presented two different From: fields and handed them to
DKIM, and the signature passes, the bottom one is the one that was signed. We
verify from the bottom up specifically to deal with the case where a message
has "m" signed instances but "n" total instances, where "m" is less than "n".
c) If an application is presented two different From: fields, it could just as
easily reject the message as invalid without even trying to apply DKIM to it.
From the design view of DKIM I know we should not want it, but what if
we would add the From address as a third _required_ output parameter?
With From: I mean: that particular From address that was used to verify
that particular signature for which the success status is handed over.
It's always the bottom one. (More generally, if the signer signed "n" of them,
and the signature passed, the bottom "n" of them were signed.) If you signed
the top one, verification will fail, unless they were both the same anyway.
As the From: address is mandatory input for the signature, it may be a
logical step to also make it mandatory in the output?
Given the above, do we still need to?
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html