$Id$

Python RPKI production tools.

Requires Python 2.5.

External Python packages required:

- lxml, which in turn requires the libxml2 C libraries.

  FreeBSD: /usr/ports/devel/py-lxml

- MySQLdb, which in turn requires MySQL client and server.  I'm
  testing with MySQL 5.1.

  FreeBSD: /usr/ports/databases/py-MySQLdb

- TLSLite, which pulls in other crypto packages.

  FreeBSD: /usr/ports/security/py-tlslite

- Cryptlib, at the moment just to support TLSlite but may end up using
  it for other things later.

  FreeBSD: /usr/ports/security/cryptlib

  ...but the FreeBSD port doesn't (yet?) install the Python bindings,
  sigh, so at the moment you have to do that by hand:

  # cd /usr/ports/security/cryptlib
  # make install
  # cd work/bindings
  # python setup.py install
  # cd ../..
  # make clean

- Eventually I expect that this will require an event-handling package
  like Twisted, but I'm not there yet.

We also use a hacked copy of the Python OpenSSL Wrappers (POW)
package, but our copy has enough modifications that it's expanded in
the Subversion tree.  Depending on how this all works out, I may end
up splitting the POW.pkix module out of the POW package and using it
with Cryptlib, as the POW.pkix package is 98% about doing ASN.1 in
pure Python and only 2% about any kind of crypto.



To do list:

- timestamps are a mess.  we have four different kinds already:
  seconds from epoch, the the two flavors of timestamps used
  in asn.1, and the timestamps used in mysql.  need a
  unifying class to hide all this nastiness.

- publication protocol and implementation

- manifest generation

- subsetting (req_* attributes in up-down protocol)

- revocation and crl generation

  - need to keep data on unexpired revoked certs to generate crl

  - ever need to delay revocation of old certs to give their
  replacements time to propegate?

  these two may imply that we need more fields in child_cert table to
  indicate whether a cert is dead, eg, a date field which is NULL if
  the cert is still live, otherwise is the date after which it should
  be in the crl

- publication hooks everywhere - need not wait for protocol, can just
  log what would happen for now

  - cert publication

  - crl publication

  - manifest publication

  - withdrawal of all of the above

- child batch processing loop, eg, regeneration or removal of expired
  certs, crl and manifest update, etc

  hmm, should this be an iteration over child_cert objects or over ca
  objects?  probably the latter as the ca is the actor in pretty much
  everything that might need to be done

  figuring out whether to regenerate or remove expired certs requires
  some of the same data as crl generation

- tiny up-down root server -- no sql or left-right needed, just config
  file, http server, static root cert and key.  in theory this should
  just be a matter of subtyping the main up-down code while overriding
  the serve_pdu() methods.

  things we'd need in a config file for this:

  - the one and only issuer cert (self-signed in this special case)
  - the one and only issuer private key id
  - filename in which to store the one and only subject cert
  - bsc info for one and only child
  - https server key and cert
  - validity interval to use when issuing
  - publication urls for issuer cert, subject cert, crl, and manifest
  - https and cms data for publication server
  - resources to issue?  or just copy/inherit from self-signed?

- Haven't done anything about db.commit() and db.rollback() yet, for
  that matter haven't yet whacked MySQL to enable those features.

- Access to object data attributes really ought to be through accessor
  methods so that the .set() method can set the sql_dirty flag
  automagically.  Not done yet.

- Hmm, I seem to have goofed on the bsc table, need a column for the
  hash algorithm after all, as it's not intrinsic to the key.  Probably
  ought to let it be set independently of the key too.  But for the
  moment I'm only supporting 2048-bit RSA with SHA-256 digests, so
  fixing this is not urgent.