8.3.5 Key Revocation Function
All changes in this version
Title
Key Revocation Function
Control changed
Before · SP 800-57 Part 1 Rev. 4
It is sometimes necessary to remove keying material from use prior to the end of its normal cryptoperiod for reasons that include key compromise, removal of an entity from an organization, etc. This process is known as key revocation and is used to explicitly revoke a symmetric key or the public key of a key pair, although the private key corresponding to the public key is also revoked. Key revocation may be accomplished using a notification indicating that the continued use of the keying material is no longer recommended. The notification could be provided by actively sending the notification to all entities that might be using the revoked keying material, or by allowing the entities to request the status of the keying material (i.e., a “push” or a “pull” of the status information). The notification should include a complete identification of the keying material (excluding the key itself), the date and time of revocation and the reason for revocation, when appropriate (e.g., a key compromise). Based on the revocation information provided, other entities could then make a determination of how they will treat information protected by the revoked keying material. For example, if a public signature-verification key is revoked because an entity left an organization, it may be appropriate to honor all signatures created prior to the revocation date (i.e., to continue to verify those signatures and accept them as valid if the verification is successful). If a signing private key is compromised, resulting in the revocation of the corresponding public key, an assessment needs to be made as to whether or not information signed prior to the revocation notice would be considered as valid. As another example, a symmetric key that is used to generate MACs may be revoked so that it will not be used to generate MACs on new information. However, the key may be retained so that archived documents can be verified. The details for key revocation should reflect the lifecycle for each particular key. If a key is used in a pair-wise situation (e.g., two entities communicating using the same encryption key), the entity revoking the key shall inform the other entity of the revocation. If the key has been registered with an infrastructure, the entity revoking the key cannot always directly inform the other entities that may rely upon that key. Instead, the entity revoking the key shall inform the infrastructure that the key needs to be revoked (e.g., using a certificate revocation request). The infrastructure shall respond by de-registering the key material (see Section 8.3.3 ).
45 A simple deletion of the keying material might not completely obliterate the information. For example, erasing the information might require overwriting that information multiple times with other non-related information, such as random bits, or all zero or one bits. Keys stored in memory for a long time can become “burned in.” This can be mitigated by splitting the key into components that are frequently updated (see [DiCrescenzo] ). In a PKI, key revocation is commonly achieved by including the certificate in a list of revoked certificates (i.e., a CRL). If the PKI uses online status mechanisms (e.g., the Online Certificate Status Protocol [RFC 2560] ), revocation is achieved by informing the appropriate certificate status server(s). For example, when a private key is compromised, the corresponding public- key certificate shall be revoked as soon as possible. Certificate revocation because of a key compromise indicates that the binding between the owner and the key is no longer to be trusted; relying parties should not accept the certificate without seriously considering the risks and consulting the organization's policy about this situation. Other revocation reasons indicate that, even though the original binding may still be valid and the key was not compromised, the use of the public key in the certificate should be terminated; again, the relying party should consult his organization's policy on this issue. In a symmetric-key system, key revocation could, in theory, be achieved by simply deleting the key from the server’s storage. Key revocation for symmetric keys is more commonly achieved by adding the key to a blacklist or compromised key list; this helps satisfy auditing and management requirements.
After · SP 800-57 Part 1 Rev. 5
ItKey revocation is sometimesused necessaryin tocases removewhere keying1) materialthe fromauthorized use of a key needs to be terminated prior to the end of itsthe normalestablished cryptoperiod of that key, or 2) a key whose usage period has expired has been compromised. A key may be revoked for administrative reasons that(e.g., includethe key’s owner has left the organization, or a device containing the key compromisehas been removed from service), removalor ofit may be revoked on an entityemergency frombasis if there is reason to believe that it may have been disclosed to or otherwise accessed by an organizationunauthorized entity. In either case, etca cryptographic key should be revoked as soon as feasible after the need for revocation has been determined.
103 ThisA processsimple isdeletion knownof the keying material might not completely obliterate the information. For example, erasing the information might require overwriting that information multiple times with other unrelated information, such as random bits or all zero or one bits. Keys stored in memory for a long time can become “burned in.” This can be mitigated by splitting the key revocationinto andcomponents isthat usedare frequently updated (see [DiCrescenzo] ).] Entities that have been, are, or would be using the key (e.g., relying parties) need to explicitlybe revokenotified that the key has been revoked.
• When a (secret) symmetric key oris therevoked, publicall entities sharing the key ofneed to be notified (e.g., using a Compromised Key List (CKL)).
• In the case of asymmetric key pairpairs, althoughthe revocation refers to the private key. However, when public key certificates are used, the certificate containing the public key corresponding to the publicprivate key is also revoked., Keyand revocationrelying mayparties beare accomplishednotified using a, notificationfor indicatingexample, thatCertificate theRevocation continuedLists use(CRLs) ofor the keying materialOnline isCertificate noStatus longerProtocol recommended(OCSP). The notification could be provided by actively sending thea notification to all entities that might be using the revoked keying material,key or by allowing the entities to request the status of the keyingkey’s materialstatus (i.e., a “push” or a “pull” of the status information). The notification should include a complete identification of the keying materialkey (excluding the key itself), the date and time of revocation, and the reason for revocation, when appropriate (e.g., a key compromise). Based on the revocation information provided, other entities could then make a determination ofdetermine how they will treat information protected by the revoked keying materialkey. For example, if a public signature-verification key is revoked because an entity left an organization, it may be appropriate to honor all signatures created prior to the revocation date (i.e., to continue to verify those signatures and accept them as valid if the verification is successful). If a signing private key is compromised, resulting in the revocation of the corresponding public key, an assessment needs to be made as to whether or not information signed prior to the date in the revocation notice would be considered as valid. As another example, a symmetric key that is used to generate MACs may be revoked so that it will not be used to generate MACs on new information. However, the key may be retained so that archived documents can be verified. The details for key revocation should reflect the lifecycle for each particular key. If a key is used in a pair-wisepairwise situation (e.g., two entities communicating using the same symmetric encryption key), the entity revoking the key shall inform the other entity of the revocation. If the key has been registered with an infrastructure, the entity revoking the key cannot always directly inform the other entities that may rely upon that key. Instead, the entity revoking the key shall inform the infrastructure that the key needs to be revoked (e.g., using a certificate revocation request). The infrastructure shall respond by revoking and de-registering the key material (see Section 8.3.3 ).
45A simple deletion of the keying material might not completely obliterate the information. For example, erasing the information might require overwriting that information multiple times with other non-related information, such as random bits, or all zero or one bits. Keys stored in memory for a long time can become “burned in.” This can be mitigated by splitting the key into components that are frequently updated (see [DiCrescenzo] ). In a PKI, key revocation is commonly achieved by including the certificate in a list of revoked certificates (i.e., in a CRL). If the PKI uses online status mechanisms (e.g., the Online Certificate Status Protocol [RFC 2560] 104 ), revocation is achieved by informing the appropriate certificate status server(s). For example, when a private key is compromised, the corresponding public- keypublic-key certificate shall be revoked as soon as possible. Certificate revocation because of a key compromise indicates that the binding between the owner and the key iscan no longer to be trusted; relying parties should not accept the certificate without seriously considering the risks and consulting the organization'sorganization’s policy about this situation. Other revocation reasons indicate that, even though the original binding may still be valid and the key was not compromised, the use of
104 FRC 2560: X.509 Internet Public Key Infrastructure, Online Certificate Status Protocol, OCSP . the public key in the certificate should be terminated; again, the relying party should consult histhe organization'sorganization’s policy on this issue. In a symmetric-key system, key revocation could, in theory, be achieved by simply deleting the key from the server’s storage. Key revocation for symmetric keys is more commonly achieved by adding the key to a blacklist or compromised key list; this helps satisfy auditing and management requirements.