keyring database
Werner Koch
wk@isil.d.shuttle.de
Mon, 8 Dec 1997 10:39:50 +0100
I=B4m looking for a way to store public key rings in an efficient way.
For now (and small key rings) we can simply use a keying (like PGP),
and insert new records, by directly changing the keying or appending
new stuff at the end and mark old stuff as invalid (and run a compaction
from time to time).
This has several disadvantages for large key rings:
* It takes a lot of time.
* The whole keying must be locked to allow several processes
to update a public keying.
* We can only do a sequential search to find a key-id or user-id
* Updates (e.g. new key signatures) are very costly. =20
* The key ring must reside on one file system.
What about this idea:
We use a database in the form xfaces uses it: Use a directory tree and
store the email addresses in it:
=20
werner.koch@guug.de
would be stored in:
.../users/de/guug/werner.koch/pubring.g10
Advantages:
* Easy access to the public key certificate of a user, if we have
his user id (Which is true in most cases).
* Locking with a fine granularity.
* We can very easy combine it with a xfaces database.
* Allows usage of symlinks for alternate user-ids
* Can be split over several disks.
* Maybe we can use a daemon to handle such a database and provide
an interface for other programs and build a key server this way.=20
Disadvantages:
* We can/must create index files for the keyids or the user-ids
to allow searching the key id or the user-id when only knowing
a part of it.=20
* Takes more space on the disk; but if you already have such
a database for xfaces, it doesn=B4t matter.
=20
Of course we don=B4t do this for secret keys. I know that this is for
what a directory service is good - but we can very easy implement this
stuff and work with huge key rings.
Comments?
--=20
Werner Koch, Duesseldorf - werner.koch@guug.de - PGP keyID: 0C9857A=
5