Folks,
The SSP thread on delegation is doing an excellent job of exploring the problems
with inventing a new delegation mechanism. What it is *not* doing is exploring
the benefits of using an existing one, instead.
The discussion is based on having SSP invent a means of declaring delegated
responsibility, so that some other operator's domain can create the signature,
but still permit using the author's domain for making assessments. Given that
email can go through re-postings, while retaining the same author field
(rfc2822.From) this creates a serious problem in determing whether the
"delegated" signature is legitimate, as Jim has noted.
One of the problems with having higher-level discussions that use terminology
that is based on underlying mechanism, is that it obscures its (higher-level)
intended use. So, "first-party" and "third-party" certainly have meaning, in
terms of indicating some indirection in the relationship among signatures, but
they do not really tell us what the issue is. The perspective is so mechanical,
it actually can confuse the "policy" discussion, I believe.
I am assuming that the real issue is whose domain name is supposed to be used
for evaluations:
Should the recipient use the author's domain or should they use (one of)
the operators' domains?
(Operator typically means someone who handled the message, but might mean a
signature by an independent assessment service.)
I assume that the term "first-party" means that the signature is provided by an
entity operating within the Administrative Domain (ADMD) of the author, and that
third-party means that the signature is provided by an entity that in an ADMD
that is independent of the author.
So, all of this concern about "delegation" is for ensuring that an operator ADMD
signature is known to be authorized by the author's ADMD.
To deal with this, we first have SSP invent a declaration of delegation and,
since this introduces the hole that Jim has described, we are now discussing
invention of an additional mechanism to fix the problem created by the first
invention. Methinks we should worry about additional mechanisms designed to fix
new mechanisms, as well as the likelihood that we will find ourselves needing
even more such fixes.
An alternative is to have *no* SSP mechanism for delegation.
DNS already provides a means of delegating.
Let's use it, as has already been discussed:
If author.com wants to make isp.com be authorized to sign on behalf of
author.com, then all that is needed is a DKIM entry for isp.com to use, under
author.com.
For example, imagine a signature made with the domain isp.author.com. The
author.com folks merely have to create a DKIM record under isp.author.com, and
give isp.com the associated private key. isp.com uses d=isp.author.com.
The site evaluating the signature sees that the signature and the rfc2822.from
field have "related" domains. Hence the signature is "authorized" and the
author.com domain is used for making further assessments.
At the very worst, the administrative effort this places on author.com is
exactly the same as we are contemplating for the new SSP mechanism. And it
eliminates the need for an SSP query about "delegation".
This mechanism already exists, is notably simpler than the one being discussed,
and does not suffer the security hole that has been noted.
Simply stated:
If the author's domain is to be used for assessment activities, then have
the signature be made with a domain that is directly related to the author.
If an operator's domain is to be used for assessment activities, then have
the signature be made with a domain that is directly related to the operator.
To explore this approach a bit further, I'm going to wonder about the supposed
need for an SSP check when a signature is present.
If a signature uses a domain related to the author's domain, then we have
no SSP issue. The author's domain is used for assessment. No SSP query need be
made.
If a signature is not present, THEN an SSP "I sign everything" record might
be useful (modulo the problem of surviving mailing list.)
If a signature is present, but is not associated with the author's domain,
then make the assessment based on the signing domain, not the author's domain.
Again, no SSP query is needed.
OK. Start shooting...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html