Hello, All.

Because current architecture of key holders doesn't suite my expectations, I'm going to
change it in Avalerion this way:

Database crypto-plugin receives from an engine provider a callback that is set with
setDbCryptCallback. It have a choice: obtain key by its own way or use the callback to
send request for it to higher layers. For some reasons it may want to do both: for
example, get ssh key from file and use callback to ask for passphrase for it. It is all up
to plugin's author.
Y-valve set callback to provider. In the callback's handler it enum configured key
holders and ask if one of them have requested information. This differ from current scheme
because Y-valve set its own handler, not just bypass callback set by application.
Every key holder plugin have the same choice as crypto-plugin: handle request itself or
send it higher via callback that application set to Y-valve.
There is a default built-in key holder named "Callback" (I have no imagination, sorry),
that is dumb and just pass the request to the application's callback (if any).
Server (as currently) set to Y-valve callback that marshal request to client.
On client side whole story is repeated with remote provider, Y-valve and user application.

This schema should allow to provide key at any point of hierarchy and thus let even
applications that are not aware of key (such as isql or Flame Robin) to work with
encrypted database without need of keeping the key on server where it can be lost among
with database.

Does anybody see a flaw in this architecture other than vulnerability to a
man-in-the-middle attack?

--
WBR, SD.