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.

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

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

• Ticket 732 - requesting new KRA transport certificate

• Ticket 733 - retrieving new KRA transport 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

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

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

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