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