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

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

After looking at this further there are two issues with the description of the Revoke operation within the KMIP Spec  (Section 4.20). 

1.  The first being that the section neglected to include references to the 'CA compromise' revocation reason which would be handled in the same way as key compromise.  This was the proposed update that I had made last week in the email below.

2.  The second issue is with the 'guidance' that is provided for how the Compromise Occurrence Date is set.  As Tim H noted Section 3.29  where the Compromise Occurrence Date attribute is described there is guidance for what to do it you don't know the date when the compromise occurred.  The recommendation provided says to set the date to the initial date of the object, but it would also be reasonable to say just don't set the value at all. 

So we have alternatives for how to address this second issue and make the KMIP more clear and consistent.

Option 1:  Change the text in the Description column  for Compromise Occurrence Date in Table 185 from a 'SHALL' to a 'SHOULD' -- This would allow leaving this field empty even in the cases where the revocation reasons is one of the two compromise options.

Option 2:  Remove the text in the Description column  for Compromise Occurrence Date in Table 185 completely.  The Compromise Occurrence Date field is already marked as optional so this allow the value to be included or not.

Option 3:  Make no change for this second issue (we are recommending that we add the missing CA compromise revocation reasons to address issue #1) keeping things as is leaving implementations to interpret this on their own.

I've posted a document to the OASIS site which shows how the different options would change the text in section 4.20.  Please see:  https://www.oasis-open.org/committees/document.php?document_id=56751&wg_abbrev=kmip

Note irrespective of any change we make in this area this doesn't impose specific behavior on a KMIP Server.  See section 3.41 Compromised Objects of the Usage Guide for more information (pasted below for ease):

3.41 Compromised Objects
A Cryptographic Object or Opaque Object may be compromised for a variety of reasons. In KMIP, a client indicates to the server that a Cryptographic Object is to be considered compromised by performing a Revoke Operation with a Revocation Reason of Key Compromise or CA Compromise. The KMIP client must provide a Compromise Occurrence Date (if the Revocation Reason is Key Compromise) and if it is unable to estimate when the compromise occurred then it should provide a Compromise Occurrence Date equal to the Initial Date. 

The KMIP specification [KMIP-Spec] places no requirements on a KMIP server to perform any action on any Managed Object that references (i.e., via Link attributes) a Cryptographic Object or Opaque Object that a client has performed a Revoke operation with a Revocation Reason of Key Compromise or CA Compromise.  However, KMIP users should be aware that there may be security relevant implications in continuing to use a Managed Cryptographic Object in the following circumstances:
*	For a compromised Private Key, the linked Public Key and/or Certificate; 
*	For a compromised Public Key, the linked Private Key and/or Certificate; 
*	For a compromised Derived Key, the linked derived key and/or Secret Data Object
In these circumstances, it is the responsibility of the client to either check the state of the referenced Managed Object or to also perform a Revoke operation on the referenced Managed Object.

Judy

-----Original Message-----
From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Thursday, October 15, 2015 4:19 PM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] Revoke operation: Ambiguity w.r.t. Compromise, Compromise Occurrence Date

We might also want to draw attention to this statement in section 3.29
Compromise Occurrence Date "If it is not possible to estimate when the
compromise occurred, then this value SHOULD be set to the Initial Date
for the object."

We also need to know that the value might not be provided - i.e. add "if
such a value is specified in the request" or something along those lines.

Tim.

On 16/10/2015 5:56 AM, Furlong, Judith wrote:
>
> 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,
> andthe 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.
>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php