From: John Stanley (stanley@PEAK.ORG)
Date: Fri Jul 10 1998 - 13:50:50 CDT
On Fri, 10 Jul 1998, in another duplicate, Brad Templeton wrote:
> Indeed, but why design a system with any holes? Part of the benefit of
> signing your articles is so they can't be altered downstream, and everybody
> knows it.
That's baloney. I can alter a signed message. Only if you go to the effort
of verifying the signature can you tell it wasn't altered. Most people do
not do that.
> Sure, there is not a big problem with articles being
> changed downstream today, but why design a system that allows it when we
> know how to do better?
Because you can't stop it.
> Not at all. There would be many 3rd party cancellers of course, and since
Of course. Obviously.
> > Bad guess. What you have just said is that anyone at peak.org can cancel
> > one of my articles, even with a cancel lock.
> Correct, that seemed to be the expectation here.
You may expect that anyone using the same news server you use is
authorized to cancel anything you post, but _I_ do not expect it, and I
would oppose ANY system that resulted in suych authorization.
> If you use @peak.org
> as your domain and use them as your news server, you have the risk they
> might cancel your articles. If you don't want that risk, don't use their
> domain to post articles.
I didn't say "any admin", I said "anyone". Everyone. Billy Bob Joe User.
> It is the inability of a site to cancel articles with cancel lock without
> adding double locks to each article that is a serious flaw in using
> cancel locks, not a feature.
A site does not have to add "double locks". Is this another manifestation
of the "100's of locks" nonsense you wrote yesterday?
> However, I would hope that any standard
> we produce that involves cancel locks would provide for only one cancel
> lock -- the author's. Sites would cancel using their public key
> and site-owner certificate.
Of course, Obviously. The site should use the less convenient system.
> > > However, more simply, one would expect that sites would use public key
> > > based authorized cancels, and so would moderators.
> > But with cancel locks they do not have to go to that extreme.
> It's not an extreme. It's a lot better than having every site, every
> moderator, every moderator's site add some sort of cancel lock to every
No, Brad, it is not. It is more effort for everyone involved.
> > But could use a much simpler system just as well. Complexity for
> > complexity's sake is foolishness.
> Of course. The public key system is vastly more flexible and elegant,
> and does not require a-priori action.
But is still more complex. As soon as you add a key repository, you make
it more complex.
> The cancel lock requires everybody
> who might be entitled to cancel to add a key. That means posters, sites,
> moderators and moderator's sites. Gateways.
Gateways == sites. You are still only up to 4. That's two orders of
magnitude less than the 100's you spoke of yesterday.
> And then there's the person in the reply-to. And the person in the "From".
> If somebody posts an article with my name forged on it, I want to cancel it
> and I want to cancel it now. I can using the key that gives me the power to
> post and cancel as me.
No, you cannot do it "now". You can mail off a request for some central
server to cancel it, but email is not necessarily guaranteed to be "now",
especially if the site you happen to mail to isn't up when you mail. Even
if it is, you will not see the result until the cancel that IT generates
happens to make it back to your site. And if the central server does a
handshake with you, the cancel will be delayed even longer. What happens
if the central server is unable to resolve your address? It happens. I've
seen whole domains dissappear because their NS are both on a segment of
the net that is unreachable. What happens if you are the casual user, who
doesn't understand that the central server is going to send you mail? You
get pissed at the forgery, cancel it (expecting it to be cancelled) then
No, Brad, it is wrong to claim that the cancel server system is going to
result in the forgery being cancelled "now". If won't be, and it won't
even have the appearance of being cancelled "now".
> A system that could call for 5 different locks on an article and still not
> work seems to be complexity for the sake of complexity.
A system that does not work for a situation that it is not designed to
work for is working properly. A system that works well for what it is
designed to do is working properly.
> An overly burdened system with several locks per article is not worth
> making it easier for them.
"Overly burdened?" You mean like the key repository will be when the next
round of Clarinet cancels goes out?