= Db storage organization for CryptoPlugin =
Right now I can think of only two requirements for plugin-specific information:
 * user <--> key associations
 * (detached) signature storage 

== Common "parasite" storage ==
Session attributes are easily accessible related on a client sessions base in Trac's Request object (`req.session`), without the need for a direct db connection.
So entries in Trac db table `session_attribute` seem like a perfect match for the first requirement - no need for an own db table here.
I've chosen the following dedicated names for related association types:
 * 'sign_key'
 * 'crypt_key'
 * 'auth_key' (''future'')
Their meaning should be easily guessable from these names.

== Dedicated "private" storage ==
For storing signature data we could resort to inline signed data, but I felt that this choice would restrict possible use cases too much.
So I chose detached signatures as the default. Resources stay unaltered by signing, and you will be able to sign text content as well as arbitrary binary/file data.

After 3 internal iterations current db schema draft is like so:
{{{
table `crypto_sign`
  * realm,
  * id,
  * version,
  * fragment,
i * key_id,
    signature
i   time,

Legend:
  * primary key
i   has dedicated index
}}}

Discussion welcome.