Key list planning

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Wed, 6 Jan 2010 11:29:29 -0800 (PST)

In light of recent feature requests and other development, I think the
thing we currently know as the KeyList will need to change. Below are
some design ideas open for feedback.

The current design is to operate in one of two modes: single-key or
multi-key. Single-key mode is activated with the "KeyFile", "Domain" and
"Selector" settings, which loads a single key for use on all signed
messages. Multi-key mode is activated with "KeyList", and loads a linked
list of regexes, selectors, domains and keys that are processed in-order
against From: header fields to determine what signature(s) to generate.

The downside to both of these is that reloads/restarts are necessary when
any of those change. What we need is a design that allows keys, domains,
etc. to be added on the fly without requiring reloads.

We already have the backend support for this in the form of odbx and bdb,
and the regex stuff can be easily adapted, and LDAP is on the way. Right
now though the key-value pairings are such that the keys are domain names
or subdomain names (or regexes) and the values are records of the form
signing-domain:selector:path-to-key, and then the keys are loaded from
those files at startup. Storing paths to keys doesn't make much sense in
the SQL and LDAP cases where lots of different machines could be
referencing the data.

So I think the keys need to be in the backend data. Thus, my current
thinking is to add a new table that maps key names to
signing-domain/selector/private-key records. KeyFile and KeyList will
merge into this one setting. In the single-key case, the table will just
have one entry that applies to all domains for which we sign. In the
multi-key case, the KeyList will map From: domains to key names. The
KeyList will become just another DB handle, which will mean it can now
benefit from on-the-fly configuration via bdb, SQL or LDAP. Keys can be
added, replaced or removed at will. Selecting signatures to apply via
regex matching will still work (and will be the only way multiple
signatures can get added), but updating that table will still require a
reload.

I'm thinking a change of this size will warrant moving toward v2.0.0
rather than a v1.x.0 release because it will actually break backward
compatibility.

Comments welcome.

-MSK
Received on Wed Jan 06 2010 - 19:29:51 PST