OASIS Key Management Interoperability Protocol (KMIP) TC

 View Only
Expand all | Collapse all

RE: [kmip] Groups - Group as a managed object(KMIP-GroupProposal-02182011.ppt) uploaded

  • 1.  RE: [kmip] Groups - Group as a managed object(KMIP-GroupProposal-02182011.ppt) uploaded

    Posted 05-16-2011 17:55
    Krishna,

    I have a few questions regarding the Group proposal.

    1. Can the functionality described in the group proposal be accomplished using existing KMIP means?
    - Can [Locate "fresh=true"] be done using a Create operation instead?
    - Can a server-supplied attribute "y-default" be used to designate "default" object in a group?

    2. Can an object registered by a client considered "fresh"? It would be according to the current definition of "fresh". On the other hand it seems that a "fresh" object is one that has not been seen by any client.

    3. "Replicated" attribute seems to come out of nowhere. I think the attribute itself and the terminology around it (e.g. replication server) would need some definition and broader discussion.

    4. There doesn't seem to be an explicit group deletion, and if a group contains many objects, particularly of heterogeneous nature, it would not be straightforward for a client to delete a group.

    5. Is it possible to add/modify/delete "fresh" attribute of an object?

    6. It seems that [Locate "fresh=true"] operation would always have to be batched with a Get request. Otherwise another client can preempt the first one and issue a Get for the object, whose UUID has been returned by the response to the initial [Locate "fresh=true"]. The picture would get even more complicated if the answer to the previous question (5) is "Yes".

    Thank you for considering my feedback.

    Regards,
    Denis

    - - - - - - - - - - - - - - - -
    Denis Pochuev
    Principal Software Engineer
    SafeNet, Inc.
    Denis.Pochuev@safenet-inc.com
    +1 (650) 261-2429



    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.





  • 2.  RE: [kmip] Groups - Group as a managed object (KMIP-GroupProposal-02182011.ppt) uploaded

    Posted 05-18-2011 18:21
    Denis, Thanks for reviewing the proposal.  Responses below to your questions. Regards, Krishna Lead Architect, Tivoli Key LifeCycle Manager From: "Pochuev,Denis" <Denis.Pochuev@safenet-inc.com> To: Krishna Yellepeddy/Austin/IBM@IBMUS Cc: "'kmip@lists.oasis-open.org'" <kmip@lists.oasis-open.org> Date: 05/16/2011 12:55 PM Subject: RE: [kmip] Groups - Group as a managed object (KMIP-GroupProposal-02182011.ppt)   uploaded Krishna, I have a few questions regarding the Group proposal. 1. Can the functionality described in the group proposal be accomplished using existing KMIP means? - Can [Locate "fresh=true"] be done using a Create operation instead? - Can a server-supplied attribute "y-default" be used to designate "default" object in a group? Answer: A client would need to know details about algorithms, key lengths etc or point to a template with this information when it makes a Create call. With a group set up this is simplified - client specifies [Locate "fresh=true" with object group]. Regarding use of 'y-default', since it is a server side custom attribute each server could interpret it differently. How the server keeps track of the default object in a group is outside the scope of the specification. Object Group member is not being used to keep track of the default object in a group. It is used by the client to specify whether it wants a fresh object or a default object. 2. Can an object registered by a client considered "fresh"? It would be according to the current definition of "fresh". On the other hand it seems that a "fresh" object is one that has not been seen by any client. Answer: Yes, an object registered by a client can be considered "fresh".  Fresh is tied to whether a client did a 'Get' to obtain the object after it has been created or registered. 3. "Replicated" attribute seems to come out of nowhere. I think the attribute itself and the terminology around it (e.g. replication server) would need some definition and broader discussion. Answer:  I agree. I have not added "Replicated" attribute to the specification. 4. There doesn't seem to be an explicit group deletion, and if a group contains many objects, particularly of heterogeneous nature, it would not be straightforward for a client to delete a group. Answer: An object can be removed from a group by deleting the object group attribute, as long as server policy permits it. A client would need to delete each individual member of a group. Until we have Group as a first class object post KMIP 1.1, we won't have a single operation to delete an entire group. 5. Is it possible to add/modify/delete "fresh" attribute of an object? Answer: It can be set initially by a client or the server. Subsequently, it is modifiable only by the server. 6. It seems that [Locate "fresh=true"] operation would always have to be batched with a Get request. Otherwise another client can preempt the first one and issue a Get for the object, whose UUID has been returned by the response to the initial [Locate "fresh=true"]. The picture would get even more complicated if the answer to the previous question (5) is "Yes". Answer: I agree, but this is not an issue unique to the Groups proposal.  Any other Locate call with attributes where the attributes can be changed between the Locate and the next operation has the same issue.  Even batching does not solve the issue as there is noting in KMIP which requires a batch to be executed as a single atomic transaction. Thank you for considering my feedback. Regards, Denis - - - - - - - - - - - - - - - - Denis Pochuev Principal Software Engineer SafeNet, Inc. Denis.Pochuev@safenet-inc.com +1 (650) 261-2429 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.