[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [kmip] Revoke operation: Ambiguity w.r.t. Compromise, Compromise Occurrence Date
Greetings Possibly two ambiguities exist in the KMIP 1.2 specification’s description of the Revoke attribute. The ambiguities arise from the text in Table 185: Revoke Request Payload, saying that the Compromise Occurrence Date “SHALL be specified if the Revocation Reason is ‘key compromise’”: a) Is a Compromise Occurrence Date permitted/optional when the Revocation Reason is not ‘Key Compromise’? b) Is a Compromise Occurrence Date not also required when the Revocation Reason is ‘CA Compromise’? Here is the current description: 4.20 Revoke This operation requests the server to revoke a Managed Cryptographic Object or an Opaque Object. The request SHALL NOT specify a Template object. The request contains a reason for the revocation (e.g., “key compromise”, “cessation of operation”, etc.). Special authentication and authorization SHOULD be enforced to perform this request (see [KMIP-UG]). Only the object owner or an authorized security officer SHOULD be allowed to issue this request. The operation has one of two effects. If the revocation reason is “key compromise”, then the object is placed into the “compromised” state, and the Compromise Date attribute is set to the current date and time. Otherwise, the object is placed into the “deactivated” state, and the Deactivation Date attribute is set to the current date and time. +-------------------------------------------------------------------------------------------------+ | R E Q U E S T P A Y L O A D | +---------------------------------+---------------------+-----------------------------------------+ | O b j e c t | R E Q U I R E D | D E S C R I P T I O N | +---------------------------------+---------------------+-----------------------------------------+ | Unique Identifier | No | Determines the object being revoked. If | | | | omitted, then the ID Placeholder value | | | | is used by the server as the Unique | | | | Identifier | +---------------------------------+---------------------+-----------------------------------------+ | Revocation Reason, see 3.31 | Yes | Specifies the reason for revocation. | | | | | +---------------------------------+---------------------+-----------------------------------------+ | Compromise Occurrence Date, see | No | SHALL be specified if the Revocation | | 3.29 | | Reason is 'key compromise'. | +-------------------------------------------------------------------------------------------------+ Table 185: Revoke Request Payload The ambiguity could be eliminated with the following alterations: 4.20 Revoke This operation requests the server to revoke a Managed Cryptographic Object or an Opaque Object. The request SHALL NOT specify a Template object. The request contains a reason for the revocation (e.g., “key compromise”, “cessation of operation”, etc.). Special authentication and authorization SHOULD be enforced to perform this request (see [KMIP-UG]). Only the object owner or an authorized security officer SHOULD be allowed to issue this request. The operation has one of two effects. If the revocation reason is “key compromise” or “CA compromise”, then the object is placed into the “compromised” state, and the Compromise Date attribute is set to the current date and time. Otherwise, the object is placed into the “deactivated” state, and the Deactivation Date attribute is set to the current date and time. +-------------------------------------------------------------------------------------------------+ | R E Q U E S T P A Y L O A D | +---------------------------------+---------------------+-----------------------------------------+ | O b j e c t | R E Q U I R E D | D E S C R I P T I O N | +---------------------------------+---------------------+-----------------------------------------+ | Unique Identifier | No | Determines the object being revoked. If | | | | omitted, then the ID Placeholder value | | | | is used by the server as the Unique | | | | Identifier | +---------------------------------+---------------------+-----------------------------------------+ | Revocation Reason, see 3.31 | Yes | Specifies the reason for revocation. | | | | | +---------------------------------+---------------------+-----------------------------------------+ | Compromise Occurrence Date, see | No | SHALL be specified if and only if the | | 3.29 | | Revocation Reason is 'key compromise' | | | | or 'CA compromise'. | +-------------------------------------------------------------------------------------------------+ Table 185: Revoke Request Payload Cheers, … Dave The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]