Re: [ietf-dkim] Draft summary of SSP functionality

Arvel Hathcock wrote to Dave:

> Ok, took the bait, couldn't resist, sorry :)
>
>  > Could you provide some examples of such scenarios?
>
> You didn't ask me, but yes, I can.
>
> (a) My software has a global white list feature.  That white list 
> contains any number of identities from which validly signed messages are 
> trusted.  When encountered, no SSP.
> (b) My software allows individual users to maintain their own address 
> books.  The domain of any entry therein can be configured as a trusted 
> identity.  When validly signed messages arrive from such identities 
> bound for said users, no SSP.
> (c) My software includes call outs to a certification service.  Use of 
> the service is predicated upon trust in the certifier.  When validly 
> signed messages arrive from identities which the certification service 
> says it's in love with, no SSP.
> (d) Although this isn't completely fleshed out yet I hope my software 
> will someday have a transparent framework for using any domain-based 
> reputation service.  Use of such services are predicated upon trust in 
> the service provider.  When validly signed messages arrive, etc. etc.
> Compared to many on this list, I'm a relative idiot in the software 
> business.  Imagine what somebody with a real brain might be able to come 
> up with.
Please don't say that.  You're are not alone.  We have completely 
different mindsets and disciplines here, and sometimes "never the twain 
shall meet."
People like us, and I honestly don't want to suggest you agree with me, 
are very keen to see how this all fits.  The hope is that our 
engineering is rich enough so that we can recognize the risk associated 
with over simplification and also appreciate the operations, 
administrators, "controllers" and "keepers" of the network point of view 
as well.
At the end of day, to me, like you, it is very simple. DKIM and SSP were 
very simple concepts to begin with and the "mess" began when we began to 
separate the two, and it should be noted, the two PRO and CON camps 
simply need came to an agreement. There were outside ambitions that were 
clearly out of scope - mixing in reputation.
That does not suggest mixing in reputation was wrong.  It means it 
should of been the original focus if this was what people wanted to 
concentrate on.  As it was, there were entities that went on their 
separate ways and created reputation based systems bypassing any IETF 
working group engineering.
So yes, we if want to be talking reputation systems, fine, thats great, 
lets remain focus with that design and work it out.
But SSP is not about reputation and if we want to complete SSP, we need 
to separate and stop with the muddying the water with reputation 
considerations.
From a implementation standpoint, they both still fits together as you 
clearly pointed out in your Software feature A, B and C, and hopefully 
D.   That is common sense - to me. :-)
--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html