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" <fenton(_at_)cisco(_dot_)com>
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" <mike(_at_)mtcc(_dot_)com>
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