This is not an exhaustive list.

- Implement message decoding using NSS's CMS routines.  For now we'll have to
  at least keep doing the CMS message encoding ourselves because:
  - NSS can't be told to generate messages with definite-length encodings, and
    Windows appears to choke on indefinite-length-encoded messages.
  - Windows tends to use/expect DigestWithEncryption OIDs where the CMS spec
    dictates Digest OIDs, so NSS by itself can't generate a signed-data object
    which looks like what a Windows client would generate.
  Switching to NSS for decoding gives us:
  - A more feature-complete and probably more correct CMS implementation
    (well, hopefully not).
  - Less code to maintain (at some point).
- Implement support for using CRLs stored on disk.
- Implement reading of creds directly from a PKCS12 file.
  - Can't be done just now with NSS APIs.  Using a key from a PKCS12 bag
    requires that it be imported into a database, and at that point your
    side-effect is pk12util's job.
- Implement direct loading and use of PKCS11 modules.
  - Having trouble using modules which aren't already in the secmod database.
- Implement RFC4557 "stapling" of OCSP responses into the AS exchange, to
  maybe cut down on client lag and OCSP responder load.  Requires newer NSS
  than exists as of 20070205.
  - Maybe we can sign responses ourselves if our certificate has the right EKU?
- Implement a Windows-compatible server.