[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] KMIP-1.1 - Revocation Reason attribute: Modifiable by server?
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]