On Sat, 2006-04-01 at 09:04 -0800, Paul Hoffman wrote:
At 4:54 PM -0800 3/30/06, Jim Fenton wrote:
I'm concerned that including verification results is going to introduce
a whole bunch of new semantics (and possibly transitive trust) to the
multiple-signature case.
I am hearing a whole bunch of push-back and no support for the
verification passthrough. Unless support appears in the next few
days, I'll revise the proposal to remove it. I'll also change the
"simple canonicalization" as well.
There is an alternative option that flags signature roles
(primary/secondary, MSA, Mediator, and MDA with the w= option). This
would allow an MDA or Mediator to sign a verification header field and
not be confused with the signature added at the message's point of
origin, when from the same domain. For example, a list-server could use
an instance of an MSA that adds signatures in the role of Mediator.
Just a single signature for each role is permitted. This restriction
limits the extent of any amplification created evaluating signatures.
Prior MSA and MDA signatures would be removed by the MSA. Except by an
MSA, the MSA signature would never be over-written. The Mediator would
represent the only instance where a sequence of signature replacements
may occur. The simplest approach would be to delete prior signatures of
the Mediator role.
The dkim-option draft suggests rather than removing prior signatures,
the b= value is overwritten with verification results. The stepped-on
signatures could indicate which role, instance, sequence and whether the
stepped-on signature had verified.
The stepped-on signatures becomes:
"b=!<role>.<instance>.<sequence>.<verification>"
The highest instance of the stepped-on signature could be included
within the signed hash for that role (both primary and secondary)
according to the sequence.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html