Re: KeyList revisited

From: SM <sm_at_resistor.net>
Date: Fri, 05 Feb 2010 17:09:41 -0800

Hi Murray,
At 16:01 05-02-10, Murray S. Kucherawy wrote:
>What I have ended up doing is loading the entire KeyTable into
>memory so it can be searched quickly and cheaply and private keys
>don't need to be re-read repeatedly. The SignTable though will be
>queried for each message.

I would have done the same or else implemented some caching
mechanism. A DB should be able to do 2000 queries per second. Let's
assume that the system is not optimized. We should at least be able
to do 200 queries per second (read operations). What's the maximum
number of messages we can sign? if it is below the number of reads,
we don't need a cache.

>My SQL isn't as strong as I'd like, so help me out here: What would
>that SELECT look like?

It's a hack. I'll use "$" to represent a catch-all:

SELECT privkey FROM table WHERE sdomain = '$' OR sdomain = ('_at_'
||domain) ORDER BY sdomain ASC

As we are ordering the results, we will get the domain's private key
before the catch-all in our results. We can have more than one
result. The first one should be the narrowest match. The second
one, if present, will be the catch-all private key. I'll need to
test the example to expand that to include user_at_host. If the
database supports stored procedures, we can do the sorting for the
more complex case where we have hostname, domain name, etc. If we
don't hardwire the logic in OpenDKIM, a wider range of cases can be supported.

>You're right, it's possible to have two different keys that name the
>same domain and selector but refer to different key files, which of
>course is impossible to resolve if sent to a verifier.

So we should avoid signing with the same selector/domain more than
once. We already know that the data may not be valid if there is
more than one match. The selector/domain is used as a composite
index in a SQL DB. The LDAP case is be different.

>I imagine it might be helpful to check that none of this exists in
>the configuration file on startup.

It would be too much overhead to do a data consistency check at
startup. By thinking for the user, we will have to limit the
functionality we offer. There can always be a utility that does the
basic tests for ease of debugging.

I'll get back to the last question later.

Regards,
-sm
Received on Sat Feb 06 2010 - 01:10:04 PST