On Aug 17, 2005, at 2:30 PM, <domainkeys-feedbackbase02(_at_)yahoo(_dot_)com>
<domainkeys-feedbackbase02(_at_)yahoo(_dot_)com> wrote
Jim Fenton wrote:
Don't you need to look at the localpart to determine whether the g=
constraint was complied with? If the answer is "yes, to determine if
they match, but I'm not going to do anything else with localpart"
than
we're in agreement.
Quite so. The localpart and g= are two of the inputs into the
verification
logic. The outcome is either "email is verified" or "email is not
verified". I
see that form of verification failure as comparable to a selector
lookup
failure or a malformed signature line.
Sure. For diagnostics reasons one may want a more fine-grained
explanation of
the verification failure, but in many cases one can only guess as
to the true
cause. Was it really a g= vs localpart mismatch or did some
"helpful" transit
MTA re-write the signature line incorrectly?
How the 'g=' key extension ends up being deployed is highly
speculative regardless of an error message. If the local-part is not
a function of DKIM, then removing this delegation artifact should not
impact DKIM results.
Creating an expectation that key delegation requires revocation when
abused, and entails a level of risk associated with the trust
conferred, this will discourage the use of key delegation. As DKIM
is currently structured, there is an incentive to abuse DNS when
deploying an inordinate number of user-keys. Part of this incentive
includes a lack of replay solutions.
There are a few things that could lessen concerns when removing
'g='. The obvious risk of not checking the local-part is that the
local-part name space may be abused. Perhaps a greater risk would be
the damage to the main domain's reputation should this trusted party
prove untrustworthy in perhaps many ways well beyond abusing the
local-part name space. A solution may be able to deal with these
concerns and with the domain assertion issue as well.
A different approach-
1: Delegated Keys should be within a sub-domain of the
administrative domain. (protects reputation)
2: Delegated Keys to poorly trusted entities should be restricted
to act only as a third-party signer. (explained later)
3: Assert a signature flag that prohibits additions of Sender, or
Resent-* headers. (simplifies domain assertions not bound to headers
and reduces the number of domain-wide assertions checked.)
To overcome the potential risk of local-part corruption, perhaps the
source routing syntax, or something similar within the pretty name,
could convey to the recipient in which name space the local-part
resides, when the 'third-party' flag is detected in the key. Assume
this syntax would be synthesized as part of the checking to avoid
disrupting email delivery, and stripped when submitted as well. This
process would be at the option of the MDA provider.
The signing domain is:
ad-agency.example.com
The from mailbox address is:
promotions(_at_)example(_dot_)com
This gets displayed as: (assuming MUAs still handle syntax.)
@ad-agency.example.com:promtions(_at_)example(_dot_)com
Non-header binding domain-wide assertions:
Email "purporting at some instance" domain checks-
1- Allows TP signing.
2- Allows sub-domain TP signing.
3- Disallows all TP signing.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org