Steve, The threats are based on what SSP defines. Getting this straight now is important.
Atleast the confirm the current meaning of the drafts. I was told I was wrong and I don't think so. Michael was shown incorrect logic while back (how the pseudo code was incorrect) and he chose to ignore the input. I can't help that, but to find out now that all my analysis and interpretation of this proposal is FLAWED, well, he better correct it or back it up. Not having this straight will cost us time and money. I am not going to wait 1, 2 or 3 or 6 months or 1 year from now to find out what we have is all incorrect (I don't think so), but before we go any further we should get this resolved now. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Stephen Farrell" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]> Cc: "Michael Thomas" <[EMAIL PROTECTED]>; <[email protected]> Sent: Friday, January 27, 2006 11:16 AM Subject: Re: [ietf-dkim] Attempted summary, SSP again > > Folks, > > Hector Santos wrote: > > ----- Original Message ----- > > From: "Michael Thomas" <[EMAIL PROTECTED]> > > > >>> What is the difference? > >> The second clause is only trying to make explicit that a third > >> party signatures is not an acceptible substitute for a first > >> party signature from that domain. Which it isn't. You're making > >> a leap that it should also cast a shadow on the first party > >> signature. > > > > I made no such leap. You are talking semantics. > > While its an interesting question, SSP is two steps further along > from where-we-are-now: > > 0. Right now we should be focusing on the threats draft. > 1. Then on the base protocol. > 2. And *then* on details like this. > > I'd love to see some more review of the threats document. It can't > be that perfect can it? > > Stephen. > > _______________________________________________ ietf-dkim mailing list http://dkim.org
