----- Original Message -----
From: "Eric Allman" <eric+dkim(_at_)sendmail(_dot_)org>
To: "Mark Delany" <MarkD+dkim(_at_)yahoo-inc(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Monday, May 01, 2006 2:01 PM
Subject: Re: [ietf-dkim] Re: dkim-base-01 nits and semi-nits
My only concern is to ensure we're not prescriptive to a
verifier. Anywhere we say "reject" probably should be changed to
"treat as unsigned" as long as there is no implication one way or
the other as to what a verifier does with that "is verified" or "is
not verified" knowledge.
At some level I agree with you. But saying "treat as unsigned" is
just as prescriptive as "reject" --- either is telling the verifier
what to do. As a verifier, I may want to just outright reject all
messages that have unsigned content. It's probably not a good idea,
but someone somewhere will want to do it someday.
Eric, may I suggest a section totally devoted to defining what "invalid"
means and also instead of saying "reject" or "accept" say something like:
- negatively classfied
- positively classfied
It is like in SMTP, when say "send a postive response code" or "send a
temporary or permanent negative response code."
This is enough information for implementators to know what to do, and that
includes SMTP developers and also after market 3rd party software, i.e.,
reputation systems.
If we do want to make this more precise, I recommend that we have an
explicit list of signature states, e.g., GOODSIG, BADSIG, NOSIG,
PARTIALSIG (the l= case), SYNTAXSIG (syntax error in signature),
etc., and then leave the actual actions taken on each of these states
remain undefined in the -base document. That's probably a fair
amount of text changes, but most likely fairly mechanical.
Bingo!! +1!
This is where a section totally developed to Failure Definition and what is
expected by the domain can be added to it.
Lets keep in mind that we have SSP coming and DKIM needs to be consistent
with not blocking helper technology because there is no doubt in mind, DKIM
will need alot of help. :-)
In fact, I plan to offer an alternative to SSP called DSAP (DKIM Signature
Authorization Protocol). This will be published very shortly.
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-01.txt
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-01.html
Related to your classification idea, part of the proposal allows the signing
domain to define a policy for failure handling for the three general errors:
- Signature Authoriztion (fa=)
- Expiration, Revocation (fx=)
- DKIM signature error (fs=)
4.8. DSAP Tags: fa=<failure-handling>; fs=<failure-handling>;
fx=<failure-handling>;
The fa=, fs, and fx= tags define the domain preferred rejection
action policy a verifier is recommended to perform when an
unauthorized signature, failed signature or expired signature is
detected, respectively.
The fa= tag defines the handling for failed signature authorization.
The fs= tag defines the handling for failed signature verfication,
and the fx= tag defines the handling when a signature expired or key
is revoked.
Failed signature includes failured related to the DKIM-Signature
hashing, syntax and encryption verification process.
<failure-handling> values:
FAIL The verifer MUST reject the transaction when
failure is detected. (Default)
SOFTFAIL The verifer SHOULD reject the transaction when
failure is detected.
IGNORE The verifer MAY reject the transaction when
failure is detected. This value may be defined
by the domain to signify the domain is testing
DKIM and failure may occur unexpectedly.
However, this handler should not be tolerated by
verifiers and should be tracked for abuse.
The fa= and fs= tags are optional with default values of SOFTFAIL.
Examples:
fa=fail;fs=fail; fx=fail; Domain has a MUST reject immediate policy
for unauthorized, failed or expired signatures.
fa=fail; Domain has a MUST reject immediate policy for
unauthorized signatures and a SHOULD reject
immediate policy for failed and expired
signatures.
undefined tags; DOMAIN has a SHOULD reject immediate policy for
all failures.
fs=fail; fx=fail; Domain has a SHOULD reject immediate policy for
unauthorized signatures and a MUST reject
immediate policy for failed and expired
signatures.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html