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.
- Check client-level compatibility with Longhorn.
  - Currently getting an error encoded as other than typed-data.  This might
    describe what's going on:
    http://marc.info/?l=samba-technical&m=114263219025559&w=2)
- Implement "best one in the token" certificate selection to better handle
  cases where multiple maybe-acceptible certs are stored on the card.
