Update README.md.

1 files changed, 16 insertions, 71 deletions

diff --git a/README.md b/README.md
index be84f6b..2ddcb09 100644
--- a/README.md
+++ b/README.md
@@ -28,81 +28,30 @@ the necessary type checking.
 As of this writing, the implementation supports only the RSA, SHA-1,
 and SHA-2 algorithms, but the design is intended to be extensible.
 
-Underlying cryptographic support is via [Cryptlib][], which may need
-to change (more on this below).
+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 too).
+also need to change (more on this below).
 
 Testing to date has been done using the `bin/pkcs11/` tools from the
-BIND9 distribution and the `hsmcheck` tool from the OpenDNSSEC
-distribution.  Beyond the test results (such as they are) reported by
-these tools, the primary test of whether the PKCS #11 code is working
-as expected has been validation of the signed DNSSEC data generated by
-`hsmcheck -s`, via a script using [DNSPython][].
+BIND9 distribution, the `hsmcheck` and `ods-hsmutil` tools from the
+OpenDNSSEC distribution, and the `hsmbully` diagnostic tool.  Beyond
+the test results (such as they are) reported by these tools, the
+primary test of whether the PKCS #11 code is working as expected has
+been validation of the signed DNSSEC data generated by `hsmcheck -s`,
+via a script using [DNSPython][].
 
 In a nutshell, the current state is that the code runs without
 throwing any obvious errors, and generates what DNSPython thinks are
-good signatures.  Much more testing will be required, by a much wider
-variety of test tools.
+good signatures.  More testing would be a really good idea.
 
 
-## Open issues ##
+## Open issue: SQLite3 ##
 
-Two critical design choices in this software were made with full
-knowledge that we might need to change them later:
-
-* The use of Cryptlib as a provider for the underlying cryptographic
-  operations, and
-
-* The use of SQLite3 as the object store.
-
-
-### Cryptlib ###
-
-[Cryptlib][] is a very nice piece of software, but it's not really
-designed for use under something like [PKCS11][].  It seemed worth a
-try anyway, because it would have been nice to be able to use
-Cryptlib's RPC mechanism, take advantage of Cryptlib's rule-based data
-protection system, and so forth, but implementing PKCS #11 requires
-doing various things which Cryptlib quite correctly discourages.  So,
-not a perfect fit.
-
-The current code works with Cryptlib's software RSA implementation,
-primarily due to an oddity of RSA: once one has handled the PKCS #1.5
-padding, the RSA signature and decryption (sic) operations are
-mathematically identical.  Fine so far as this goes, but:
-
-* This probably does not hold for other signature algorithms (well,
-  the math certainly does not, I haven't yet investigated what the
-  Cryptlib API does if one attempts to "decrypt" using an ECDSA key);
-  and
-
-* The Cryptlib manual says that there are some extra protections
-  around keys stored in hardware devices that would forbid using this
-  trick with an FPGA implementation of RSA.
-
-The latter (extra protections) is probably something we could work
-around if necessary, but the former may make this a moot point.
-
-All of the above notwithstanding, Cryptlib was a reasonable choice for
-the initial implementation, as we had no FPGA RSA to work with and
-needed to develop with *something*.  Surprisingly little effort has
-gone into Cryptlib-specific code (probably less than would have been
-required with, eg, OpenSSL, because the Cryptlib API is cleaner).
-
-Bottom line: we haven't lost anything by this approach, we're just not
-done yet.
-
-There are a few other issues with using Cryptlib in this context which
-I will detail if they become relevant, but I'll skip them for now
-since I don't think they'll end up being relevant here.
-
-
-### SQLite3 ###
-
-The choice of [SQLite3][] for the data store was made with several
-factors in mind:
+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);
 
@@ -118,10 +67,8 @@ factors in mind:
   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: it fails the minimum complexity test,
-and at least in the current implementation requires two separate kinds
-of storage, one for keys (currently a PKCS #15 keyring) and one for
-attributes (the SQLite3 database).
+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
@@ -136,7 +83,6 @@ 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.
@@ -147,7 +93,6 @@ Code written for the [Cryptech][] project is under the usual Cryptech
 BSD-style license.
 
 [PKCS11]:    http://www.cryptsoft.com/pkcs11doc/STANDARD/       "PKCS #11"
-[Cryptlib]:  https://www.cs.auckland.ac.nz/~pgut001/cryptlib/   "Cryptlib"
 [SQLite3]:   https://www.sqlite.org/                            "SQLite3"
 [DNSPython]: http://www.dnspython.org/                          "DNSPython"
 [Cryptech]:  https://cryptech.is/                               "Cryptech"