From: Bill Davidsen (davidsen@prodigy.com)
Date: Wed Oct 10 2001 - 10:00:13 CDT
Brad Templeton <brad@templetons.com> wrote:
Whoever said we should drop this is right, there is simply no meeting
ground between those of us who don't want any central certificate
authority and those who feel it is a requirement.
> On Tue, Oct 09, 2001 at 03:38:57PM -0400, Bill Davidsen wrote:
> > Brad Templeton <brad@templetons.com> wrote:
> > > You don't need a key repository at all. Public key cryptography was
> > > invented for two reasons, and you're forgetting the 2nd -- to avoid key
> > > management problems.
> >
> > If I don't need a key repository, where do I get the public key.
> > for (i=0; i<1000;++i) printf("usenet is not internet\n";
>
> I've answered this so many times, I am surprised you've missed it.
> The keys are in certificates, they are included with the article itself.
> All you need to install (or in fact all your news software author includes
> if you trust him or her) is the set of root CA keys you wish to trust.
But that identifies the person sending the cancel, not their authority
to do it... It means I have to trust someone to issue cancels in certain
cases. Now that's fine for moderators, although I'm not sure that
signing every post is a bad thing either, which would let forged posts
be rejected upstream by some (eventually most) hosts.
Cancel keys have the advantage of not requiring trust of any poster for
more than that particular post. And as we both have noted it means you
can't cancel a post which has expired (not a problem) and if the cancel
arrives before the original post the information needs to be saved. But
you noted this is low overhead, and I agree.
> You could call that a "repository" but it's only a few score keys, and it's
> generally static (or rather subject to automatic update via control
> messages which come over USENET, not the internet.)
>
> The goal is for most admins that they set it and forget it, until something
> major comes up (like most of the people they trusted simultaneously going
> rogue -- which is pretty unlikely.)
I agree, but it still requires a site to have trust for someone to
cancel ANY post. That's not a bad thing, but I don't see why having
cancel locks changes that:
- sites w/o cancel lock implemented honor old cancels or don't
- trusted moderator/nocem source MAY cancel anything at site option
- poster and injector can cancel posts w/o requiring trust in general
I don't see this as either/or, a cancel locked post SHOULD not be
canceled by an old style cancel. Site MAY allow OOB cancels like nocem.
Moderators can be done with either a moderator lock, sign of each post,
signed cancels, or some limited nocem-like message.
> > This supposes that we rewrite the standard to require that the site
> > force message-id's. And it still has "any site can get" assumptions
> > which don't apply to non-Internet feeds (satelite, uucp, etc, etc).
>
> Sorry, I don't understand why being a uucp or satellite feed would
> interfere with your ability to have a domain name or get a key for
> one. Can you explain?
It makes getting keys in real time a problem. And given the things which
have happened recently, the Verisign/Microsoft fiasco and the
possibility of enemy action, I'm even more disinclined to use CA.
> As for rewriting the standard, that is after all, what we're doing here!
> (You were proposing that by saying that cancels that arrive first not
> be reliable.)
Given that (old) cancels aren't reliable now, and this only applies to
sites not saving cancel info, which you agree is easy, and only happens
with new style keyed cancels, I don't see that we are changing anything,
just adding a new feature and (I hope) denigrating the old unkeyed
cancel mechanism.
> > The need for same can be eliminated by putting the cancel key info in
> > the headers for the poster and/or site.
>
> Huh? You mean in the original article? Then you have to wait for it
> to authenticate the cancel.
Agreed, but so what?
> > The issue is not so much in getting a key or certificate for the sender,
> > as avoiding getting keys for many users or sites before you can validate
> > cancels.
>
> You don't need to get the keys for users or sites before you can validate
> the cancels. The keys come, certified, in the cancels themselves.
> Self-contained.
You see a trusted central authority as a good thing, I don't. It's a
single point of failure and compromise, and would probably not scale
well if it were giving out thousands of certificates. Not to mention
that it might cost more than people would want to donate.
> Well, I happen to think it is an error to have both systems exist, but
> I know some continue to advocate the cancel lock/unlock. I have
> enumerated its various flaws before. One of them is the one you point
> out -- that you can't verify a cancel until you get the original.
I don't see that the methods "compete," one validates cancels for a
given article, one validates the right of a given poster to cancel any
post (or a subset of posts, whatever).
> > Here you make a very good point, you probably should have a key server
> > keep the moderator keys. However, for sites not connected to the
> > Internet, an occasional posting of a signed list of keys would resuduce
> > the number of keys needed to start to one, the key for the moderator key
> > post. And most sites can get the list off the net (a one time thing)
> > somehow. One time access to keys is a vary small problem.
>
> Again, you seem to be making assumptions that indicate you are unaware
> of how certificate systems work.
No, I make the assumption that some other people share my distrust of CA
vs. PGP (or similar) keys.
> There are no key servers. (Well, you can have them as a backup but
> they are not normally used.)
Consider that "key server" can mean "CA master" and you see what I want
to avoid.
> No, what I have been pointing out is that, if, as is the case 99% of the
> time today, messages come with a message-id which ends in the domain
> of the site that originated the message, one can arrange to have an
> authenticated cancel which does not require having the original message
> to authenticate it.
It's actually not nearly that high a percentage, in two days 19000
Msg-Ids came from the server and 7466 were supplied by the user. That's
more or less 25% user provided. However, I think that any % breaks the
functionality, at least for all injectors allowing user setting.
> If you add the idea that you encode a user's E-mail address (not just
> domain) into the message-id, so that my messages come from
> <unique#brad@templetons.com>
At user request Prodigy went from a unique number to a 192 character
header line, because people didn't want to have messages trace back to
them. Most providers will avoid something so obvious.
> 1) For most users, they just post messages and cancels as per today. Their
> site, with a new injector, takes the cancels, authenticates them locally
> and signs them. If the messages contained the site's domain in the msgid,
> the cancel can be acted upon without waiting for the original. If not, the
> site must wait.
That sounds as if every post would have to leave a trail of message-id
and "real poster" information. Many sites don't know the real user on
the server, they get it from the logs on the POP, or billing records, or
whatever.
> 2) For users who don't have a new injector, the cancel goes out the old
> way. The cancelbot notices it, and sends back a challenge to the poster.
> The poster responds and the cancelbot issues a signed cancel.
You're not serious, are you? You're just making up the most cumbersome
way to possibly implement this? What a great argument for cancel keys.
> 3) For users who want to get their own keys, they can arrange to configure
> their msgids etc. as they like, and get a key which lets them cancel
> directly, with no involvement by the injector or the bots. They need not
> use their local injector -- since their cancel is signed, there is no
> reason that they can't use an open injector anywhere on the net which
> accepts only signed and authenticated cancels. Indeed, the author of
> the new canceller could presumably run this injector for his own users,
> since private cancel volume is quite small.
Thank you for pointing out how complex your CA scheme would really be.
Hopefully you have convinced people that cancel keys are the better way
to go, and PGP signed nocem as is current practice.
Now we can discuss moderator issues.
-- -bill davidsen (davidsen@prodigy.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me