RE: [kmip] Revoke operation: Ambiguity w.r.t. Compromise, Compromise Occurrence Date

["Furlong, Judith" <judith.furlong@emc.com>]

David

 

I re-read the Revocation related sections of KMIP Spec and KMIP Usage Guide over again.  Generally I believe the KMIP Spec is clear on when you set the  Compromise Occurrence Date vs Deactivation Date – this is covered in section 4.20 Revoke and in 3.22 State of the KMIP (1.2) Spec.  Compromise is distinct state from Deactivation so it is reasonable that they have separate dates to represent the point when an object transitions to that state.  When you Revoke an object due to compromise (Key Compromise or CA Compromise) you set the Compromise Occurrence Date and if you Revoke and object of any other reason code (Affiliation Changed, Cessation of Operation) you set the Deactivation Date.

 

That said there are a few issues with the text of section 4.20 Revoke of the KMIP (1.2) Spec.  First we neglected to mention the CA Compromise reason code as the other reason code that would transition an object into the compromise state.    The other issue with the section is that we give guidance on setting the Compromise Date attribute to the current date and time and seems to leave out the step of setting the Compromise Occurrence Date to the value.   The client has specified the Compromise Occurrence Date in the request and that could be for a time earlier than the current date/time (the point of compromise can be earlier than the point when the compromise is reported).  So the server should take the value from the request and use that to set the Compromise Occurrence Date. 

 

So here is what I believe needs to change in the Revoke section of the KMIP Spec.

 

 

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 and the Compromise Occurrence Date is set to value provided in the Revoke request. Otherwise, the object is placed into the “deactivated” state, and the Deactivation Date attribute is set to the current date and time.

Request Payload
Object	REQUIRED	Description
Unique Identifier, see 3.1	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 3.29	No	SHALL be specified if the Revocation Reason is 'key compromise' or ‘CA compromise’.

Table 185: Revoke Request Payload

Response Payload
Object	REQUIRED	Description
Unique Identifier, see 3.1	Yes	The Unique Identifier of the object.

Table 186: Revoke Response Payload

Judy

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Featherstone, David
Sent: Tuesday, September 08, 2015 11:30 AM
To: kmip@lists.oasis-open.org
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.