On Fri, 5 Feb 2010, SM wrote:
>> 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.
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.
>> - 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.
My SQL isn't as strong as I'd like, so help me out here: What would that
SELECT look like?
> I assume that users will know that they have to secure their DB if they
> are storing private keys in it.
We'll definitely mention that in the documentation.
> 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).
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.
I imagine it might be helpful to check that none of this exists in the
configuration file on startup.
What would be a more appropriate design? How about this instead: Key
names in the KeyTable map to actual private keys, and records in the
SigningTable map senders to domains, selectors and key names.
Received on Sat Feb 06 2010 - 00:02:12 PST
This archive was generated by hypermail 2.3.0
: Mon Oct 29 2012 - 23:32:52 PST