Standalone Subsystems

Overview

Dogtag PKI subsystems such as a Data Recovery Managers (DRMs) and an Online Certificate Status Protocol (OCSP) Managers have always required the presence of a Certificate Authority (CA) to be part of a PKI deployment.

Recently, however, it has been determined that it would be beneficial to be able to allow some of these PKI subsystems (e.g. DRM and OCSP) to be setup as stand-alone systems which do not include a CA in their PKI deployment.

It should be emphasized that these stand-alone PKI subsystems are not expected to communicate with any other PKI subsystems (with the exception of their clones).

Associated Bugs and Tickets

• Ticket #1237: provide option for ca-less drm install

• Ticket #1284: Review panel for configuration wizard

• Ticket #1289: Provide option for a stand-alone OCSP Manager

Use Cases

See Standalone Subsystems Use Cases.

Operating System Platforms and Architectures

This design is initially targeted for the following platforms:

• DRM [PKI 10.1]

  • 32-bit Fedora 20 [i686]

  • 64-bit Fedora 20 [x86_64]

• OCSP [PKI 10.2]?

  • TBD

Design

This design will apply to the following PKI subsystems:

• DRM

• OCSP

Installation and configuration of a PKI stand-alone subsystem will consist of one of the following:

• pkispawn (two pass installation and configuration utilizing the RESTEasy interface)

  • First invocation will create the following certificate requests for the specified PKI subsystems:

    • DRM - Transport Certificate Request, Storage Certificate Request, SSL Server Certificate Request, Subsystem Certificate Request, Audit Log Signing Request, and Administration Certificate Request

    • OCSP - OCSP Signing Certificate Request, SSL Server Certificate Request, Subsystem Certificate Request, Audit Log Signing Request, and Administration Certificate Request

  • All requests generated by the first invocation will be submitted to and signed by an External CA.

    • QUESTION: Do we want to allow/support the ability for individual certificate requests to be signed by different External CA’s?

    • ANSWER: While it may be possible to manually setup all of the trusts, we would recommend that the same External CA be used for all certificate requests.

  • Second invocation will import the following certificates that have been signed by an External CA into the specified PKI subsystems:

    • DRM - Transport Certificate, Storage Certificate, SSL Server Certificate, Subsystem Certificate, Audit Log Signing Certificate, and Administration Certificate. Additionally, the External CA Certificate and its Chain will be imported and trusted.

    • OCSP - OCSP Signing Certificate, SSL Server Certificate, Subsystem Certificate, Audit Log Signing Certificate, and Administration Certificate. Additionally, the External CA Certificate and its Chain will be imported and trusted.

• pkispawn (installation) + browser GUI (configuration)

  • all certificate requests and certificates will be requested/generated/installed during the browser GUI configuration

Note	Until Ticket #1284: Review panel for configuration wizard has been completed, the browser GUI configuration will utilize the legacy interface rather than the RESTEasy interface.

PKI stand-alone subsystems will consist of their own security domain (i.e. they will not depend upon a CA being present as a part of their PKI deployment).

PKI stand-alone subsystems are not expected to communicate with any other PKI subsystem (with the notable exception of any master-clone communication).

PKI stand-alone subsystems will have the ability to be cloned with the imposed restriction that any clone of a stand-alone PKI subsystem must utilize the master stand-alone PKI subsystem as its security domain.

Implementation

See Stand-alone PKI Subsystems.

Major Configuration Options and Enablement

See Stand-alone PKI Subsystems.

Cloning

PKI stand-alone subsystems will have the ability to be cloned with the imposed restriction that any clone of a stand-alone PKI subsystem must utilize the master stand-alone PKI subsystem as its security domain.

Updates and Upgrades

Since this is a brand new feature, it should require no update/upgrade logic.

Tests

See Testing Standalone Subsystems.

Dependencies

This design should require no new package or library dependencies.

Packages

This design will be contained within the existing packages, and therefore should require no new packages.

External Impact

T.B.D.

History

ORIGINAL DESIGN DATE: September 5, 2013

Proposed Solution: When the initial patch was provided (as documented in Ticket #1237: provide option for ca-less drm install), it was believed that no security domain would be required. Additionally, the initial patch attempted to provide a solution for the legacy GUI browser interface rather than the pkispawn RESTEasy interface.

Reason for Rejection: Upon closer examination of the code, it was realized that in order to provide the ability for a stand-alone PKI component to perform cloning, a security domain would be required. Additionally, the order of the implementation phases as described in this ticket was revised such that the initial implementation would address the pkispawn RESTEasy interface rather than the legacy GUI browser interface.