| 1 | = Db storage organization for CryptoPlugin = |
| 2 | Right now I can think of only two requirements for plugin-specific information: |
| 3 | * user <--> key associations |
| 4 | * (detached) signature storage |
| 5 | |
| 6 | == Common "parasite" storage == |
| 7 | Entries in `session_attribute` seem like a perfect match for the first requirement. |
| 8 | I've chosen the following dedicated names for related association types: |
| 9 | * 'sign_key' |
| 10 | * 'crypt_key' |
| 11 | * 'auth_key' (''future'') |
| 12 | |
| 13 | == Dedicated "private" storage == |
| 14 | For storing signature data we could resort to inline signed data, but I felt that this choice would restrict possible use cases too much. |
| 15 | 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. |
| 16 | |
| 17 | After 3 internal iterations current db schema draft is like so: |
| 18 | {{{ |
| 19 | table `crypto_sign` |
| 20 | * realm, |
| 21 | * id, |
| 22 | * version, |
| 23 | * fragment, |
| 24 | i* key_id, |
| 25 | signature |
| 26 | i time, |
| 27 | |
| 28 | * primary key |
| 29 | i has dedicated index: |
| 30 | }}} |
| 31 | |
| 32 | Discussion welcome. |