On October 17, 2005 at 22:35, Jim Fenton wrote: > A domain can certainly assert its role, by signing a header such as > Sender or Resent-From that has a relationship with the signer address. > The questions (for me) have been (1) Can the verifier rely on an > assertion of role by the signature [no, unless you know that the signer > is reliable], and (2) Must a signature assert a role in order to be a > valid signature [I would argue "no"].
The intrinsic operation of signing causes the signer to assert some kind of role, otherwise signing is meaningless. The question is what the role is. In the general, the role is a responsibility party. Without more information on what the real role of the signer is, the level of responsibility is either unknown or a constant (as defined by the community). If the later, then you limit domains' motivation to sign since some domains may not want to claim the level of responsibility asserted by the community. For example, a pass-thru forwarder may not want to claim the same level of responsibility as an originating domain. Doug's recent list of roles is more useful, allowing different levels of responsibility based upon those roles, and subsequently, different classifications for reputation and accreditation. As for signing a specific header, this alone asserts nothing since the signing of the header can just be for message integrity purposes versus any role assertion. To make the role explicit, a tag can be defined by the signer to list which header field identities it is asserting a relationship with (versus the always Sender/From as currently defined). For example, a signer may want to assert a relationship with the Resent-Sender and _not_ Sender, something useful for messages resubmitted into the transit system by an end-user. The SSP check would be based upon Resent-Sender and not Sender. The (modified-from-currently-defined) SSP check can be used to reliably determine if the role asserted is valid or not. --ewh _______________________________________________ ietf-dkim mailing list http://dkim.org
