Sub-CAs overview
by 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
9 years, 4 months
[PATCH] 0026 Add lightweight sub-CA support
by Fraser Tweedale
G'day,
The first major patch for lightweight sub-CAs is attached for
review. Some important features are not yet implemented in this
patch:
- Sub-CA creation
- Caching of sub-CA instances
- Signing key replication for clones
- CRLs (the OCSP servlet works for sub-CAs, however)
- Sub-CA support is possibly missing from some web servlets /
templates. Let me know if you hit any.
Because sub-CA creation is not implemented, if you want to test this
patch you will need to:
1. Use the top-level CA to sign a sub-CA certificate and manually
install it in the NSSDB with the nickname:
"${TOPLEVEL_CA_NICKNAME} ${SUB_CA_HANDLE}"
2. Create the sub-CA certificate repository OU:
"ou=${SUB_CA_HANDLE},ou=certificateRepository,ou=ca,o=pki-tomcat-CA"
3. When submitting requests or other queries via HTTP, edit the
initial link target or form action to include the query parameter:
"?caRef=${SUB_CA_HANDLE}"
(Subsequent pages should not require this intervention.)
I have also updated the design proposal with some refinements and
details of the implementation so far:
http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs
Looking forward to your feedback / bug reports!
Fraser
9 years, 4 months
[pki-devel][PATCH] 0031-Ticket-572-CRL-scheduler-adds-extra-CRL-generation-a.patch
by John Magne
Patch addresses the issue with least amount of change, isolated to the specific problem case.
The case is when we have a daily schedule that spans only one day. When the last member of the
daily schedule fires, the system thinks the next update should be at midnight the following morning
instead of the first entry of the schedule for the next day.
9 years, 4 months
[PATCH] patch to nuxwdog to add systemd support
by Ade Lee
The attached patch adds systemd support. When the STARTED_BY_SYSTEMD
environment variable is set, nuxwdog will call "systemd-ask-password" to
get the password from systemd.
To get this to work, we needed to temporarily disable the signal handler
used to handle SIGCHLD so as not to interfere with the handling of the
response from systemd-ask-password. Also fixed an error condition.
Please review,
Ade
9 years, 4 months
