Enabling PKA key management extensions

The rules for cryptographic key usage defined in the ICSF segment of CSFKEYS and XCSFKEY profiles (described in Restricting asymmetric keys from being used in secure import and export operations, Restricting asymmetric keys from being used in handshake operations, and Placing restrictions on exporting symmetric keys) will not be in effect unless PKA Key Management Extensions are enabled. PKA Key Management Extensions cannot be enabled unless Key Store Policy is active for both the CKDS and PKDS.

Enabling any one of the following controls will activate Key Store Policy for a CKDS:
Enabling any one of the following controls will activate Key Store Policy for a PKDS:

The following table shows the controls for enabling PKA Key Management Extensions in either warning or fail mode. To enable one of the controls, create the appropriate profile in the XFACILIT class.

Table 1. Key Store Policy controls: The PKA Key Management Extensions controls
The existence of this resource profile in the XFACILIT class: Does this:
CSF.PKAEXTNS.ENABLE.WARNONLY Enables PKA Key Management Extensions in warning mode. The ICSF segment of CSFKEYS or XCSFKEY profiles will be checked to:
  • determine if a symmetric key can be exported, and, if so, which asymmetric keys can be used in the operation to re-encrypt the symmetric key.
  • determine if an asymmetric key can be used in secure export and import operations, or in handshake operations.
However, because this is warning mode, ICSF will allow the operation to continue even if the ICSF segment indicates that the operation is not allowed.
CSF.PKAEXTNS.ENABLE Enables PKA Key Management Extensions in fail mode. The ICSF segment of CSFKEYS or XCSFKEY profiles will be checked to:
  • determine if a symmetric key can be exported, and, if so, which asymmetric keys can be used in the operation to re-encrypt the symmetric key.
  • determine if an asymmetric key can be used in secure export and import operations, or in handshake operations.
If the ICSF segment indicates that the operation is not allowed, the service returns with an error.
For example, you've already used the ICSF segment of profiles in the CSFKEYS or XCSFKEY class to define various restrictions on how keys covered by the profiles can be used. You're not certain that all applications at your installation are using the keys according to the new restrictions, and do not want to disrupt current work patterns at your installation. For this reason, you decide to allow a warning period during which you can identify noncompliant applications without causing application failure. To do this, you would:
  1. Enable PKA Key Management Extensions in warning mode:
    RDEFINE XFACILIT CSF.PKAEXTNS.ENABLE.WARNONLY
SETROPTS RACLIST(XFACILIT) REFRESH
  2. Because you have enabled PKA Key Management Extensions in warning mode, ICSF will allow applications to use keys in ways that violate ICSF segment specifications. However, ICSF will generate SMF type 82 subtype 27 records for any violation. Using the information in these records, you can modify your installation's applications as needed.
  3. When you are ready to move to a stricter implementation of the policy, you enable the PKA Key Management Extensions control for fail mode, and disable the one for warning mode.
    RDEFINE XFACILIT CSF.PKAEXTNS.ENABLE
RDELETE XFACILIT CSF.PKAEXTNS.ENABLE.WARNONLY
SETROPTS RACLIST(XFACILIT) REFRESH
    If you accidentally enable PKA Key Management Extensions in both warning and fail mode, the control for fail mode will take precedence.
As described in Identifying key certificates for symmetric key export, you can use the ICSF segment's SYMEXPORTCERTS field to provide a list of certificate labels in a trusted certificate repository (either a PKCS #11 token or a SAF key ring). This enables you to specify that symmetric keys covered by a CSFKEYS or XCSFKEY profile can be exported only by RSA public keys that are bound to identities in the listed certificates. If using the SYMEXPORTCERTS field to provide a list of certificate labels in a trusted certificate repository, you will need to identify that trusted certificate repository to ICSF. You do this using the APPLDATA field of the CSF.PKAEXTNS.ENABLE profile. If the trusted key repository is a PKCS #11 token, it should be identified in the APPLDATA field in the format *TOKEN*/PKCS-token-name. If the trusted key repository is a SAF key ring, it should be identified in the APPLDATA field in the format userID/key-ring-name. For example, if the trusted key repository was a SAF key ring named TRUSTED.KEY.EXPORTERS created by BOBADMIN, you would enter:
RDEFINE XFACILIT CSF.PKAEXTNS.ENABLE APPLDATA(BOBADMIN/TRUSTD.KEY.EXPORTERS)
SETROPTS RACLIST(XFACILIT) REFRESH
If an APPLDATA field is not provided on the CSF.PKAEXTNS.ENABLE, the default certificate repository is a PKCS #11 token named CSF.TRUSTED.KEYRING.
Parent topic: Controlling how cryptographic keys can be used