On Jun 11, 2008, at 6:07 PM, Frank Ellermann wrote:
Douglas Otis wrote:
[skipping the parts we have now repeated often enough]
After all, the goal is to finish the ADSP, ASAP. : )
Sometimes I wonder what the goal here is. Looking into
it reinvents RFC 3834 without referencing it, it has a reference to
RFC 1894 obsoleted by RFC 3464 *five* years ago, and still talks
about ASP instead of ADSP.
Using [FWS] in DNS records is also broken by design, unless the goal
is "experimental" havoc.
Adding to this, Murray Kucherawy's draft captures the i= (identity)
parameter and a worthless s= (selector) parameter. The s= parameter
offers little value since the d= (key domain) parameter is missing.
Only the d= parameter (upon which the s= parameter rests) represents a
domain validated by a verified signature. An identity parameter can
include any number of virtual or wildcard domains below a key domain.
The d= (key domain) ensures reputations consolidate upon a controlling
entity. Basing reputation upon either the i= or the s= parameters
would permit senders an easy ability to fabricate an infinite number
of such tokens. Such diversity will thwart efforts at establishing
reputations. Basing reputation upon the key domain essentially means
a sales department can not spam with impunity while using the same key
domain. This has been clarified in the otis-dkim-adsp draft.
Restricting the i= in the ADSP draft is also a mistake. When a domain
attempts to accurately indicate on whose behalf the signature was
added, the identity might not be that of the Author. In which case,
even signing all messages would not satisfy a CLOSED ADSP practice.
It should be possible for the identity included within the signature
to be opaque and perhaps derived from an account granted access, and
not necessarily be either ambiguous or affirm the identity of the
Author. Otherwise, the only work around for remaining compliant
involves adding multiple signatures. Necessitating ambiguous (on
behalf of) signatures will also thwart dealing effectively with intra-
domain abuse. When unrestricted signatures are added to a message,
receiving hosts should expect the message conforms to the key domain's
Excluding the i= parameter as a component of ADSP compliance ensures
greater interoperability when DKIM signing is by MTAs. However,
messages signed with g= restricted keys should not be accepted when
the identity within the signature is not that of the Author. Refusals
of local-part restricted messages should not be conditioned upon
receiving hosts first obtaining an ADSP records. Local-part
restricted keys permit signing on behalf of a specific identity, where
this identity should always represent that of the Author. Otherwise,
not imposing this limitation as a general rule allows circumvention of
the anti-spoofing protections being sought. This is an issue
independent of ADSP as well.
NOTE WELL: This list operates according to