external keystore option?

[Mikolaj J. Habryn]

  How does the following sound? Trying to trace operation flows
through the code is a little confusing, so I'm probably way off base
:(

  There appear to be two basic parts to this - firstly, gnupg needs to
find out what keys are available, and secondly, it needs to use them.

  Using them appears to be the province of cipher/pubkey.c. Let's
assume that gnupg has found out what keys the agent has, and is now
trying to perform some kind of operation with them.

  My first thought was to somehow overload pubkey_table so that it
would have two entries for each algorithm - one as is, and one which
references functions which communicate with the agent for
operations. This would require minor changes to all the functions that 
walk pubkey_table to not bomb if the first algorithm match fails, and
also hook into the dynamic module loading code to add the duplicate
agent entry for each loaded module, which could be messy.

  Alternatively, we can assume that when gnupg is fed the agent's
keys, it will receive something bogus for the secret key. When it
tries to do something useful with it, it will bomb with a recognizable 
error (G10ERR_BAD_MPI spring to mind). We could change all the wrapper 
functions to note this error and repeat the request to the agent to
see if it will do any better.

  I couldn't find any way of changing the functions called on a key by 
key basis, only algorithm by algorithm. Did I miss anything?

  g10/ringedit.c appears to be a good place to start teaching gnupg
about the agent. One could define a new keyring type (rt_AGENT), and
hook it appropriately in the following functions. I'm basically
looking to see where rt_GDBM is special cased, and trying to work out
what the corresponding operations would be for an agent.

  o add_keyblock_resource - simple enough, establish a connection to
the agent, cache the socket fd.

  o search - seemingly simple, but there's some questions in my
mind. The rt_GDBM case generates a fingerprint from the public key in
the packet passed as an argument to the function, and uses that as a
key. But... there's some functions, like find_keyblock_bysk, that
(judging from the name) might not have a public key as part of the
request. Why is it safe for rt_GDBM to assume that it will be there?

  A comment later in the code suggests that the search interface is
used preparatory to doing modifications to the keystore - is it /only/ 
used for this? ie, assuming that gnupg isn't going to have control
over the agent, can implementing the search operation be skipped?

  The second part of this question is where does the public key
initially come from, if not search? Which ties in to...

  o enum_keyblocks - am I correct in guessing that this is the
interface used for populating gnupg's idea of what keys are available
for it to use? I'm getting a little bit lost in all the various packet 
types, but here's the idea floating uppermost in my mind:

  If enum_keyblocks is indeed what is called as the first contact with 
a keystore, can I get away with simply populating the KBNODE(?) with a
full public key and a bogus secret key (assuming the second option for 
using the key that I mentioned above)? This would mean that for all
uses of this key that don't directly use the secret key,
enum_keyblocks would already have all of the required data to handle
them.

  Sorry if this is as confused as I am :)

m.