From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Thu Oct 11 2001 - 11:13:43 CDT
In <20011010131332.B19129@main.templetons.com> Brad Templeton <brad@templetons.com> writes:
>On Wed, Oct 10, 2001 at 11:00:13AM -0400, Bill Davidsen wrote:
>>
>> 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.
>No, as I have been writing, the certificate doesn't need to identify the
>sender, just that there is a chain of trust from you to the sender
>authorizing whatever it is the article wants to do (cancel, moderated group
>posting, newgroup etc.)
I would certainly want to be able to identify the origin of each
certificate in the chain if my suspicions were aroused for some reason.
>So which is simpler, PK and CL or just PK?
We indeed have to choose between those two. My present opinion is in
favour of PK + CL.
>> 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.
>There is no need to get keys in real time, so that is not an issue.
On the contrary, when a cancel arrives you need the necessary keys in real
time (within a very high probability). I.e. they must already be in some
local cache.
>As for CAs making mistakes -- of course they will, lots of them. However,
>this issue is dealt with in several ways:
>I don't want a trusted central authority. I want a generalized system
>that gives site admins the ability to delegate trust to whomever they want,
>including the ability to sub-delegate.
Yes, but your system entails much more than you have been having us
believe.
Site admins will decide for themselves who to trust. Some will trust Paul;
some will trust Apollos; some will trust Cephas.
So every signed message will have to include three chains of certificates,
one for each of Paul, Apollos and Cephas, just to be sure that all sites
will honour it.
But you are also expecting every injecting site on Usenet to have its own
key, and neither Paul, nor Apollos, nor Cephas will have intimate
knowledge of all those sites, so they themselves will rely on
intermediaries whom they trust, so a typical chain may be four of more
long. So that is maybe 12 signatures to accompany each article, with up to
4 of them having to be checked (depending on how good your cache is). And
note that it will be the perceived thoroughness of the 3 top signers in
checking their intermediaries that will influence site admins to trust one
of them rather than another.
And for sure there will be other top level signers trying to muscle in, for
their own reasons. Would you trust Verisign as a top-level signer, for
example? You may be sure that Verisign will be only too ready to lure you
in.
OTOH, if only hierachy admins, moderators and spam cancellers need to
sign things, then the whole thing scales down to something much more
manageable.
>Likewise I don't think admins will want different groups saying who is
>the moderator of what newsgroup. They will push instead for one system
>to pick the moderator and trust one party or board to certify those
>moderators, because that works and alternatives are unweildy.
Moderators are a much easier case, because the obvious entity to trust is
the hierarchy admin who newgrouped the moderated group in the first place
(wouldn't work so well on alt, though).
>>
>> No, I make the assumption that some other people share my distrust of CA
>> vs. PGP (or similar) keys.
>Perhaps, but I really would like to see a workable proposal, that scales,
>that does't use certificates. I (and pretty much the entire crytpo
>community) view certificates as following Einstein's dictate to make everything
>as simple as possible but no simpler.
A scheme that requires certificates for only hierachy admins, moderators
and spam cancellers will scale pretty well. But not one that requires
maybe a million certificates worldwide, for the reasons I have given
above.
>>
>> > 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.
>Completely serious.
I think I would agree at least to the extent that some sort of
challenge-response system is the only option for individual users,
especially if they do not have modern software or their articles are being
maliciously forged. But that sort of scheme is an alternative (or
supplement) to Cancel-Locks, and is independent of how we manage the main
PK system.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5