On Oct 17, 2005, at 10:35 PM, Jim Fenton wrote:
Earl Hood wrote:
If additional roles will not, or cannot, be specified, I see no value
in signing unless you are the originating domain, where signer role
and semantics are better defined due to binding to originating
header fields.
There is little, to no, incentive for a domain to claim
responsibility
for a message that does no originate from its domain if it cannot
specify the role it played in the transmission of the message.
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"].
I see three roles being significant with signatures.
- Originating domain
- Resending domain
- Verifying domain
I also see rules that limit these roles to being the maximum number
of signatures allowed in a message. If the Originating domain is
present and valid, the Resending domain signature is used. If the
Resending domain signature is present, it is logged and removed. The
Verifying domain should never be allowed over the Internet. A
Verifying domain signature may add information to the message in the
form of additional headers that are signed. The Verifying domain may
decide to remove the Originating and Resending domain signatures at
that point to minimize replay risks.
If binding are established based upon the signing-domain and some
address, then the roles being played are indeed significant. The
best correlation in the case of bindings would be from the
Originating domain. Resending domain signatures may represent a list
server. This signature would serve as a name basis for white-listing
these types of third-party services that may require special
handling. These services should not use the Originating domain
signature when resending messages.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org