Phillip,
+1. Nicely Stated.
The DSAP draft does have this concept considered, but it see it as a "Nice
to Have" item.
In practice, we can sometimes underestimate what customers will want once
this is all in place. That does not mean all customers, but what I feel
might end up being an significant amount (or important amount) that will
like to have more control in not only what they sign but probably equally
and more importantly, who they will be targeting. The idea of blindly
signing mail with a "cross your fingers, hope its ok" security mindset is
odd to me as something my customers will want.
In practice, for us, when such "need or don't need" concepts come up,
customers nearly always say: "as long it is optional" and its not forced
down their throats, then if its easy to implement, then it should be
considered. I don't think this is an complex consideration.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Tuesday, August 29, 2006 10:57 AM
Subject: RE: [ietf-dkim] Reputation trusted layers is out of scope
From: Stephen Farrell
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Hi Phill,
Is that "exceptions" stuff a requirement that's been
discussed before? I don't recall it anyway.
It sounds a bit of an edge case, though, so I wonder if
there's broad support for that feature?
Its not so much a requirement as an attempt to demonstrate that the only
thing that the SSP policy need actually include is the statement 'A message
always contains at least n signatures'. I have already demonstrated that
this works fine for values of n from 1 to 5+.
What the exceptions stuff is intended to demonstrate is that we can catch
the edge cases as well, IF WE DECIDE WE NEED TO and address the case where n
is usually 1 or more but in certain exceptions n is zero.
My personal view is that this is not necessary and violates the 95/5%
rule. However I note that there are people who appear to be arguing that use
cases of this type are important. What I want to show is that we can have an
exceptionally simple policy record AND strong policy and that this model may
be extended IF NECESSARY to meet a very large number of edge cases.
Furthermore the 'simple but strong' approach makes a good case for the
DKIM record to be regarded as the master policy record for email since the
policy statement is vastly simpler and cleaner than SPF. All the policy
record states here is the set of security policies that are implemented for
outbound mail. We have no esoteric syntax, no bangs, apostrophes, percent
signs or stuff.
This is a policy record that is simple and clean enough that it is easy to
see how it can be extended to serve other protocols. Given the metasyntax
for the inbound policy I can pretty much guess what the outbound policy
statement would be for typical configurations (e.g. SSL)
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html