Skip to content

KRA Transport Key Rotation

Jump to bottom
Endi S. Dewata edited this page Feb 14, 2021 · 1 revision

Overview

It is a good security practice to rotate keys. In this case, key rotation support will be added for KRA transport keys. For this purpose, support for a second KRA transport key will be added.

Here are requirements for KRA transport keys rotation provided by customers:

  • The requirement is to rotate KRA transport keys periodically.

  • KRAs and CAs have to have ability to work with multiple transport public/private key pairs simultaneously as big enterprise deployments cannot switch transport keys in a very small time window.

  • KRA transport key rotation has to be provided as graceful transition from old to new transport key without loss of client services. KRA has to be able to utilize simultaneously at least two transport keys.

  • Graceful transport key rotation has to be provided for KRAs using HSMs.

Associated Bugs and Tickets

Ticket 129 is the main ticket for KRA transport key rotation. Subtasks defined through th following tickets:

  • Ticket 729 - CA to include transport certificate when submitting archival request to KRA

  • Ticket 730 - KRA to detect presence of transport certificate attribute in submitted archival request and validate transport certificate against KRA’s transport key list

  • Ticket 731 - KRA to provide handling for alternative transport key based on detected and validated transport certificate arriving as a part of extended archival request

  • Ticket 732 - requesting new transport certificate

  • Ticket 733 - obtaining issued certificate

  • Ticket 734 - importing of new transport certificate and keys to KRA’s NSS database

  • Ticket 735 - updating of KRA configuration to reflect existence of new transport certificate and keys

  • Ticket 736 - propagation of new transport certificate and keys to KRA clones

  • Ticket 737 - replacement of the current transport certificate and keys during process of transfer of the new transport certificate and keys to become the current one.

  • Ticket 738 - propagation of new transport certificate to all CAs communicating with updated KRA (including CAs' clones)

Use Cases

To rotate KRA transport key you need to generate new transport key pair, submit certificate request, and retrieve new transport certificate. New transport key pair and certificate needs to be included in KRA’s configuration to provide support for second transport key. Once KRA supports two transport keys, administrators can start transition CAs to new transport key. KRA support for the old transport key can be removed once all CAs are moved to the new transport key,

Operating System Platforms and Architectures

This feature will be provided for Dogtag 10.1.

Design

Support for KRA transport key rotation, requires the following main sub features:

  • ability to distinguish KRA transport keys used in archival process in new KRA environment supporting dual transport keys

  • new process of KRA transport certificate generation

  • new process of KRA transport certificate propagation

Due to time restrictions only the first subtask will be implemented. Other two subtasks are going to be provided as a set of manual procedures.

Adding Ability to Distinguish KRA Transport Keys

There were few methods considered for adding ability to distinguish KRA transport keys used in archival process in new KRA environment supporting multiple transport keys. Considered methods included simple mapping, sequential decrypting of symmetric key, and and connector request extension. Mapping method was rejected as manual and therefore error prone method. Sequential decrypting of symmetric key was rejected as very expensive for RSA algorithms. Connector requests are designed to be extended so connector requests extension has been selected as the method providing backwards compatibility and performance. Transport certificate will be used to identify transport key used in archiving option and for that reason transport certificate will be transfered through CA-KRA connector.

Providing ability to distinguish KRA transport keys used in archival process in new KRA environment supporting dual transport keys requires:

  • Ticket 729 - CA to include transport certificate when submitting archival request to KRA

  • Ticket 730 - KRA to detect presence of transport certificate attribute in submitted archival request and validate transport certificate against KRA’s transport key list

  • Ticket 731 - KRA to provide handling for alternative transport key based on detected and validated transport certificate arriving as a part of extended archival request

Backward Compatibility

  • Old CAs with new KRA’s will work because new KRA will use current transport key and fail if keys will not match.

  • Old KRA with new CA will work because KRA will use current transport key and fail if keys will not match.

Implementation

TBD

Major configuration options and enablement

TBD

Cloning

Configuration updates for cloning are part of manual procedures:

Updates and Upgrades

No impact on updates and upgrades.

Tests

Only manual procedures can be used for testing and they are listed in the design section.

KRA Transport Key Rotation Procedures are provided on a separate wiki page.

Dependencies

No new package and library dependencies.

Packages

pki-core-TBD

External Impact

No impact on other development teams and components.

History

  • ORIGINAL DESIGN DATE: September 11, 2013

  • Included manual procedures: September 18, 2013

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