#129 RFE: Add support for multiple DRM transport keys
Closed: Fixed None Opened 10 years ago by nkinder.

https://bugzilla.redhat.com/show_bug.cgi?id=804677 (Red Hat Certificate System)

We should add the ability to have multiple DRM transport keys.  This would help
to solve the use case where one wants to periodically rotate the transport
keys.  During this key rotation, there would be an overlap period where both
the old and new transport key could be used to encrypt traffic.

Here are requirements for DRM transport keys rotation provided by customers:
1. The requirement is to rotate DRM transport keys periodically.
2. 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.
3. 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 at least two transport keys
4. Graceful transport key rotation has to be provided for DRMs using HSMs.

Current limitation in using single DRM to support multiple CAs is that all CAs have to have a common root CA.

Main tasks are:
1. to provide ability to distinguish DRM transport keys used in archival process in new DRM environment supporting multiple transport keys
2. to provide new process of DRM transport certificate generation
3. to provide new process of DRM transport certificate propagation

All above main tasks will be divided in appropriate sub-tasks.

Base on discussion with Nathan (nkinder) scope of this feature has been significantly reduced by only providing ability for DRM to support two transport keys: current key and new key. DRM will provide ability to automatically distinguish between its transport keys during archival process.

All other processes will be covered by manual procedures. This includes:

  • ticket #732 - requesting new transport certificate
  • ticket #733 - obtaining issued certificate
  • ticket #734 - importing of new transport certificate and keys to DRM's NSS DB
  • ticket #735 - updating of DRM configuration to reflect existence of new transport certificate and keys
  • ticket #736 - propagation of new transport certificate and keys to DRM 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 DRM (including CAs' clones)

Above list of procedures may/will grow.

Please note that all manual procedures are requiring subsystem restarts which are resulting in service interruptions.

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

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

Tickets related to phase 2: #750 and #753.

Metadata Update from @nkinder:
- Issue assigned to awnuk
- Issue set to the milestone: 10.1 - 09/13 (September)

5 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/701

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Login to comment on this ticket.

Metadata