Hi Murray,
At 23:19 02-02-10, Murray S. Kucherawy wrote:
>1) Is the proposed design acceptable, or can someone think of
>something better? Or should it just be left alone?
The design is fine.
>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?
If there are any changes which are not backward compatible, it is
better to do them now. I recommend having the Lua feature in version 2.0.
>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:
We don't have to walk through the entire directory for SQL. It is
only a matter of doing a SELECT and processing the results. That can
be more than one record.
>- 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 "*"
Ideally, that should be done as one SQL query. The more restrictive
match wins. The user can always adapt the query to return a larger set.
>- 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)
Okay.
>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.
I assume that users will know that they have to secure their DB if
they are storing private keys in it.
>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?
You have normalized the data above. Can a key have more than one
domain and more than one domain/selector combination? Isn't it the
selector/domain that maps to a key? The difference here is that we
have a one to many relationship where the selector/domain is unique
(for indexing).
Regards,
-sm
Received on Fri Feb 05 2010 - 22:58:30 PST
This archive was generated by hypermail 2.3.0
: Mon Oct 29 2012 - 23:32:52 PST