RE: [kmip] KMIP-1.1 - Revocation Reason attribute: Modifiable by server?

["Featherstone, David" <David.Featherstone@safenet-inc.com>]

Answering my own question ...

The spec identifies six states {Pre-Active, Active, Deactivated, Destroyed, Compromised, 
Destroyed Compromised } [see 3.22], and ten transitions to/from those states:

  1.    --> Pre-Active
  2.  Pre-Active  --> Destroyed
  3.  Pre-Active  --> Compromised
  4.  Pre-Active  --> Active
  5.  Active  --> Compromised
  6.  Active  --> Deactivated
  7.  Deactivated     --> Destroyed
  8.  Deactivated     --> Compromised
  9.  Compromised --> Destroyed Compromised
10.  Destroyed        --> Destroyed Compromised

Four the above transitions may be initiated by a Revoke request:
  3.  Pre-Active --> Compromised                         // Revoke w/Reason equal Compromised
  5.  Active --> Compromised                                  // Revoke w/Reason equal Compromised 
  6.  Active  --> Deactivated                                     // Revoke w/Reason *not* equal Compromised
  8.  Deactivated --> Compromised                      // Revoke w/Reason equal Compromised
10.  Destroyed --> Destroyed Compromised  // Revoke w/Reason=Compromised

To allow for a Revoke initiated transition from Active to Deactivated [#6], and a subsequent 
Revoke initiated transition from Deactivated to Compromised [#8] requires the Managed 
Object's Revocation Reason attribute be "Modifiable by server".

Similar logic holds true for the transition sequence: #6, #7, #10; the Revoke operation is applied 
once for transition #6 and again for transition #10.

In other words, the Revocation Reason must be "Modifiable by server" to allow for possibly two 
applications of the Revoke operation:
  (a) First, to support the transition from Active to Deactivated, and
  (b) Again, to support the transition to Compromised [from Deactivated], or from Destroyed to
         Destroyed Compromised

Cheers,
... Dave

  


-----Original Message-----
From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Mr. David Featherstone
Sent: Monday, May 12, 2014 11:34 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] KMIP-1.1 - Revocation Reason attribute: Modifiable by server?

Section 3.31 Revocation Reason

The Revocation Reason attribute is one of three attributes closely associated with the Revoke request:
  1. Compromise Occurrence Date
  2. Compromise Date
  3. Revocation Reason

The Attribute Rules for these three attributes are identical, with the following exception:
  Modifiable by server: No  // Compromise Occurrence Date
  Modifiable by server: No  // Compromise Date
  Modifiable by Server: Yes // Revocation Reason

As it stands, the Revocation Reason attribute is not a Read-Only attribute. Does any justification exist for the above difference between the Revocation Reason attribute and the other two? 

Regards,
... 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.