wk at isil
Dec 8, 1997, 2:39 AM
Post #1 of 1
(392 views)
Permalink
|
Iīm 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.
* 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:
werner.koch [at] guug
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.
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.
* Takes more space on the disk; but if you already have such
a database for xfaces, it doesnīt matter.
Of course we donīt 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?
--
Werner Koch, Duesseldorf - werner.koch [at] guug - PGP keyID: 0C9857A5
|
