Hector,

Hector Santos wrote:

> > 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.
> >   
>   
Please don't overreact.  I would have spoken up sooner if I had
understood the disconnect and if I thought that your interpretation was
as broken as you seem to think it is.  I think only minor adjustments
are necessary.

> > 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.
> >   
>   
I mostly disagree; see definitions below.

> > >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.
> >   
>   
This is the definition that I think fits.  The originating domain does
not want to share the right to apply a valid signature to its messages
with re-signers.

There is one sense where the term "exclusive" may be inappropriate.  I
understand that there may be legal reasons, in Europe in particular,
that a domain not try to dictate the handling of messages by others.  In
that sense the o=! policy (practice) would mean "I sign all messages,
and do not send through lists and others that would necessitate
re-signing".  A verifier could then interpret that policy/practice in
much the same way, but the statement is now declarative, not
imperative.  I don't really know what the laws say and whether this
would help, but I suspect it might.

> >
> > 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.  :-) 
> >   
>   
Did I say that?  I think there's an important difference between STRONG
and EXCLUSIVE.  Not many domains will be able to publish EXCLUSIVE
because only a minority actually adhere to those practices, but it's a
very useful statement for those that do to be able to make.

> > 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.
> >   
>   
I'll be interested in your new issues.  I don't think that much has
really changed; just that the validity of individual signatures, and not
entire messages, is affected by SSP.

-Jim

_______________________________________________
ietf-dkim mailing list
http://dkim.org

Reply via email to