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
