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