From: "Paul Hoffman" <phoffman(_at_)proper(_dot_)com>
At 4:54 PM -0800 3/30/06, Jim Fenton wrote:
I'm concerned that including verification results is going to
introduce a whole bunch of new semantics (and possibly transitive
trust) to the multiple-signature case.
I am hearing a whole bunch of push-back and no support for the
verification passthrough. Unless support appears in the next few
days, I'll revise the proposal to remove it. I'll also change the
"simple canonicalization" as well.
I'm sure I'm not telling anything you don't know, but it seems to me this is
not a weekend crowd. Most input seems to be only during the weekdays. So
your deadline should be atleast Tuesday or Wednesday. :-)
Anyway here is my input:
In all honesty, I had a relatively hard time understanding the main issue
and proposal you made when I think that there needs to be more system
engineering here in regards to considering how SSP can help the process.
I think the overall goal is to "maintain integrity of mail distribution" in
the current mail infrastructure and to determine what are the minimum change
requirements in order to make DKIM work.
In other words, SSP helps define what your proposal should state.
Examples:
o Exclusive Signing Policy (SSP draft, o=!)
o No Mail Expected Policy (SSP draft, o=.)
o Weak Signing Policy (new proposed SSP, o=?)
o No Signing Policy (No SSP record - conflicts with BASE-00)
To maintain integrity, these will dictate how additional handling and
distribution of the mail *SHOULD* be done.
A complaint middleware, regardless of type and purpose, MUST NOT:
- RESIGN, nor
- ADD, nor
- STRIP
without violating the integrity and consistency of the protocol methodology.
If this is to be allowed, then the SSP for the domain must change to
something less restrictive such as the next domain SSP declarations.
o Neutral Signing Policy (SSP draft, o=~)
o Strong Signing Policy (SSP draft, o=-)
These two policies allow for additional signatures to be present. So once
again, in order to maintain the integrity and survival of transports, the
middleware must adhere to the domain signing policy.
In this case, for NEUTRAL, which says no signature is required, a middle
ware now has the design options to offer:
- Skip adding signature (passthru)
- Optional, add 3rd party signature (3PS).
- If adding, optional to remove original
However for the STRONG policy, the designs options are now:
- Skip adding signature (passthru)
- If Body Content will change, Add 3PS.
Much will depend if the middle ware is going to break the body content.
NOTES:
1) The current specs defines EXCLUSIVE in a manner that suggest
additional signatures are allowed but must be ignored. I have
a conflict with this policy semantic.
2) WEAK was proposed by Arvel.
3) No (NONE) policy conflicts with BASE-00 "standalone usage"
since having no SSP record fallbacks to a "NEUTRAL" policy.
It is highly probably that many domains will use DKIM with the
help of SSP to declare domains that have no association with
mail or no have no expectation of signatures. In short, we
need a SSP o= tag value that says "NO SIGNATURE EXPECTED" for
this domain.
Anyway, to me, I find it very difficult to discuss protocol semantics in a
non-SSP environment. It makes everything extremely more difficult, more
chaotic, more ambiguities, too many implementation issues. If middleware
authors or resigners are going to have to change code to support your
proposal, I find it difficult as to why not also add SSP logic to help the
process for the middleware. The last thing middleware authors want to do is
bring the integrity of DKIM mail. If its made too difficult, then they may
opt to ignore DKIM, putt on the idea of dealing with adding new signatures,
and if they break the integrity, the blame is no longer on the middleware
but on the domain owner for allowing risky mail to be put thru their system.
That's my input on this.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html