# **Enable key** ## **Goal** The objective of this feature is to suspend and resume the use of a key. It is achieved by introducing: - the enable and disable commands. - "isEnabled" status of a key. Note: we use term "disabled" to indicate that the "isEnabled == FALSE" ### Example When a key is disabled and we are trying to perform signing using the key, the following error is returned to the caller: ``` { "type": "PERMISSION_DENIED", "title": "Key is disabled", "details": "Key is disabled", "status": "FORBIDDEN", "message": "Key is disabled" } ``` ## Interworking with other features - This feature doesn't apply to keys in the Root partition. - Upon the generation of a key, the key is enabled. - When upgrading from the release that didn't have isEnabled key attribute, this attribute is set to isEnabled=TRUE. - The "isEnabled" and "Key-state" attributes are orthogonal to each other. Changing the one doesn't depend on the value of the other and doesn't affect it. - A disabled key can not be used in any cryptographic operation including operations that use only the public part of the key, such as "verify" and "encrypt". - It is impossible to derive a new key from a disabled key. - Rekey: -- It is possible to rekey a disabled key. The new key becomes enabled. -- The same applies to the disabled key scheduled for automatic rotation. - Backup/Restore: -- The "isEnabled" status is saved during the backup and restored when the backup file is used during DB restore. - Roles: -- To change the isEnabled status of a key, the user's role must contain DY_ENABLE operation in the permission applicable to the key's group. -- The DY_ENABLE operation is includedd in the default USER role. - Audit Log: -- The enable/disable events are reflected in the Audit Log as the DyEnable operation. ## **APIs** ### REST **Enable Request:** ``` POST /api/v1/keys/{keyId}/enable ``` **Response:** ```json { "id": "0x005d67beb52880667b", "uid": "0x005d67beb52880667b", . . . "isEnabled": true, . . . "activationDate": "2020-02-24T12:35:57Z" } ``` **Disable Request:** ``` POST /api/v1/keys/{keyId}/disable ``` **Response:** ```json { "id": "0x005d67beb52880667b", "uid": "0x005d67beb52880667b", . . . "isEnabled": false, . . . "activationDate": "2020-02-24T12:35:57Z" } ``` **Get keys Request:** The /keys/ API allows to specify the query parameter isEnabled=<true|false> It filters the list of the keys according to the required isEnabled status. Example: ``` GET /api/v1/keys?limit=10&skip=0&isEnabled=true ``` **Response:** ```json { "totalItems": 2, "limit": 10, "skip": 0, "items": [ { "id": "rest", "uid": "0x00bd2667bc8432e382", . . . "isEnabled": true, . . . }, { "id": "rest1", "uid": "0x00f2aac592ff47c4a0", . . . "isEnabled": true, . . . } ] } ``` ## **UCL** The UCL supports enable/disable command **Enable command:** ``` ucl enable -u bd2667bc8432e382 -p part1 ``` Output: ``` The key is successfully enabled ``` **Disable command:** ``` ucl disable -u bd2667bc8432e382 -p part1 ``` Output: ``` The key is successfully disabled ``` **Show command:** It's possible to see the isEnabled attribute using ucl show command: ``` ucl show -u bd2667bc8432e382 -p part1 ``` Output: ``` -------------- Private RSA key: UID=bd2667bc8432e382 . . . isEnabled = false . . . ```