From: Brad Templeton (brad@templetons.com)
Date: Fri Oct 12 2001 - 02:29:03 CDT
On Thu, Oct 11, 2001 at 04:13:43PM +0000, Charles Lindsey wrote:
> In <20011010131332.B19129@main.templetons.com> Brad Templeton <brad@templetons.com> writes:
>
> >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.
I'm not actually against that, as long as the standard is clear that you
can't just implement one of them. If sites have the choice of
implementing one and not the other, you can not issue your cancel with
confidence. Half the net might accept it and the other half not. Which
means you would feel compelled to issue it both ways, which is pointless.
> >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.
Yes, but in a properly designed system there are very few keys that need
to be available locally. They would be distributed regularly in control
messages, and not normally used until such messages are well and redundantly
distributed, so that it is highly unlikely a site would not have them.
(If a site elected to, it could decide, upon encountering a key it for some
reason has missed, to try and fetch it over the net, but this would both
be extremely rare, and entirely optional because it is so rare.)
> 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.
Yes and no. The truth is that all systems face this problem if site admins
wish to not act in a unified manner. This is also true for pgpverify,
for example. Right now, if sites splintered into three factions as to
whom they wanted to be authorized to issue newgroups for comp.*, then
a global newgroup would indeed need to be signed (or in the modern
pgpverify, issued independently) by all three parties.
This creates a trade-off. A fractured net is bad and inefficient, but
possible. YOu have to really want it to make it happen.
The alternative is far more likely, that if there is such a fracture
in decisions like who is the moderator, or who gets to newgroup, then
competing hierarchies are created where there is unity.
This is as it exists today.
For some functions, where there are factual judgements rather than
value judgements, it is far more likely there would be the required
unanimity. For example, when it comes to certifying the owner of a
domain, chances are this would simply be done by a conversion of whatever
security the domain registrars use. (There is a plan underway for
signed DNS would is an obvious choice.)
Or a general concensus could arise that email challenge/response from
the domain's administrative contact (which is what many domain registrars
use) is sufficient.
In this case, it's not a matter of judgement, it's a technical matter and
there can easily be unanimous opinion that whoever is doing that is
doing it properly or not, and little need to fracture.
Today, we've come to unanimous opinion on Dave Lawrence maintaining a
list of unanimously approged hierarchy managers for newgroups with
pgpverify.
Of course for spam cancellers there is no need for unanimous opinion, and
in fact there are many redudant streams, signed by the various parties.
>
> 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.
On any frequent message (of which the only examples are moderated postings)
signature collapse would be used. Only one signature to check because of
the collapse. For spam cancels, these are expected to be fine tuned,
though spam cancellers picked through multiple levels of delegation
would be polite to collapse to save people space and time.
For control messages (newgroup, personal cancel etc.) they are so rare
that the number of signatures is not an issue.
However, by and large, while having such a fracture is entirely doable,
I think that users will tend away from it. That is certainly what we
have seen so far. One master moderator forwarding site, one file of
hieararchy managers, one blesser of moderators for pgpmoose.
It's really up to where people want to sit on the tradeoff line between
the advantages and disadvantage of fractured control structures within
a single hierarchy. For different hierarchies, of course there is
no problem.
My personal expectation is to replace the role of Dave Lawrence and the
blessers of moderators (currently ISC and pgpmoose) with a board. This
board would probably have 12 to 20 members, in different nations of the
world, so that no national government or court could control it. It would
be volunteers, who would win the near unanimous blessing of news admins of
the world (As Dave Lawrenced managed to do as a single person, which is even
more impressive.)
The difference here is that no member of the board could act alone. The
board would issue keys to do powerful things (newgroups, create moderators,
create hierarchy managers) by "vote", but the vote is right in the
certificate. Most modern certificate systems are designed to support
such a system. The board member's certificate says, "This certificate has
godlike powers X, Y and Z, but only when combined with at least 10 other
similar certificates."
The sysadmin installs only the certs of the board to start with. He trusts
them because, like Dave, they have a good reputation, and none of them can
act alone, and if some of them go rogue the others can put checks and
balances on them, and if it gets so extreme that it's time to fracture
the net and use a different board, the sysadmin can always do so.
This isn't the way it has to work, but I predict it's a good way for it
to work.
>
> 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.
I think Verisign would be a fine certifier of E-mail addresses, quite a
good one actually. In the system I describe there is no single top
level signer. Now of course the board doesn't actually sign real articles
that get posted to the net. The board only delegates its powers.
So let's say the board likes Dave Lawrence to manage comp.*. (ie. the
same situation we have now.) So 10 or more of the 20 members of the board
issue a special control message, which contains a certificate signed by
them. That cert delegates to a special key of Dave's total power over
comp.*, and it tells all systems, "Keep this key in your local
repository."
Your system looks at that message, checks that indeed 10 of the board
signed it, and stores the key and associates total power over comp.* with
it. This is similar to you configuring such power by hand, but you
didn't have to do anything but trust the board. (You could of course
configure your software to not trust the board and review this by hand.)
Or you could have a board for each hierarchy if you wish. Or a dictator
if you wish.
Now Dave has a key that can do everything in comp.* -- newgroups, rmgroups,
delegate moderator keys, delegate managers of sub-hierarchies with all
powers within them, cancel in comp.*, etc. -- whatever the board decided
to delegate to him.
If Dave abuses that key, the board can take it away from him. Or site
admins can disable it manually if they want. As such, these checks and
balances keep Dave from doing such abuse. He's a good boy, so he's not
likely to, which is why they picked him. That's how everything on
USENET gets done -- somebody volunteers to do it, and as long as they
do a good job, people continue to use what they do.
Dave possibly uses his key to do newgroups, but mostly he probably
just delegates further. If a key is going to be used a lot, he puts
that "sticky" bit on it to tell sites to keep it and cache it. This
is done enough to be efficient, but not so much as to make very large
tables of keys to be kept in ram. (If ram is that much of a concern these
days!)
When it comes to factual judgements, the board might accept many volunteers
or companies who are willing to do things like certify E-mail addresses
and domains. There are lots of ways to do that, and here we get a
market.
Let's say verisign says "we want to certify domains and E-mail addresses."
The board says yes, and has little reason not to. Then they turn out to
have really lax security and screw up all the time. The board pulls their
certificate. That means everybody who certified through them loses their
certificate! Possibly the board gives some warning so they can all scramble
and get another quickly. However, what this means is that you want to
get your certificate from somebody who will not screw up. As such,
the customers, more than anybody, demand that you do a good job!
However, certifying domains and email addresses is something you can do
to a moderate security level very cheaply, with challenge/response. You
can automate it, and issue certificates that say, "All this cert proves
is that a valid challenge response went on, and nothing more." Such certs
would be of mostly limited use, but fine for people who want to sign their
postings and block forgeries in their name. Such certs will have holes
but everybody knows them.
Verisign in fact does this, or used to. Their level 1 cert, which was
free, just verifies a challenge/response to confirm an E-mail address.
I think they've now upped it to $14.95/year. Their Thawte division
still offers them free.
> 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).
For things like alt, one could implement a system that creates a group
and grants moderator power to the first person to try to claim it.
Alt could have its own board (or dictator -- whoever people want to trust),
or a larger board that just builds a system that creates a group and grants
a moderation certificate to the first person who comes along. That seems
to be the charter of alt.
> 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.
But with a tree-based system, there is no difference between a few
certificates and a million, that is the beauty.
>
>
> 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.
The question is, if that works well, why do you need the cancel lock?
Again the question isn't PK vs. CL, it's PK + CL vs. PK.
As you point out, PK based cancel has the big plus that you can cancel
a forgery that was posted in your name, and a site can cancel forgeries
(notably spams) that were posted in their name.