KeyList revisited

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Tue, 2 Feb 2010 23:19:49 -0800 (PST)

As soon as the OpenLDAP branch merge is complete (should be soon), I will
be tackling the KeyList porting to DB API and its possible redesign. I'd
like to reopen it for discussion once more before I head down this road.
There are basically two things to consider:

1) Is the proposed design acceptable, or can someone think of something
better? Or should it just be left alone?

2) Does the proposed change warrant a minor version number (e.g. 1.3.0)
because there are new features, or a major one (e.g. 2.0.0) because there
are major configuration file changes?

So, first, where we are today:

One can either have a single signing key that is used for all domains
passing through the filter that get signed, or one can use a KeyList that
maps regular expressions (matched against the user_at_host) to
domain/selector/key-path triples. This is the only format a KeyList can
have at present. This serves two important purposes: (a) Pattern
matching for key selection, and (b) the KeyList is walked entirely
looking for matches when MultipleSignatures is enabled.

The main goal of the re-working is to make it possible to use any database
style, not just a regular expression file. That includes SQL, flat files,
regex files, LDAP, or whatever else is supported.

Obviously walking an entire LDAP directory or SQL database is not
practical, so the handling function for the KeyList will have to instead
be split as follows:

- for a regex file, do what's done now and possibly return multiple
matches

- for all other types, try user_at_hostname, then just hostname, then
user_at_.domain, then just .domain, then try other superdomains in the same
way, and then finally try some default like "*"

- in case MultipleSignatures is set, this function has to have some state
saved so that matches can be returned but the search continues (or an
array or list is returned)

There are two other issues to consider. Where a filter (or a cluster of
filters) is querying a remote database like LDAP or SQL, it may not make
sense to have the KeyList value returned refer to the path to a private
key. I propose to have those values interpreted such that if the path
starts with a "/" then the filter will try to open that file, otherwise
the path is interpreted as being the key itself.

The other issue is whether or not each entry should be of the form
domain:selector:key-path as it is now. My thinking is that there could be
lots of data repetition at a large site if all key records require all
three values. An alternative I'm considering is to have the KeyList
replaced by two other data sets: a KeyTable that maps arbitrary key names
to domain/selector/key-path and a SigningTable that maps addresses and
domains to key names. For example:

KeyTable:
key1 domain1, selector1, keydata1
key2 domain2, selector2, keydata2
key3 domain3, selector3, keydata3

SigningTable:
user1_at_domain1 key1
user2_at_domain1 key1
user3_at_domain1 key1
domain1 key2
domain2 key3

So the three specific users in domain1 all get key 1, and they also get
key 2 (and so does everyone else in domain1), and everyone in domain2 gets
key 3.

The KeyList as it exists now would be dropped (though retaining
back-compatibility is possible, if icky). This would allow a site to have
a set of "x" signing keys for "y" users/domains that need signing, and the
amount of data stored can be a great deal smaller when "x" is less than
"y". But maybe this isn't really a problem in the first place, and this
change would needlessly complicate things by requiring configuration
changes possibly a whole new version number.

So the KeyList function has to be updated to use the new DB API and
thus to work with LDAP and SQL, but I'm undecided on the splitting I've
discussed. Does anyone else have any thoughts?

-MSK
Received on Wed Feb 03 2010 - 07:20:10 PST