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

Entries in session_attribute seem like a perfect match for the first requirement. I've chosen the following dedicated names for related association types:

• 'sign_key'
• 'crypt_key'
• 'auth_key' (future)

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,

 * primary key
 i has dedicated index: 

Discussion welcome.