Sharing Keys with Older Clusters

Transfer keys differ in length depending on the OKM version used to create them. Some keys may not be compatible with certain versions of OKM.

Compatibility Restrictions for Transfer Partners

OKM_3.1+ KMAs generate key transfer keys that are a different length than those generated by KMAs running a previous OKM release. In addition, OKM 3.3 KMAs that have a Thales nShield Solo module generate key transfer keys that are longer than those that do not have a Thales nShield Solo module. Such changes introduce a compatibility concern with previous OKM releases.

The OKM 3.3 GUI supports key transfer keys of any of these lengths. Thus, it can be used to configure transfer partners while connected to KMAs running either the OKM 3.3 release or a previous OKM release. It cannot, however, configure a pre-OKM 3.1 KMA Transfer Partner using the longer key length.

  • You must use the OKM 3.1 or later GUI to configure Transfer Partners on OKM clusters where OKM 3.1 or later KMAs reside.
  • You cannot configure Transfer Partners for key sharing between an OKM cluster where OKM 3.1 or later KMAs reside and an OKM cluster where only OKM 2.5.3 (or lower) or OKM 3.0.2 (or lower) KMAs reside.

Transferring Keys in Mixed Clusters

If you add an OKM 3.1+ KMA to a cluster with OKM 2.x or 3.0.2 KMAs:

  • Existing KMA transfer partner activities would remain unchanged and the transfer partners exchanges with older (earlier than OKM 3.1) clusters would not be affected.
  • When sending a new transfer key, if the new key transfer key is generated on a KMA (earlier than OKM 3.1), then the new key would be accepted in pre-3.1 clusters. If the new transfer key is generated on the OKM 3.1 or later KMA, then it would be rejected by any pre-3.1 cluster.

Once a transfer partnership is established between two OKM clusters, customers can perform export key and import key operations on any KMA in the OKM cluster, even after a KMA in these OKM clusters is upgraded to the OKM 3.3 release. However, the compatibility issues described above are exposed when the customer attempts to create or modify a Transfer Partner. Also, customers must take these issues into consideration when a new key transfer key must be generated, and choose the correct KMA when generating this key.Key Transfer Keys can be used any KMA in an OKM cluster. Thus, when an OKM 3.1 or later KMA is added to a down-level OKM cluster, it uses any (smaller) Key Transfer Keys that have already been generated there. If the customer uses the OKM 3.1 or later KMA to create a new Key Transfer Key, then this KMA generates a Key Transfer Key with a longer length.

Mitigation when Transferring Keys in Mixed Clusters

If an OKM 3.1 or later cluster needs to exchange keys with a down-level OKM 3.x cluster:

  • If possible, upgrade the other KMAs in this cluster to OKM 3.1 or later.

If an OKM 3.1 or later cluster needs to exchange keys with an OKM 2.x cluster:

  • If possible, add an OKM 3.1 or later KMA to the OKM 2.x cluster to create Transfer Partners using longer Key Transfer Keys.