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

8.3.3 Key De-registration Function

NIST platform security: roots of trust, firmware and secure enclaves SP 800-57 Part 1 Rev. 5 against SP 800-57 Part 1 Rev. 4
All changes in this version
modified 8 Transition: A transition plan should be developed and followed so that the changeover part of 8.3

Title

Key De-registration Function

Control changed

Before · SP 800-57 Part 1 Rev. 4

Registered keying material may be associated with the identity of a key owner, owner information (e.g., email address), role, or authorization information. When the keying material is no longer needed, or the associated information becomes invalid, the keying material should be de-registered (i.e., all records of the keying material and its associations should be marked to indicate that the key is no longer in use) by the appropriate trusted third party. In general, this will be the trusted third party that registered the key (see Section 8.1.6 ). Keying material should be de-registered when the information associated with an entity is modified. For example, if an entity's email address is associated with a public key, and the entity's address changes, the keying material should be de-registered to indicate that the associated information has become invalid. Unlike the case of a key compromise, the entity could safely re-register the public key after modifying the entity's information through the user registration process (see Section 8.1.1 ). When a registered cryptographic key is compromised, that key and any associated keying material shall be de-registered. When the compromised key is the private part of a public- private key pair, the public key shall also be revoked (see Section 8.3.5 ). If the registration information associated with a public-private key pair is changed, but the private key has not been compromised, the public key should be revoked with an appropriate reason code (see Section 8.3.5 ).

44 For example, an archived symmetric key could be recovered to decrypt a single message or file, or could be used to decrypt multiple messages or files, all of which were encrypted using that key during its originator-usage period.

After · SP 800-57 Part 1 Rev. 5

Registered keying material may be associated with the identity of a key owner, owner information (e.g., email address), role, or authorization information. When the keying material is no longer needed, or the associated information becomes invalid, the keying material should be de-registered (i.e., all records of the keying material and its associations should be marked to indicate that the key is no longer in use) by the appropriate trusted third party. In general, this will be the trusted third party that registered the key (see Section 8.1.6 ). Keying material should be de-registered when the information associated with an entity is modified. For example, if an entity'sentity’s email address is associated with a public key, and the entity'sentity’s address changes, the keying material should be de-registered to indicate that the associated information has become invalid. Unlike the case of a key compromise, if the cryptoperiod of the key has not expired, the entity could safely re-register the public key after modifying the entity'sentity’s information through the userentity registration process (see Section 8.1.1 ). When a registered cryptographic key is compromised, that key and any associated keying material shall be de-registered. When the compromised key is the private partkey of a public- private key pair, the public key shall also be revoked (see Section 8.3.5 ). The de-registered key shall not be re-registered. If the registration information associated with a public-private key pair is changed, but the private key has not been compromised, the public key should be revoked with an appropriate reason code (see Section 8.3.5 ).

44 For; example,in anthis archivedcase, symmetricthe key could be recovered to decrypt a single message or file, or couldmay be used to decrypt multiple messages or files, all of which were encrypted usingre-registered thatif keythe duringcryptoperiod itshas originator-usagenot periodexpired.