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

[Krishna Yellepeddy <kyellepe@us.ibm.com>]

Hi Indra,

You are welcome and thanks for the questions/comments. Please see my responses below to your questions.

Thanks,
Krishna

"Fitzgerald, Indra" ---07/01/2010 02:25:33 PM---Hi Krishna, Thanks for putting together the proposal. I think it's very useful to be able to group m

From:	"Fitzgerald, Indra" <indra.fitzgerald@hp.com>
To:	Krishna Yellepeddy/Austin/IBM@IBMUS, "kmip@lists.oasis-open.org" <kmip@lists.oasis-open.org>
Date:	07/01/2010 02:25 PM
Subject:	RE: [kmip] Groups - Group as a managed object (KMIP-GroupProposal-06302010.pdf) uploaded

---

Hi Krishna,

Thanks for putting together the proposal. I think it's very useful to be able to group managed objects into groups. At this point, I have the following questions:

1. Will a group have its own UUID?   
   - Yes. 

2. Does the homogenous group only apply to symmetric keys or could you, for example, have a group of asymmetric keys? 
   - A group contains zero or more KMIP managed objects. So you could have a homogeneous group where all objects are of the same managed object type. You couldn't have a homogeneous group of asymmetric keys, but you could have a homogeneous group of private keys only or public keys only or a heterogeneous group consisting of both private and public keys.

3. What are the requirements for a homogeneous group? Can it consists of, for example, both AES and TDES keys? What about key size or key type restrictions? Can a group consists of both encryption and MAC keys?
   - The requirements for a homogeneous group are that all its members have the same object type and have a specified list of identical attributes. This criteria for homogeneity is specified when the homogeneous group is created.  For symmetric keys I think the minimum criteria for homogeneity is that the keys be of the same size and use the same cryptographic algorithm. This definition would make AES and TDES keys different, and so they would not be part of the same homogeneous group but could belong to the same heterogeneous group. The use case for such a homogeneous group of symmetric keys is an application/device that always requires a key with the same algorithm and size to be served to it to meet business security policies. E.g., always return an AES key of size 256 bits which the application then uses for encryption. If two keys of the same key size and type need to be considered different because their cryptographic usage differ, e.g, an encryption key versus a MAC key, then they can be members of the same  heterogeneous group, but not members of the same homogeneous group(also see response to question 5).  

4. What happens to a group member after a rekey or a destroy? I assume the new version of the key will not be automatically added to the group after a rekey.
   - The new version of the key is not automatically added to group. The client would have to make an explicit call to add it to the group. Once a group member is destroyed, it is no longer part of the group.

5. How will the Cryptographic Usage Mask attribute of group members affect the group object? The usage mask defines the usage of a managed object and may conflict with the cursor pattern set for the group.
   - The cursor pattern applies to homogeneous groups only. For example, if managed object A of a given key size and type is considered different from managed object B of the same key size and type because cryptographic usage is different, A and B should be grouped together in a heterogeneous group. The criteria for homogeneity is defined at the time the group is created (see answer 3)

6. Does it even make sense to apply the Activate operation to a group?
   - You are right that there are cases where the Activate operation does not make sense. e.g, for templates. However, there are other cases where Activate operation makes sense. For members in a heterogeneous group where activate does not make sense, the operation would be a no-op (please see page 6 of the group proposal document I posted to the TC website) 

7. This question is probably linked to the Access Control proposal. Assuming that several users have access to a group, who is able to add new members to a group? I assume the user who is able to add a managed object to a group must have access to the object and have the privilege to add the object to the group.
 - Yes. 




Thanks,
Indra 

-----Original Message-----
From: kyellepe@us.ibm.com [mailto:kyellepe@us.ibm.com] 
Sent: Wednesday, June 30, 2010 9:10 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] Groups - Group as a managed object (KMIP-GroupProposal-06302010.pdf) uploaded

 Proposal to add Group as a managed object to v 1.1 of the specification.

 -- Krishna Yellepeddy

The document named Group as a managed object
(KMIP-GroupProposal-06302010.pdf) has been submitted by Krishna Yellepeddy
to the OASIS Key Management Interoperability Protocol (KMIP) TC document
repository.

Document Description:
Proposal for Group as a new managed object in KMIP

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=38504

Download Document:  
http://www.oasis-open.org/committees/download.php/38504/KMIP-GroupProposal-06302010.pdf


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration

---------------------------------------------------------------------
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