$Id$

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.



To do list:

- publication protocol and implementation

- manifest generation

- 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.