From: Brad Templeton (brad@templetons.com)
Date: Thu Jul 23 1998 - 21:28:11 CDT
On Fri, Jul 24, 1998 at 11:10:38AM +1000, ? the Platypus {aka David Formosa} wrote:
> By unifing these powers you are centrilising the power (or influence) in a
> way that has never been done before.
Unification is not a must. Different people can certify e-mail addresses
from those that do collapse from those that certify control messages.
Yes, there must be some nearly unanimous agreement on who is a good
and trustworthy certifier of e-mail addresses, but I fail to see that
as inferior to today's alternative -- that we simply trust all e-mail
addresses generated.
>
> I know you beleave that this will delay the impion of your system.
> However the share complexy of the set up and the fact that there is still
> parts of the scheam that remain undefined.
Most people are agreeed we can't turn on cancel locks until there also is
a 3rd party system also endorsed by the spec. Otherwise the first people
to cancel lock will be the spammers! In fact, I'm sure that spammers will
be the first to cancel lock because they "suffer" the most from 3rd
party cancel!
So both systems have to come online at once. It is not appropriate for
the spec to define cancel lock but leave the necessary 3rd party component
to an unspeced ad-hoc system like pgp based nocem.
So they both come together. The only question is how long to get the
trust networks in place for certificates. And yes, that goes faster the
more uses you put to it and the more people need it for.
>
> As 3rd and 1st party cancels are very diffrent beasts I don't consider
> this as a bug. In fact I beleave whatever scheam is used 1st and 3rd part
> cancels should be clearly seperated.
Why? Why would you have 2 systems when 1 of them will do? The only reason
I have seen is simplicity of newsreader operation when posting articles
and cancels.
>
> You can have a non delegated trust model, I belave that this cert is
> valid because most of my peers beleave that it is valid. Assuming that
> peaple trust there peers, then you can derive a chain going back to the
> owner of the privert key.
I would like to see a model for this working on USENET, without making
a fractured net where control messages only work some of the time. You
can certainly implement this using a cert system, the question is whether
it will work.
>
> However what happens with this person gets entrenched? I mean if Tale
> went nuts tomorrow. How quickly could we get a replacement?
That's the point. With the system I proposed, if we are willing to appoint
a council with the power to replace him, then we can do it as soon as they
meet and gather the votes to do it. Right now you would take months to
replace him, though it goes faster the more nuts he goes. (Sorry, Dave!)