A number of ICSF callable services enable an application to create, write to, or delete a key label. By default, the user needs only READ authority to read from, create, write to, or delete a label. In some cases, however, you might want to require a higher level of authority for modifying a label than is required to merely read a label. By enabling the Granular Key Label Access control, you increase the level of access authority required to create, write to, or delete a label, while still requiring only READ authority for cryptographic functions. This way, you can give a user permission to access a key for encryption or decryption operations, while preventing that same user from changing or deleting the key record.

The following table outlines the increased access authority required when the Granular Key Label Access control is enabled.

You can enable the Granular Key Label Access control in warning or fail mode. In warning mode, the user's access authority will be checked, but only READ authority will be required. However, if a user does not have UPDATE authority when creating a label, or CONTROL authority when writing to or deleting a label, a warning will be issued and the access will be logged. Warning mode allows you to identify any users who will need to be granted increased access authority prior to moving to a stricter implementation of the policy. The stricter implementation of the policy is called fail mode. In fail mode, users who lack the increased access authority required will not be able to modify key labels. The operation will be unsuccessful, and a return code of 8 (reason code 16004) will be returned to the calling application.

It is recommended that you activate Key Store Policy for both the CKDS and the PKDS before enabling the Granular Key Label Access control. If Key Store Policy is not activated and the Granular Key Label Access control is enabled, the increased access authority checks will work only when the application passes a callable service a key label. However, if the application were to pass the callable service a key token instead of a key label, then no authorization checking will be performed. When a token is passed, ICSF will, in order to initiate a SAF authorization check, rely on an active Key Store Policy for the appropriate key store.

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

• CSF.CKDS.TOKEN.CHECK.LABEL.WARN
• CSF.CKDS.TOKEN.CHECK.LABEL.FAIL
• CSF.CKDS.TOKEN.NODUPLICATES

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

• CSF.PKDS.TOKEN.CHECK.LABEL.WARN
• CSF.PKDS.TOKEN.CHECK.LABEL.FAIL
• CSF.PKDS.TOKEN.NODUPLICATES

The following table shows the controls for enabling Granular Key Label Access in warning or fail mode. To enable one of the controls, create the appropriate profile in the XFACILIT class.

For example, you want to require UPDATE authority to create a label, and CONTROL authority to write to or delete a label. You're not certain all the users currently modifying key labels will have the necessary access authority, 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 which users will need to be granted increased authority. To do this, you would:

1. Enable the Granular Key Label Access control in warning mode.

   RDEFINE XFACILIT CSF.CSFKEYS.AUTHORITY.LEVELS.WARN 
   SETROPTS RACLIST(XFACILIT) REFRESH

2. Because you have enabled the control in warning mode, a failing access check will still allow a user to modify the key record (as long as the user has READ authority), but will issue a warning and log the access. Using this information, you can update the appropriate profiles in the CSFKEYS class to grant increased access authority to the appropriate users. For example, if user RITA needs to be able to generate RSA key tokens (by way of the CSNDKRC and CSNDPKG callable services), she will need CONTROL access to the label:

   PERMIT RITA.RSA.TEST.* CLASS(CSFKEYS) ID(RITA) ACCESS(CONTROL)

3. When you are ready to move to a stricter implementation of the policy, you would enable the control for fail mode and disable the one for warning mode.

   RDEFINE XFACILIT CSF.CKDS.TOKEN.CHECK.LABEL.FAIL
   RDELETE XFACILIT CSF.CKDS.TOKEN.CHECK.LABEL.WARN
   SETROPTS RACLIST(XFACILIT) REFRESH

If you accidentally enable the Granular Key Label Access controls for both warning and fail mode, the control for fail mode will take precedence.