[Pki-devel] Sub-CAs overview

[Fraser Tweedale]

Hi Christian,

The purpose of this mail is to give you a *brief* tour of important
aspects of the sub-CAs feature and its implementation, and provide
some orientation for implementing the Python API for subcas, for
reviewing and testing the feature, or for helping with development.
Full(er) details are in the design proposal:
http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs

I have copied pki-devel@ because this overview is likely to be of
interest to anyone reviewing or testing the sub-CAs feature.

On with the details:

- The initial release of sub-CAs is exclusively to support sub-CAs
  in FreeIPA, and will not initially be supported as a general
  feature.  As such, some features (such as Dogtag web-UI for
  dealing with sub-CAs) are deferred.

- Sub-CAs can be created underneath the "top-level CA" (which may or
  may not be a root CA), or underneath other sub-CAs.  Eventually we
  will support hosting unrelated CAs but this is not an immediate
  requirement, and is implemented.

- class SubCAService implements the SubCAResource interface.  This
  is the REST API that the Python subca API will abstract.  It
  currently provides two methods - createCA and getCA.  For now, we
  are not intending to provide a delete method, but we may need to
  implement disable/enable and list/search methods.

- Submitting certificate or revocation requests and other
  interactions with the web servlets involve a new URL query
  parameter - `?caRef=<subca-handle>'.  When testing the feature,
  you only need to do this on the first page of the workflow - it
  will then be propagated through subsequent pages (if it is not
  propagated, that is a bug)

- The main `CertificateAuthority' class grew a `getSubCA(handle)'
  method.  This splits the handle apart and recursively searches for
  the appointed sub-CA.

- Signing keys are stored in the same NSSDB as the top-level CA's
  signing key; the key nickname is suffixed with the ca's handle.

- All CAs/Sub-CAs in an instance share a single, flat request queue,
  but certificates are stored in nested certificate repositories.

- The caRef (if any) is stored with each request (which has
  'objectclass: extensibleObject') for locating the appointed sub-CA
  or certificate repository when the request is processed.  The key
  is "req_authority_ref".  See `IEnrollProfile.java'

- The sub-CA signing key is used for OCSP signing as well.  OSCP/CRL
  signing delegation could be implemented later.


For the Python API, it will probably follow a similar pattern to the
existing modules, e.g. `pki.cert' or `pki.profile'.  The Python API
lives under `base/common/python/'.

OK, let me know your questions!

Cheers,
Fraser