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" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]> Cc: "IETF-DKIM" <[email protected]> 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
