Read-only keyring and the keybox

[Jason Harris]

On Fri, Dec 04, 2009 at 03:49:49PM +0100, Werner Koch wrote:

> Complaints about multiple keyrings are an old topic but one we
> eventually need to solve.  Daniel Leidert recently opened a bug for it

FWIW, I had difficulties with multiple and/or read-only keyrings until
--primary-keyring was introduced, which has been a great improvement.

> These bug reports are sometimes mixing two different issues: The
> debian-keyring and r/o keyrings for other purposes.

> The other issue is that of multiple keyrings.  Over the years we tried
> several approaches to get it right but none of them worked reliable.
> The problem is the usual one of keeping two databases in sync.
> Aggravated by the requirement to keep some of them read-only but still
> allowing to update them somehow.  Approaches like preferring the
> writable one over the read-only one work in theory but will lead to
> administrative headaches.  We will never be sure which keyblock is
> actually used.  (I had a similar problem today with VPATH builds where

It is a pain to manually/administratively ensure no key is used from
or kept in multiple keyrings, but that is generally what I have done.
Given that any GPG process should only be using one trustdb.gpg at
a time, I think it is acceptable to merge (in memory) all key material
found in multiple keyrings, recalculate trust/trustdb.gpg "stuff,"
and proceed as though only one keyring held all the key material.
When it is necessary to update a key on disk, the --primary-keyring
or first available writable keyring wins.  (Non-exportable data must
remain in the file(s) in which it was found.  New non-exportable data
must only be written to --primary-keyring.)

Speeding up finding one or more copies of all desired keys in one
or more keyrings is a separate issue (addressed below).

> What I plan with GnuPG 2.1 is to rework the keyring situation by
> replacing keyrings it with a new format (keybox).  This new format
> allows to keep meta data and also will boost key access times.  This
> will make it possible to flag keys as read-only or allow updates only

I think metadata is excellent, but GPG will always run into files
holding key material that are themselves marked read-only, no-change,
append-only, etc. at the OS level.  Marking all keys in a keybox
file internally as read-only will be accompanied in a belt-and-
suspenders approach by also marking the file unchangeable at the
OS level by users who are sufficiently paranoid.

> with a new options set.  I am actually working on 2.1.  However,
> before we implement such extravagant feature it will be wetter to
> collect real world use cases.  We should do this on gnupg-devel at .
> 
> One such use case might be to automatically import certain keys into
> the keybox for future use.  This is basically the idea of reading the
> writable keyring first and only then the read-only ring
> (write-on-demand).  The solution I have in mind is to import such
> read-only keys using the established --auth-key-locate feature.

Rather than introducing a new format (keybox) for actual key material
or requiring that separate indices be kept for each keyring
(.gpg and .gpgidx?), why not add the needed metadata to trustdb.gpg
or some other single, suitable (and always-writable) file/database?

When the metadata and actual file sizes and file mtimes match for
all specified keyrings, and the combinations of offset, size/length,
fingerprint, and overall hash match the key(s) found in each file
for all keys being actively used, no further scanning of the specified
key files or updating of the centralized metadata need be done.

(When a file holding key material has changed in any detectable
way (depending on one's threat model), rescan the entire file
and update the central metadata store for that file.  (Add a
command-line flag to rescan one or all specified keyrings or
to delete and rebuild all metadata if the file size + file mtime
method is not enough for the sufficiently paranoid.))

-- 
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris at widomaker.com _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 313 bytes
Desc: not available
URL: </pipermail/attachments/20091205/758c539a/attachment.pgp>