Skip to content

Standalone Subsystems

Jump to bottom
Endi S. Dewata edited this page Jun 10, 2021 · 7 revisions

Overview

PKI subsystems such as KRA and OCSP have always required the presence of a 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. KRA 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

Use Cases

Operating System Platforms and Architectures

This design is initially targeted for the following platforms:

  • KRA [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:

  • KRA

  • 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:

      • KRA - 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:

      • KRA - 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

Major Configuration Options and Enablement

KRA

Master

An example of a first-pass default.cfg override file for a stand-alone KRA might look something like this:

[DEFAULT]
pki_admin_password=<password>
pki_client_database_password=<password>
pki_client_pkcs12_password=<password>
pki_ds_password=<password>
[KRA]
pki_standalone=True

An example of a second-pass default.cfg override file for a stand-alone KRA might look something like this:

[DEFAULT]
pki_admin_password=<password>
pki_client_database_password=<password>
pki_client_pkcs12_password=<password>
pki_ds_password=<password>
[KRA]
pki_standalone=True
pki_external_step_two=True

Each stand-alone KRA instance will contain the following parameter in its CS.cfg file:

kra.standalone=true
Note
 kra.standalone will be set to false on non-standalone KRAs, and this parameter will not be present in legacy KRAs.

Clone

An example of a first-pass default.cfg override file for a cloned KRA of a stand-alone KRA might look something like this:

T.B.D.

An example of a second-pass default.cfg override file for a cloned KRA of a stand-alone KRA might look something like this:

T.B.D.

Each cloned KRA of a stand-alone KRA instance will contain the following parameter in its CS.cfg file:

kra.standalone=true
Note
 kra.standalone will be set to false on non-standalone cloned KRAs, and this parameter will not be present in legacy cloned KRAs.

OCSP

Master

An example of a first-pass default.cfg override file for a stand-alone OCSP might look something like this:

[DEFAULT]
pki_admin_password=<password>
pki_client_database_password=<password>
pki_client_pkcs12_password=<password>
pki_ds_password=<password>
[OCSP]
pki_standalone=True

An example of a second-pass default.cfg override file for a stand-alone OCSP might look something like this:

[DEFAULT]
pki_admin_password=<password>
pki_client_database_password=<password>
pki_client_pkcs12_password=<password>
pki_ds_password=<password>
[OCSP]
pki_standalone=True
pki_external_step_two=True

Each stand-alone OCSP instance will contain the following parameter in its CS.cfg file:

ocsp.standalone=true
Note
 ocsp.standalone will be set to false on non-standalone OCSPs, and this parameter will not be present in legacy OCSPs.

Clone

An example of a first-pass default.cfg override file for a cloned OCSP of a stand-alone OCSP might look something like this:

T.B.D.

An example of a second-pass default.cfg override file for a cloned OCSP of a stand-alone OCSP might look something like this:

T.B.D.

Each cloned OCSP of a stand-alone OCSP instance will contain the following parameter in its CS.cfg file:

ocsp.standalone=true
Note
 ocsp.standalone will be set to false on non-standalone cloned OCSPs, and this parameter will not be present in legacy cloned OCSPs.

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.

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 KRA 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.

Tip
 To find a page in the Wiki, enter the keywords in search field, press Enter, then click Wikis.
Clone this wiki locally