User's Guide: Key Metadata Policy

1.0 Introduction

This article describes the Key Metadata Policy feature in Fortanix-Data-Security-Manager (DSM), which allows users to set key metadata policies for Fortanix DSM groups.

Fortanix DSM supports key metadata policies that can be configured at the group level to enforce restrictions on the metadata associated with security objects. Here “metadata” refers to elements of security objects that are not governed by cryptographic policies, such as custom metadata, descriptions, expiry dates, and so on. The policy can specify that certain metadata “must be present”, “must not be present”, or “must be present and have a certain value”.

2.0 Create a Group-Level Key Metadata Policy

A group-level Key metadata policy allows you to configure specific restrictions on the “metadata” associated with security objects, such as key descriptions, activation and deactivation dates, custom attributes, and so on.

Perform the following steps to add a Key metadata policy at the group level:

1. Navigate to the detailed view of a group, and under the INFO tab, click ADD POLICY in the Key metadata policy section.

   

2. On the Key metadata policy page, configure the following metadata that you want to allow for this group:

   1. Key description: Set the rule as either Optional or Required by selecting the corresponding radio button.

   2. Activation date: Set the rule as either Optional or Required by selecting the appropriate radio button.

      1. To enforce a specific activation window for the key, select the Required radio button. Select the optional check box User must specify an activation date within [X] and [Y] (seconds/minutes/hours/days) of the security object's creation time to define the allowed activation range for the key.

         For example, the user can specify an activation date between 20 hours and 10 days from the time the security object is created.

         

         NOTE

         [X] defines the lower limit, and [Y] defines the upper limit of the time range within which the security object must be activated.

   3. Deactivation date: Set the Deactivation date rule to Optional, Required, or Forbid by selecting the corresponding radio button.

      • Optionally, select the check box  User must specify a deactivation date within [X] and [Y] (seconds/minutes/hours/days) of the security object's creation time to configure when the security object should be deactivated.

        For example, the user can specify a deactivation date between 10 hours and 1 day after the security object’s creation time.

        

        NOTE

        [X] sets the lower limit, and [Y] sets the upper limit of the time range within which the security object will be deactivated.

      • If you select the Forbid radio button, deactivating the key is not allowed.

   4. Custom Attribute: These are user-defined attributes that can be added to a security object's metadata. You can configure each attribute as either required or forbidden. Enter the attribute name (for example, Country) and specify whether the attribute should be required or forbidden by selecting the option Required or Forbid.

      • If you select Required, you can optionally configure the following settings:

        • The value cannot be blank (empty or only containing whitespace): If selected, the user must enter a non-blank value, which means empty or whitespace-only entries are not allowed.

        • Restrict value to one of the following values: If selected, you must provide a list of pre-defined values that the user must choose from.

          • Allow the value to be empty: Enter comma-separated values. For example, India, Australia, China, the US, and so on.

          • If you want to allow a blank value, select the Allow empty values check box. This permits an empty string as the attribute value when creating a security object.

            NOTE

            If The value cannot be blank check box is selected, it overrides the Allow empty values option and disallows empty values.

          • To configure additional custom attributes, click ADD ATTRIBUTE.

      • If you select Forbid, the attribute specified in the Attribute name field cannot be added.

3. Click SAVE POLICY to apply the changes.

3.0 Overriding Key Metadata Policy for Selected Key Types

By default, all types of keys are selected for Key metadata policy: AES, DES3, HMAC, OPAQUE, RSA, DSA, DES, EC, SECRET, LMS, XMSS, MLKEM, MLKEMBETA, MLDSA, MLDSABETA, CERTIFICATE, BIP32, ECKCDSA, KCDSA, SEED, ARIA, BLS.

Perform the following steps to override the default Key metadata policy for selected key types:

1. Click OVERRIDE FOR KEY TYPES. 

   

2. Select the key types from the drop down menu that should be overridden by the default Key metadata policy.

3. To configure the metadata of security objects such as key description, activation date, deactivation date, and custom attribute applicable to the selected key types, refer to Section 2.0: Create a Group-Level Key Metadata Policy.

3.1 Handling Existing Non-Compliant Keys

• All new keys will be allowed or denied based on the Key metadata policy rules.

• Any existing keys that do not comply with the policy will remain in the group. However, these keys will be marked separately as policy-violating keys. For more information on the conditions applicable to policy violating keys, refer to the User's Guide: Group Cryptographic Policy.

  

  When a key metadata policy is created at the group level, three options are provided to handle non-compliant keys.  These options are described below:

  1. Accept: Accept non-compliant objects even though they violate the current policy. If this option is selected, you may continue to use existing non-compliant keys, but you may not generate or import new non-compliant objects.

  2. Forbid to use: Forbid any use of non-compliant objects. If this option is selected, you are not allowed to use non-compliant keys for any operation.

  3. Limit usage: Restrict non-compliant objects so that they may only be used for “process operations” (DECRYPT, UNWRAPKEY, VERIFY, and MACVERIFY) on existing objects that violate these restrictions “Protect operations” (ENCRYPT, SIGN, WRAPKEY, DERIVEKEY, and MACGENERATE) are forbidden.

4.0 Delete A Group-Level Key Metadata Policy

Perform the following steps to edit or delete a group-level key metadata policy:

1. Go to the detailed view of a group, and in the INFO tab, click EDIT POLICY for Key metadata policy.

2. Scroll to the end of the screen, click DELETE POLICY to delete the Key metadata policy.