BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

7.4 Deactivated State

NIST platform security: roots of trust, firmware and secure enclaves SP 800-57 Part 1 Rev. 4
All changes in this version
first version loaded 7 Key States and Transitions part of 7

Title

Deactivated State

Control

Keys in the deactivated state shall not be used to apply cryptographic protection, but in some cases, may be used to process cryptographically protected information. If the key has been revoked (i.e., for reasons other than a compromise), then the key may continue to be used for

39 In the case of public ephemeral key-agreement keys, the cryptoperiod ends at the same time as that of the corresponding private ephemeral key-agreement key (which transitioned to the destroyed state after use (see transition 5), However, there is no actual requirement to destroy the public key immediately, so it is listed here as transitioning to the deactivated state, rather than the destroyed state. However, transitioning directly to the destroyed state would also be acceptable. processing. Note that keys retrieved from an archive can be considered to be in the deactivated state unless compromised.

• Public signature verification keys may be used to verify the digital signatures generated before the end of the corresponding private key's originator-usage period (e.g., before the notAfter date in the last certificate for the public key).

• Symmetric authentication keys, symmetric data encryption keys and symmetric key- wrapping keys may be used to process cryptographically protected information until the end of the recipient-usage period is reached, provided that the protection was applied during the key's originator-usage period.

• Public authentication keys may be used to authenticate processes performed before the end of the corresponding private key's originator-usage period (e.g., before the notAfter date in the last certificate for the public key).

• Private key-transport keys may be used to decrypt keys that were encrypted using the corresponding public key before the end of the public key's originator-usage period (e.g., before the notAfter date in the last certificate for the public key).

• Symmetric key-agreement keys may be used to determine the agreed-upon key, assuming that sufficient information is available.

• Private/public static key-agreement keys may be used to regenerate agreed-upon keys that were created before the end of the key pair's cryptoperiod (e.g., before the notAfter date in the last certificate for the public key, assuming that sufficient information is available for the key-agreement scheme used).

• Public ephemeral key-agreement keys may be used to regenerate agreed-upon keys (assuming that sufficient information is available for the key-agreement scheme used).

• Public authorization keys shall not be used. Keys in the deactivated state may transition to either the compromised or destroyed state at some point in time. Transition 13: A key shall transition from the deactivated state to the compromised state when the integrity of a key or the confidentiality of a key requiring confidentiality protection becomes suspect. In this case, the key or key pair shall be revoked. The date, time and reason for the transition shall be recorded. If the key is known by multiple entities, a revocation notice shall be generated. Transition 14: A key in the deactivated state should transition to the destroyed state as soon as it is no longer needed. The date, time and reason for the transition shall be recorded. Note that keys retrieved from an archive may be in the deactivated state.