diff options
| -rw-r--r-- | README.md | 19 |
1 files changed, 14 insertions, 5 deletions
@@ -10,6 +10,12 @@ specification includes enough rope for an unwary developer to hang not only himself, but all of his friends, relations, and casual acquaintances. +Along with the PKCS #11 library itself, the package includes a +companion Python interface ("py11"), which uses the ctypes module from +the Python standard library to talk to the PKCS #11 implementation. +The Python implementation is intended primarily to simplify testing +the C code. + ## Novel design features ## @@ -25,8 +31,9 @@ the necessary type checking. ## Current status ## -As of this writing, the implementation supports only the RSA, SHA-1, -and SHA-2 algorithms, but the design is intended to be extensible. +As of this writing, the implementation supports only the RSA, ECDSA, +SHA-1, and SHA-2 algorithms, but the design is intended to be +extensible. The underlying cryptographic support comes from the [Cryptech][] `libhal` package. @@ -36,15 +43,17 @@ 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, and the `hsmbully` diagnostic tool. Beyond +OpenDNSSEC distribution, the `hsmbully` diagnostic tool, and a +preliminary set of unit tests using Python's unittest library. 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. More testing would be a really good idea. +throwing any obvious errors, generates what DNSPython thinks are good +signatures, and passes some fairly basic tests. More testing would be +a really good idea. ## Open issue: SQLite3 ## |