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" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>;
<ietf-dkim(_at_)mipassoc(_dot_)org>
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" <mike(_at_)mtcc(_dot_)com>
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