John Levine wrote:
That's not quite what we had in mind. As I see it, 3rd party signing
is only acceptable when the domain owner wants to permit it --
It would be possible to design a system in which domain A says that it
endorses domain B's signature on mail with an author address at A, but
if you dig through the list archives, you'll find that we rejected
that expansion of SSP quite a while ago.
hmmmmm, I don't believe that is true John. I think you are reading your
own adaptation where stripping down SSP-01, removing such Verifier
Accepable 3rd party Signature semantics from the spec, relabeling it ASP
does not make it "while ago". I think I am fairly certain ASP is only
week or so old.
Anyway, while there were various proposals and ideas not everyone was
tickled pink with, it was quite clear the concept was feasible enough to
get written in stone in SSP-01:
2.11. Verifier Acceptable Third-Party Signature
A Verifier Acceptable Third-Party Signature is a Third-Party
Signature that the Verifier is willing to accept as meaningful for
the message under consideration. The Verifier may use any criteria
it deems appropriate for making this determination.
3. Operation Overview
..
2. All messages from this domain are signed. Messages containing a
Verifier Acceptable Third-Party Signature MUST NOT be considered
Suspicious.
NON-NORMATIVE RATIONALE: Third-party signatures, since they
can potentially represent any domain, are considered more
likely to be abused by attackers seeking to spoof a specific
address. It may therefore be desirable for verifiers to apply
other criteria outside the scope of this specification in
deciding to accept a given third-party signature. For
example, a list of known mailing list domains used by
addresses served by the verifier might be specifically
considered acceptable third-party signers.
And in RFC 5016, it goes as far as using suggesting DNS CNAME techniques:
6. Because DKIM uses DNS to store selectors, there is always the
ability for a domain holder to delegate all or parts of the
_domainkey subdomain to an affiliated party of the domain
holder's choosing. That is, the domain holder may set an NS
record for _domainkey.example.com to delegate to an email
provider who manages the entire namespace. There is also the
ability for the domain holder to partition its namespace into
subdomains to further constrain third parties. For example, a
domain holder could delegate only _domainkey.benefits.example.com
to a third party to constrain the third party to only be able to
produce valid signatures in the benefits.example.com subdomain.
Last, a domain holder can even use CNAME's to delegate individual
leaf nodes. Given the above considerations, SSP need not invent
a different means of allowing affiliated parties to sign on a
domain's behalf at this time.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html