DRM Transport Key Rotation

From Dogtag
Jump to: navigation, search

DRM Transport Key Rotation

Overview

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

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

  • The requirement is to rotate DRM transport keys periodically.
  • DRMs 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.
  • DRM transport key rotation has to be provided as graceful transition from old to new transport key without loss of client services. DRM has to be able to utilize simultaneously at least two transport keys.
  • Graceful transport key rotation has to be provided for DRMs using HSMs.

Associated Bugs and Tickets

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

  • #729 - CA to include transport certificate when submitting archival request to DRM
  • #730 - DRM to detect presence of transport certificate attribute in submitted archival request and validate transport certificate against DRM's transport key list
  • #731 - DRM to provide handling for alternative transport key based on detected and validated transport certificate arriving as a part of extended archival request
  • #732 - requesting new transport certificate
  • #733 - obtaining issued certificate
  • #734 - importing of new transport certificate and keys to DRM's NSS DB
  • #735 - updating of DRM configuration to reflect existence of new transport certificate and keys
  • #736 - propagation of new transport certificate and keys to DRM clones
  • #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.
  • #738 - propagation of new transport certificate to all CAs communicating with updated DRM (including CAs' clones)

Use Cases

To rotate DRM 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 DRM's configuration to provide support for second transport key. Once DRM supports two transport keys, administrators can start transition CAs to new transport key. DRM 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 DRM transport key rotation, requires the following main sub features:

  1. ability to distinguish DRM transport keys used in archival process in new DRM environment supporting dual transport keys
  2. new process of DRM transport certificate generation
  3. new process of DRM 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 DRM Transport Keys

There were few methods considered for adding ability to distinguish DRM transport keys used in archival process in new DRM 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-DRM connector.

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

  • 729 - CA to include transport certificate when submitting archival request to DRM
  • 730 - DRM to detect presence of transport certificate attribute in submitted archival request and validate transport certificate against DRM's transport key list
  • 731 - DRM to provide handling for alternative transport key based on detected and validated transport certificate arriving as a part of extended archival request

Adding Process of DRM Transport Certificate Generation

Due to time restrictions, process of DRM transport certificate generation will be provided as a set of manual procedures:

Adding Process of DRM Transport Certificate Propagation

Due to time restrictions, process of DRM transport certificate propagation will be provided as a set of manual procedures:

Backward Compatibility

  • Old CAs with new DRM's will work because new DRM will use current transport key and fail if keys will not match.
  • Old DRM with new CA will work because DRM 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.
DRM 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