The requirement attempts to make an implied rule about the flow of software
designs using a valid first party signature and implicit presumption the
policy is proper and/or has no bearing whether it is or not. Whether that
is true or not, it shouldn't be stated in a way that suggest it isn't
necessary from an *implementation standpoint*.
My first suggestion is to remove req #10, and as a perfect bonus add a
separate section, maybe title
1.1 Invoking SSP
with reasons why it may or may not be necessary. This is what's going to
help designers with their approaches. Because its a discussion on possible
optimization, which may include the statement "not required to be invoked
when a valid 1st party is found."
But overall, the key point is that invoking SSP is not just for SMTP
receivers but also other email related software as well, such as a List
Server and others applications where users will be asked for their email
address (atleast that is our plan).
So with that said, if we want some text, I might suggest:
1.1 Invoking SSP
How SSP is invoked is out of scope of the SSP requirements. The
design for SSP implementation and usage may vary depending on the
mail application. For example, a SMTP receiver may wish to invoke
SSP immediately to check for various policies prior to performing
the higher overhead DKIM-BASE has verification process. A LIST
SERVER may wish to invoke SSP as part of its subscription process.
It should be noted that valid 1st party signatures is considered
to be a sufficiently secured valid condition per DKIM-BASE
specification design goals which may allow for DKIM-SSP
implementators a method to short circuit SSP queries when 1st
party signatures are valid.
However, implementators should keep in mind, it is technically
possible for an inconsistent policy to exist even for valid 1st
party signatures. How implementators address this condition is out
of scope of the SSP requirements.
That's the best I can say it trying to wear a few different hats here.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "IETF-DKIM" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Tuesday, September 26, 2006 11:32 AM
Subject: Re: [ietf-dkim] New issue: Requirement #10 - Invoking SSP -
Suggestion to Remove this.
Hector,
It'd make it easier for the WG to make a decision (whether positive
or negative) if you could suggest text for such a new section.
Thanks,
S.
PS: A "MUST NOT be required" is the same as a MAY. Nothing militant
there at all IMO.
Hector Santos wrote:
Requirement #10 indicates:
10. The Protocol MUST NOT be required to be invoked if a
valid first party signature is found.
Suggestion:
Remove req #10, maybe add a new section that talks about the validation
value of 1st party signatures vs. 3rd party signatures.
Comments:
I don't get it this militant MUST NOT provision for a design decision.
The
statement makes it sound like its already written in stone that software
developers WILL invoke the protocol and the author is trying to STOP it
for
his own reasons.
If my software engineering experience gives me any insight into proper
designs, I will surely violate this requirement and I get the sense most
software implementators developing their own DKIM/SSP tools will realize
how
this req #10 conflicts with their design needs.
It is unnecessary requirement that attempts to mandate a certain design
approach which has no proof of being the correct approach.
At best, it should be rephrase to maybe serve as a reminder that 1st
party
validated signatures have a higher trust value and that by DEFAULT there
should be no conflict with the SSP policy.
But what is there is a conflict?
What does that mean? Should there be some tagging, notification,
logging or
reporting by the receiver? Not saying this level of logic should be in
the
requirements, but you have no control how the implementer will want to
approach this here.
In short, it is a implementator or software decision how they will
approach
POLICY vs. SIGNATURE checking. I already see I will be ignoring this
requirement. I may check it always regardless of signed or no signed
mail
simply because regardless of what the signature says, it must be
consistent
with the policy. If the 1st party signature is valid but there is a
CONFLICT with the POLICY, then someone should be scratching their heads
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html