A Key Store Policy defines rules for how encrypted key tokens stored in a CKDS or PKDS can be accessed and used. A Key Store Policy is collectively defined by a number of separate controls that each specify a particular rule. Most of the Key Store Policy controls work in conjunction with profiles in the CSFKEYS class, and enable you to:

• Specify how ICSF should respond when a key token is passed to a callable service instead of a key label (which is needed to perform a SAF authorization check).
• Determine if applications should be prevented from creating a new key record (with a new key label) for a token that is already stored in the CKDS or PKDS (in a key record with a different key label).
• Specify if READ access authority is sufficient to create, write to, or delete a key label, or if a higher level of access authority should be required for these actions.
• Specify if READ access authority to an AES or DES key is sufficient to export the key (move it from encryption under a master key to encryption under an RSA key), or if UPDATE authority should be required for this action.
• Place restrictions on how keys can be used. You can:
  • restrict a particular AES or DES key from being exported, or allow it to be exported only by certain RSA keys (or only by RSA keys bound to identities in certain key certificates).
  • restrict certain RSA keys from being used in secure export and import operations, or from being used in handshake operations.

Each Key Store Policy control is a resource in the XFACILIT class, and can be enabled by creating a profile for the resource using the RDEFINE command. Similarly, you can disable a control by deleting its profile using the RDELETE command.

Certain controls, when enabled, will activate Key Store Policy for either the CKDS or PKDS. When Key Store Policy is activated, ICSF will identify the key label(s) associated with each key token in the key store. This information is needed, for example, in order to carry out SAF authorization checks against RACF profiles (which are based on key labels) when a key token is passed to a callable service, or to ensure an application doesn't store a duplicate token (a token that is already stored, but associated with a different key label) in the key store. In addition to the controls that activate Key Store Policy, other controls that do not themselves activate Key Store Policy may still require, or to a lesser degree rely upon, an active Key Store Policy and its key token/label associations. The following table outlines the Key Store Policy controls that are available. This table also highlights the controls that activate Key Store Policy for a CKDS or PKDS, as well as the dependencies the other controls have on Key Store Policy being active. Be aware that Key Store Policy is activated separately for a CKDS and a PKDS.

For more information on the:

• Key Token Authorization Checking controls, refer to Enabling access authority checking for key tokens
• Default Key Label Checking controls, refer to Determining access to tokens not stored in the CKDS or PKDS
• Duplicate Key Token Checking controls, refer to Enabling duplicate key label checking
• Granular Key Label Access controls, refer to Increasing the level of authority needed to modify key labels
• Symmetric Key Label Export controls, refer to Increasing the level of authority required to export symmetric keys
• PKA Key Management Extension control, refer to Controlling how cryptographic keys can be used