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