---
# System prepended metadata

title: '**Enable key**'

---

# **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
    .
    .
    .
```



