Lightweight CA - dogtagpki/pki GitHub Wiki

Overview

Dogtag supports operation as a sub-CA, but only as a separate instance. This document proposes ''lightweight sub-CAs'', where one or more sub-CAs can reside alongside the primary CA in a single instance. other subsystems including the parent CA.

This feature is aimed for inclusion in Dogtag 10.3, to be included in Fedora 21.

Terminology

  • host CA: The existing signing capability of the CA subsystem and associated key(s), certificates and data. Put another way, this is the "highest-level" CA in a Dogtag instance, which may or may not be a root CA.

  • lightweight CA: A signing capability and associated key(s), certificates and data, which is hosted in the CA subsystem alongside the host CA.

  • sub-CA: A lightweight CA that is certified by the host CA or by another sub-CA.

  • authority ID: A UUID identifying a CA. All lightweight CAs and the host CA have an authority ID. In records that may include an authority ID, the absense of an authority ID typically implies the host CA.

  • subsystem: A Dogtag instance subsystem, i.e. that which is created by pkispawn(8). When referring to subsystems within a CMS instance, the term ''CMS subsystem'' is used.

Associated Bugs and Tickets

Multiple subsystems in a single instance

Dogtag 10.0 introduced ability to host multiple subsystems within a single instance by hosting the subsystems' HTTP interfaces at different paths. How this change was carried out might inform and influence the sub-CA change.

Top-level Tree

A design proposal to avoid proliferation of replication agreements, justified by FreeIPA use cases (including lightweight sub-CAs). The proposed change is to enhance pkispawn to create subsystem databases as subtrees under a top-level tree, such that a single replication agreement can replicate all subsystems.

Support for multiple OCSP signing certificates

Ticket for adding support for multiple OCSP signing certificates. Each sub-CA will need its own OCSP signing certificate.

Use cases

See Lightweight CA Use Cases.

Operating System Platforms and Architectures

Linux (Fedora, RHEL, Debian).

Design

See Lightweight CA Design.

Implementation

See Lightweight CA Implementation.

Major configuration options and enablement

The ''features'' facility shall be used to enable or disable the ''creation'' of lightweight CAs. The relevant configuration in CS.cfg shall be:

features.authority.description=Lightweight CAs
features.authority.enabled=true
features.authority.version=1.0

Instances shall default to enabling the creation of lightweight CAs.

The pkispawn(8) configuration format should be updated to provide a way to control this configuration when deploying an instance.

Cloning

There are no special provisions for cloning. Lightweight CA signing keys shall be replicated via the KeyReplicator mechanism described previously.

Upgrading

Several web templates have been updated and these updates will need to be deployed on existing instances by pki-server-upgrade(8).

Tests

Dependencies

  • Secure key/secret replication service.

Packages

External Impact

History

See Lightweight CA History.

⚠️ **GitHub.com Fallback** ⚠️