vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Active 1 Keys move immediately into the Active state on the activation date. This transition marks the beginning of a key's cryptoperiod. Keys with no activation date become active immediately and remain active until they expire or are destroyed. 
 Suspended 2 A key moves into the Suspended state when it is [disabled for encrypt and decrypt operations](https://cloud.ibm.com/docs/key-protect?topic=key-protect-disable-keys). In this state, the key is unable to cryptographically protect data and can only be moved to the Active or Destroyed states. 
 Deactivated 3 A key moves into the Deactivated state within one hour past its expiration date, if one is assigned. In this state, the only actions that can be performed on the key are unwrap, rewrap, rotate, and delete. 
 Destroyed 5 Keys are moved into the Destroyed state after being deleted. Keys in this state can be recovered for 30 days but become eligible to be purged after 90 days. They can also be purged four hours after being moved into the Destroyed state, if necessary. After being moved into a Destroyed state, metadata that is associated with a key, such as its name and a record of when it last transitioned, is kept in the Key Protect database until the key is purged. For more information, check out [About deleting and purging keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-purge-keys). 







 Key states and service actions 

Key states affect whether an action that is performed on a key succeeds or fails. For example, if a key is in the Active state, you can't restore the key, because the key wasn't previously deleted.

The following table describes how key states affect service actions. The column headers represent the key states, and the row headers represent the actions that you can perform on a key. The check mark icon (!
After 90 days, the key is purged and permanently removed from your instance. The data that is associated with the key becomes inaccessible. Before you delete a key, make sure that the key is not actively protecting any resources. For more information, see [Restoring keys](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-restore-keys).
* What happens if I lose the signature key or the master key parts?

If your signature key or master key part is lost, you are not able to initialize your service instance, and your service instance is not accessible. Depending on how to store your keys, back up you key files on your workstation or back up your smart cards.
* How is routine maintenance performed on Hyper Protect Crypto Services?

If one available zone that contains your provisioned service instance goes down, Hyper Protect Crypto Services has automatic in-region data failover in place if you have 2 or 3 crypto units provisioned. IBM also performs cross-region backup for your key resources. Your data is automatically backed up in another supported region daily. If a regional disaster that affects all available zones occurs, you need to open a support ticket so that IBM can restore your data in another supported [IBM Cloud regions](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-regions) from the backup. And then, you need to manually load your master key to your new service instance. For more information, see [Restoring your data from another region](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-restore-data).
* How do I get support for Hyper Protect Crypto Services?

If you have technical questions about Hyper Protect Crypto Services, post your question on [Stack Overflow](https://stackoverflow.com/questions/tagged/hyper-protect-crypto) and tag your question with ibm-cloud and hyper-protect-crypto.
"lastUpdateDate": "2020-06-19T16:08:59Z",
"updatedBy": "user id ...<redacted>...",
"dualAuthDelete": { "enabled": true
}
}
]

 this should fail (the key has a dual authorization policy)
$ ibmcloud kp key delete $KEY_ID_OR_ALIAS

Deleting key: d887bfe8-5166-4dad-af32-7e3055ca1873, from instance: a192d603-0b8d-452f-aac3-f9e1f95e7411...
FAILED
kp.Error:
correlation_id='fe0db627-1726-4827-a9d2-c21d728e1c92',
msg='Conflict: 1 prior authorization(s) are required for deletion: Key could not be deleted.
Please see "reasons" for more details.',
reasons='[AUTHORIZATIONS_NOT_MET: Number of authorizations required to delete is not met -
FOR_MORE_INFO_REFER: https://cloud.ibm.com/apidocs/key-protect]'





 Required parameters 



* KEY_ID_OR_ALIAS

The v4 UUID or alias of the key that you want to query. To retrieve a list of your available keys, run the [kp keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-protect-cli-referencekp-keys) command.
* -e, --enable

Once you enable the dual-auth-delete policy you cannot disable it. You cannot delete a key without two (dual) authorizations. The process must be completed within 7 days, otherwise the dual authorization policy is automatically canceled, which means the key can be deleted by anyone that has authorization (two authorizations are not needed).
"lastUpdateDate": "2020-06-19T16:08:59Z",
"updatedBy": "user id ...<redacted>...",
"dualAuthDelete": { "enabled": true
}
}
]

 this should fail (the key has a dual authorization policy)
$ ibmcloud kp key delete $KEY_ID_OR_ALIAS

Deleting key: d887bfe8-5166-4dad-af32-7e3055ca1873, from instance: a192d603-0b8d-452f-aac3-f9e1f95e7411...
FAILED
kp.Error:
correlation_id='fe0db627-1726-4827-a9d2-c21d728e1c92',
msg='Conflict: 1 prior authorization(s) are required for deletion: Key could not be deleted.
Please see "reasons" for more details.',
reasons='[AUTHORIZATIONS_NOT_MET: Number of authorizations required to delete is not met -
FOR_MORE_INFO_REFER: https://cloud.ibm.com/apidocs/key-protect]'





 Required parameters 



* KEY_ID_OR_ALIAS

The v4 UUID or alias of the key that you want to query. To retrieve a list of your available keys, run the [kp keys](https://cloud.ibm.com/docs/cli?topic=cli-key-protect-cli-referencekp-keys) command.
* -e, --enable

Once you enable the dual-auth-delete policy you cannot disable it. You cannot delete a key without two (dual) authorizations. The process must be completed within 7 days, otherwise the dual authorization policy is automatically canceled, which means the key can be deleted by anyone that has authorization (two authorizations are not needed).
Then, a different user provides a second authorization by using the [GUI](https://cloud.ibm.com/login/) or [API](https://cloud.ibm.com/apidocs/key-protect) to delete the key.

ibmcloud kp key policy-update dual-auth-delete KEY_ID_OR_ALIAS
-i, --instance-id INSTANCE_ID
-e, --enable
[--key-ring KEY_RING_ID]
[-o, --output OUTPUT]



 Example 

This example enables the dual authorization delete policy.

 create a root key
$ KEY_ID=$(ibmcloud kp key create my-root-key --output json | jq -r '.["id"]')

$ echo $KEY_ID

d887bfe8-5166-4dad-af32-7e3055ca1873

 show key details
$ ibmcloud kp key show $KEY_ID --output json

{
"id": "d887bfe8-5166-4dad-af32-7e3055ca1873",
"name": "my-root-key",
"type": "application/vnd.ibm.kms.key+json",
"algorithmType": "AES",
"createdBy": "user id ...<redacted>...",
"creationDate": "2020-06-19T16:07:50Z",
"lastUpdateDate": "2020-06-19T16:07:50Z",
"keyVersion": {
"id": "d887bfe8-5166-4dad-af32-7e3055ca1873",
"creationDate": "2020-06-19T16:07:50Z"
},
"extractable": false,
"state": 1,
Key states and service actions 

Key states affect whether an action that is performed on a key succeeds or fails. For example, if a key is in the Active state, you can't restore the key, because the key wasn't previously deleted.

The following table describes how key states affect service actions. The column headers represent the key states, and the row headers represent the actions that you can perform on a key. The check mark icon (![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/0bc8db34a3d90b2a5103c9c71b08a96de9525bbc/icons/checkmark-icon.svg) indicates that the action on a key is expected to succeed based on the key state.



Table 2. Describes how key states affect service actions.

 Action Active Suspended (disabled keys) Deactivated (expired keys) Destroyed (deleted keys) 

 Get key ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/0bc8db34a3d90b2a5103c9c71b08a96de9525bbc/icons/checkmark-icon.svg) ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/0bc8db34a3d90b2a5103c9c71b08a96de9525bbc/icons/checkmark-icon.svg) ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/0bc8db34a3d90b2a5103c9c71b08a96de9525bbc/icons/checkmark-icon.svg) !
When you [authorize use](https://cloud.ibm.com/docs/account?topic=account-serviceauthserviceauth) of your root key, you grant permission for IBM to use the key to encrypt your resource. Authorization is done at the key management service level through IAM, when you authorize service between your service (for example, Cloud Block Storage) and the key management service.

You can remove any authorization between services in your account when you have the Administrator role on the target service (in this case, the key management service). If you remove an access policy that was created by the source service for its dependent services, the source service is unable to complete the workflow or access the target service.

Because the root keys are under your control, you don't need to contact IBM to remove authorization.

Do not remove IAM authorization between Cloud Block Storage and the KMS instance, and then delete a block storage volume, snapshot, or image resource. Such action causes the root key in the KMS instance to remain registered with the deleted resource. You must delete all BYOK volumes, snapshots, or images before you remove the IAM authorization.

To make your data inaccessible, but retain it on the IBM Cloud:



1. [Remove IAM authorization](https://cloud.ibm.com/docs/account?topic=account-serviceauthremove-auth) from the source Cloud Block Storage service to your target key management service instance.
2. [Stop all virtual server instances](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-virtual-server-instancesstop-and-start) with attached encrypted volumes that are secured by that root key.



You can also [disable a root key](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-managingbyok-disable-root-keys), which suspends the key and temporarily revokes access to it.







 Viewing events in the IBM Cloud Activity Tracker 

Use the Activity Tracker to verify user-initiated activities that change the state of your keys in the key management service.
During this 7-day period, the key remains in the [Active state](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-key-states) and all key operations are allowed on the key. If no action is taken by the second user and the 7-day period expires, you must [restart the dual authorization process](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-dual-auth-keysset-key-deletion-api) to delete the key.

To delete a key and the contents, make a DELETE call to the service endpoint by following instructions in [Deleting keys with the API](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-keysdelete-keys-api).





 Removing an existing authorization 

If you need to cancel an authorization for a key before the 7-day waiting period expires, you can remove the existing authorization by making a POST call to the following endpoint.

https://api.<region>.hs-crypto.cloud.ibm.com:<port>/api/v2/keys/<key_ID>/actions/unsetKeyForDeletion



1. [Retrieve your authentication credentials to work with keys in the service](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-up-kms-api).

To remove an authorization to delete a key, you must be assigned a Manager or Writer access policy for the instance or key. To learn how IAM roles map to Hyper Protect Crypto Services actions, check out [Service access roles](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-accessservice-access-roles).
2. Copy the ID of the key that you want to unset or deauthorize for deletion.
3. Remove an existing authorization to delete the key.

curl -X POST
If a second authorization does not occur within 7 days, the key returns to its default status



There are two ways to enable the dual-auth-delete policy:



* Set the policy for a single key using kp key policy-update dual-auth-delete
* Set the policy for the instance using kp instance policy-update dual-auth-delete; all keys created after the instance policy is enabled inherit the instance policy setting



The [kp key cancel-delete](https://cloud.ibm.com/docs/key-protect-cli-pluginkp-key-cancel-delete) command cancels, or removes, a prior authorization.

ibmcloud kp key schedule-delete KEY_ID_OR_ALIAS
-i, --instance-id INSTANCE_ID
[--key-ring KEY_RING_ID]



 Example 

This is an example of scheduleing a key to be deleted.

 schedule this key to be deleted
$ ibmcloud kp key schedule-delete $KEY_ID_OR_ALIAS

Scheduling key for deletion...
OK

 this key has a dual-auth-delete policy
$ ibmcloud kp key policies $KEY_ID_OR_ALIAS --output json

[
{
"createdBy": "user id ...<redacted>...",
"creationDate": "2020-06-22T19:13:00Z",
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb146:a192d603-0b8d-452f-aac3-f9e1f95e7411:policy:2427dbde-6cff-41eb-8b5a-ff26b038cafc",
"lastUpdateDate": "2020-06-22T21:36:16Z",
"updatedBy": "user id ...<redacted>..."
* If you delete just the Cloud Object Storage authorization (as seen in Table 2), then not only is the deployment that is shown as the creator affected, but any deployments that also use the same key are also affected. Those deployments can encounter temporary backup failures until the policy is automatically re-created. There should be no lasting effects, except for missing backups.
* If you delete just Cloud Databases delegator authorization, which is created by you (as seen in Table 1), nothing immediately breaks because the second authorization is still in place. However, if the Cloud Object Storage authorization is ever removed, it cannot be re-created, and can lead to multiple deployments that use the same key losing the ability to back up.
* If you delete both the Cloud Object Storage authorization AND the Cloud Databases delegator authorization, all deployments that use the same key will immediately not have the ability to back up and the correct authorizations will not be able to be re-created, effectively destroying the backups for all deployments that use that key.



Use caution if you reuse keys.
[After you enable dual authorization for an instance or key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-dual-auth), you can provide the first authorization to delete a key by making a POST call to the following endpoint.

https://<region>.kms.cloud.ibm.com/api/v2/keys/<keyID_or_alias>/actions/setKeyForDeletion



1. [Retrieve your authentication credentials to work with keys in the service](https://cloud.ibm.com/docs/key-protect?topic=key-protect-set-up-api).

To set a key for deletion, you must be assigned a Manager or Writer access policy for the instance or key. To learn how IAM roles map to Key Protect service actions, check out [Service access roles](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-accessmanage-access-roles).
2. Copy the ID of the key that you want to set or authorize for deletion.
3. Provide the first authorization to delete the key.

$ curl -X POST "https://<region>.kms.cloud.ibm.com/api/v2/keys/<keyID_or_alias>/actions/setKeyForDeletion" -H "accept: application/vnd.ibm.kms.key_action+json" -H "authorization: Bearer <IAM_token>" -H "bluemix-instance: <instance_ID>" -H "content-type: application/vnd.ibm.kms.key_action+json"

Replace the variables in the example request according to the following table.





Table 1. Describes the variables that are needed to set a key for deletion.

 Variable Description 

 region Required. The region abbreviation, such as us-south or eu-gb, that represents the geographic area where your Key Protectinstance resides.
correlation_id='cbc0d18b-a816-45ab-af6a-b8e18dc3e628',
msg='Conflict: 1 prior authorization(s) are required for deletion: Key could not be deleted. Please see "reasons" for more details.',
reasons='[AUTHORIZATIONS_NOT_MET: Number of authorizations required to delete is not met -
FOR_MORE_INFO_REFER: https://cloud.ibm.com/apidocs/key-protect]'







 Required parameters 

-d, --disable
or
-e, --enable
: Disable or enable the dual authorization policy. One option is required.







 kp key cancel-delete 

A key with a dual-auth-delete policy requires authorization from two administrative users to delete the key.

This command (kp key cancel-delete) cancels, or removes, a prior authorization.

The [kp key schedule-delete](https://cloud.ibm.com/docs/key-protect?topic=key-protect-cli-reference-five-twokp-key-schedule-delete) command is the "authorization" to delete the key.

Follow this process to delete a key with a dual-auth-delete policy.



1. Create a key and enable the dual-auth-delete policy
2. User 1 schedules (authorizes) a key deletion with the kp key schedule-delete command
3. User 2 schedules (authorizes) a key deletion
4. The key is deleted after the second schedule-delete is performed, which is supported in the user interface, API, and CLI
5. If a second authorization does not occur within 7 days, the key returns to its default status



There are two ways to enable the dual-auth-delete policy:



* Set the policy for a single key using kp key policy-update dual-auth-delete
Your IBM Cloud access token. Include the full contents of the IAM token, including the Bearer value, in the curl request. <br> <br>For more information, see [Retrieving an access token](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-access-token). 
 instance_ID Required. The unique identifier that is assigned to your Key Protect service instance. <br> <br>For more information, see [Retrieving an instance ID](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-instance-ID). 



A successful request returns an HTTP 204 No Content response, which indicates that your key is no longer authorized for deletion. If you need to restart the dual authorization process, you can issue another authorization to [set the key for deletion](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-dual-auth-keysdelete-dual-auth-keys-set-key-deletion-api).
Suspended 2 A key moves into the Suspended state when it is [disabled for encrypt and decrypt operations](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-disable-keys). In this state, the key is unable to cryptographically protect data and can be moved only to the Active or Destroyed states. 
 Deactivated 3 A key moves into the Deactivated state on the expiration date, if one is assigned. In this state, the key is unable to cryptographically protect data and can be moved only to the Destroyed state. 
 Destroyed 5 Deleted keys are in the Destroyed state. Keys in this state are not recoverable. Metadata that is associated with a key, such as the key's transition history and name, is kept in the Hyper Protect Crypto Services database. 







 Key states and service actions 

Key states affect whether an action that is performed on a key succeeds or fails. For example, if a key is in the Active state, you can't restore the key because the key wasn't previously deleted.

The following table shows how Hyper Protect Crypto Services handles service actions based on the state of a key. The column headers represent the key states, and the row headers represent the actions that you can perform on a key. The Checkmark icon ![checkmark icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/checkmark-icon.svg) indicates that the action on a key is expected to succeed based on the key state.



Table 2. Describes how key states affect service actions.

 Action Pre-active Active Suspended Deactivated Destroyed 

 Get key. ![checkmark icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/checkmark-icon.svg) !
The rotated key retains its original name and ID in the list of KMS instances.





 User actions that impact root key states and resource status 

Root keys move to various states as a result of the actions that you take, and different root key states impact resources differently. The following table describes what happens to a resource when you disable, enable, delete, and restore a root key.

Disable root key

Enable root key

Delete root key



Table 1. Disable root key

 Resource type Resource status Result 

 Root key state = suspended<br><br>[1] 
 All -- The key can't be used to encrypt new resources or unwrap (decrypt) passphrases that are protecting existing resources until you enable the key. For more information, see [Disabling root keys](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-managingbyok-disable-root-keys). 
 Custom image unusable Images cannot be used for creating boot volumes during instance provisioning. 
 Boot volume available Boot volumes remain encrypted with the suspended key. If you stop the instance that uses that boot volume, it can't restart. 
 Data volume available Data volumes remain encrypted, attached, and available until you stop the instance. Stand-alone data volumes that are encrypted by the suspended key can't be attached to an instance. 
 Snapshot unusable Snapshot cannot be used to restore a volume. 
 File shares stable Data on the file share is accessible but you can't create a file Share with that key. 
 Instance available Instance workloads continue to run with an available status in the CLI and API, and with a running status in the UI. If you stop instances, they can't restart. 



For more information about root key states from a KMS perspective, see the following topics.



* [Key Protect - Key states and transitions](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-stateskey-transitions)
User 2 schedules (authorizes) a key deletion
4. The key is deleted after the second schedule-delete is performed, which is supported in the user interface, API, and CLI
5. If a second authorization does not occur within 7 days, the key returns to its default status



There are two ways to enable the dual-auth-delete policy:



* Set the policy for a single key using kp key policy-update dual-auth-delete
* Set the policy for the instance using kp instance policy-update dual-auth-delete; all keys created after the instance policy is enabled inherit the instance policy setting



ibmcloud kp key cancel-delete KEY_ID
-i, --instance-id INSTANCE_ID



 Example 

This is an example of canceling a previously scheduled key delete.

 this key has a dual-auth-delete policy
$ ibmcloud kp key policies $KEY_ID --output json

[
{
"createdBy": "user id ...<redacted>...",
"creationDate": "2020-06-22T19:13:00Z",
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb146:a192d603-0b8d-452f-aac3-f9e1f95e7411:policy:2427dbde-6cff-41eb-8b5a-ff26b038cafc",
"lastUpdateDate": "2020-06-22T21:29:10Z",
"updatedBy": "user id ...<redacted>...",
"dualAuthDelete": {
"enabled": true
}
}
]

 cancel a previously scheduled key delete
$ ibmcloud kp key cancel-delete $KEY_ID

Cancelling key for deletion...