Jim, I appreciated your clarification of the Exclusive (o=!) policy.
First, I must say I had to get over the shock value of this revelation and fundamental miscalculation. This changes everything. I am vexed as to how this fell thru the cracks. Rest assured if I had realized this last year, it would of been topic of debate to atleast get it very clear what this policy meant as it initially drafted. A lot of time wasted and what I really don't appreciate is the lack of professional courtesy from the key cogs and authors for not clearing this up very early on for one simple reason: The term EXCLUSIVE introduced to label the symbolic O=! policy, was semantically, literally and technically incorrect to be used for this specific SSP. >From Dictionary.dom: 1. Excluding or tending to exclude: exclusive barriers. 2. Not allowing something else; incompatible: mutually exclusive conditions. 3. Not divided or shared with others: exclusive publishing rights. 4. Not accompanied by others; single or sole: your exclusive function. 5. Complete; undivided: gained their exclusive attention. and so on. It should had not been used or allowed to be used in SSP discussion, especially in the IETF meeting presentations. It was incorrect. In all fairness, it all make sense now. I can see now why you commented, there might not be a difference between STRONG and EXCLUSIVE and that they could be folded. In this case, I think you are correct. There is no difference now. But then again, you probably meant something else. :-) This changes months of proposed protocol technical analysis and software modeling 100% based on having a fundamental engineering concept of always having ideal baseline conditions or two absolute guarantee extreme end points in the spectrum of possible results. In this case, EXCLUSIVE (O=!) and NEVER (O=.) This changes everything: - Foremost, the security of the protocol. There is no longer an absolute ideal end point of exclusive protection. The protocol is now entirely made up using 100% relaxed provisions, which - Creates new potential entry points to analyze, and which - Creats a new series of assertions that need to be proved. I will go ahead and provide input with "NEW ISSUES" in the TA. I do hope this is reconsidered and changed because if DKIM is made of 100% of relaxed conditions with no absolutes (and the only one now is NEVER), it will be very difficult me to have any incentive to continue supporting this protocol purely based on its technical merits. Thanks for listening. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Jim Fenton" <[EMAIL PROTECTED]> > Hector, > > Perhaps part of the disconnect here is the question of whether the > policy applies to the validity of the message or to the validity of > individual signatures. > > John's original question is premised on the idea that there may be > multiple signatures on a message. Let's take it as a given for now that > there may be. > > The ! (EXCLUSIVE) policy says "Third-party signatures SHOULD NOT be > accepted". So if a message with an OA signature and a third party is > verified, and the SSP is EXCLUSIVE, then the third-party signature > SHOULD be ignored, leaving the OA signature. The message isn't > considered Suspicious if the message has a valid OA signature. In other > words, it doesn't say "messages with third-party signatures SHOULD NOT > be accepted", it says that the third-party signature itself SHOULD NOT be. > > I agree with many that it doesn't make a lot of sense to put a > third-party signature on a message that has an EXCLUSIVE SSP. But I > don't see why it should harm the message to do so, so long as applying > the new signature doesn't break one that's already there. The verifier > has to check SSP regardless (unless it verifies that there is a valid OA > signature first); it should be up to the re-signer to decide whether to > also check SSP or not. > > -Jim > > P.S.: I'll echo Stephen's request for more comments on the threat > analysis document. I KNOW it isn't perfect! > > > Hector Santos wrote: > > ----- Original Message ----- > > From: "Michael Thomas" <[EMAIL PROTECTED]> > > > > > >>> For the EXCLUSIVE policy? Following SSP, it would be a > >>> REJECT because the policy says no 3PS should exist. > >>> > >> That's not what it says. It says: > >> > >> "! All mail from the entity is signed; Third-Party > >> signatures SHOULD NOT be accepted" > >> > >> In the context, it means that it requires a first party signature. > >> It should probably be more explicit on this point. > >> > > > > In the context of the Levine's question, > > > > Levine: > > "if a message has both a signature from the From: domain > > and one from someone else, does that pass? Why or why not?" > > > > Following your SSP draft description as posted above, this would be an > > unaccepted condition. > > > > What is the difference? > > > > -- > > Hector Santos, Santronics Software, Inc. > > http://www.santronics.com > > > > > > > > _______________________________________________ > > ietf-dkim mailing list > > http://dkim.org > > > > > _______________________________________________ ietf-dkim mailing list http://dkim.org
