diff options
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 40 |
1 files changed, 0 insertions, 40 deletions
@@ -38,9 +38,6 @@ extensible. The underlying cryptographic support comes from the [Cryptech][] `libhal` package. -The object store is currently implemented using [SQLite3][], which may -also need to change (more on this below). - Testing to date has been done using the `bin/pkcs11/` tools from the BIND9 distribution, the `hsmcheck` and `ods-hsmutil` tools from the OpenDNSSEC distribution, the `hsmbully` diagnostic tool, and a @@ -56,42 +53,6 @@ signatures, and passes some fairly basic tests. More testing would be a really good idea. -## Open issue: SQLite3 ## - -The choice to use use of [SQLite3][] as the PKCS #11 object store was -made with full knowledge that we might need to change it later. That -said, we made the initial choice with several factors in mind: - -* Relative ease of development (it's all just SQL schemas and queries); - -* Relative ease of data normalization (foreign key constraints, - etcetera) and debugging (command line tool available for arbitrary - direct queries against stored data); - -* Licensing (SQLite3 is explictly public domain); - -* Support for embedded systems; and - -* Surprisingly small object code size (everything I found that was - significantly smaller had license issues, eg, gdbm). - -Overall, this has worked relatively well, but it's not necessarily -what we want in the long run, if only because it fails the minimum -complexity test. - -The current implementation keeps much of the SQL data in an in-memory -database: only "token objects" are stored in on disk. This matches -the required PKCS #11 semantics, and using the same mechanism to -handle both session objects and token objects simplifies the code -considerably, but it does mean that much of the SQL code is really -just dealing with a weird encoding of in-memory data structures. - -At this point the schema may be stable enough that it would make sense -to consider reimplementing without SQL. It's not urgent as long as -we're just doing proof-of-concept work, but is something we should -consider seriously before deciding that this is ready for "production" -status. - ## Copyright status ## The [PKCS11][] header files are "derived from the RSA Security Inc. @@ -102,6 +63,5 @@ Code written for the [Cryptech][] project is under the usual Cryptech BSD-style license. [PKCS11]: http://www.cryptsoft.com/pkcs11doc/STANDARD/ "PKCS #11" -[SQLite3]: https://www.sqlite.org/ "SQLite3" [DNSPython]: http://www.dnspython.org/ "DNSPython" [Cryptech]: https://cryptech.is/ "Cryptech" |