From: Brad Templeton (brad@templetons.com)
Date: Fri Oct 12 2001 - 13:17:59 CDT
On Thu, Oct 11, 2001 at 04:47:07PM +0000, Charles Lindsey wrote:
> In <20011010193612.F20770@main.templetons.com> Brad Templeton <brad@templetons.com> writes:
> Not at all. Each site keeps a set of keys (the existing PGP Key Ring
> format would actually do quite well, though a tailor made solution would
> likely be better). Certain newsgroups (perhaps one per hierarchy) would
> carry articles containing keys, which would be automatically downloaded
> into the database as received. Naturally, these groups would be moderated,
> or use Named-Articles, or both. There might also be web sites storing such
> keys (though I would not recommend the present PGP key servers for the
> purpose).
>
> Now an article needs to be signed by only one key, because you can look up
> in your database the whole history of why you should trust it.
One of the key factors to this debate is you believe there is complexity
to a certificate system which does not exist in manual files. This is
not true. One way or another, there needs to be information stored
in some fashion that configures the trust relationships.
For example, you might propose a file (keyring) where keys are stored, and
something is stored to associate a key with an authorization (like
newgroup in comp.) This file has to have a format, a syntax. It is
spread out but that is exactly what a certificate is. A certificate is
an association between a key and an authorization, and it has a syntax.
The only difference is the one on disk gets its blessing because you hard
coded blessing to that disk file, and the certificate (found in the
article) gets its blessing because it is signed by a key. This is popped
up a level and that key is trusted because it is in the blessed disk file,
though since the syntax remains the same, this is just an extra level of
indirection.
Now I've always believed the fundamental theorem of computer science
(that all problems in CS can be solved by adding another level of
indirection) and I think it applies here.
>
> >Why is putting the certificates in the articles so bothersome to you?
>
> What your scheme carefully omits to mention is the matter of revocation.
> There absolutely MUST be a worldwide database of revocations, cached
> locally. If you are going to have that database anyway, then you may as
> well keep ALL the keys in it.
If you have read the proposals, years old as they are, you would see that
they deal with revocation. In fact, I have often brought up the issue
of revocation as important because it demands that it must be servers
which handle authentication, not clients. Clients can't reasonably keep
a CRL.
The way most public key systems handle revocation is indeed to require
that sites keep a list of the recently revoked certificates. Not of
all keys (that would defeat the point) but just of the revoked ones.
This list is built into a hash table (spell checker style) so a quick
in-ram test can quickly determine 99% of the time that a key is not
in the CRL. (1% of the time you go to disk to check the non-hashed
CRL that resides there.)
Normally, to keep the CRL small, systems are designed so that certificates
expire. You set the expiration time based on security needs, and the
expected revocation frequency traded off against the issues of renewing
keys. Normally key renewal is automatic -- some time before your
key expires, your software contacts the CA that issued the key and asks
for a renewed certificate with a longer lifetime. The CA of course checks
that this is OK, and that your old key wasn't revoked.
When this is done you only have to keep a cert in the CRL until it expires.
Revocation on USENET would clearly be done by a control message, repeated
from time to time, with recent key revocations. In addition, those who
wanted to could fetch the current CRL over the internet or it might be
posted every few days in a newsgroup. The USENET CRL should not get
very large. Even if millions of keys were involved, only a few thousand
would likely need revoking. (That might not be true for pseudonym style
identities which people get, spam with, and discard, which is why you
give them a shorter expiry.)
Done well, the users and admins don't see this happening at all.
As for the top-level keys, they also renew, but the top level keys get
their power by the sysadmin (or installer) having placed them in the magic
file of blessed keys. In my proposed system of a "board" enough members
of the board can get together and revoke the key of another board member.
If you don't do this, sysadmins need to edit the magic file to take out
somebody they want to revoke permission on. They can always do this, but
again I believe most people want minimum sysadmin work.