OASIS Key Management Interoperability Protocol (KMIP) TC

 View Only

  • 1.  Groups - Group as a managed object (KMIP-GroupProposal-06302010.pdf) uploaded

    Posted 07-01-2010 04:10 
     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


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

    Posted 07-01-2010 19:25 
    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?

2. Does the homogenous group only apply to symmetric keys or could you, for example, have a group of asymmetric keys? 

3. What are the requirements for a homogenous 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?

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.

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.

6. Does it even make sense to apply the Activate operation to a group?

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.

Thanks,
Indra 


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


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

    Posted 07-07-2010 23:08 
    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
                                                
    
                                                    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 


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

    Posted 07-08-2010 20:37 
    Hi, Krishna, just one question for now...

It is not clear to me from the presentation how elements of the group would be "served out". This does not seem to derive obviously from any of the permitted KMIP operations you listed. Is the "serving" behavior intended to remain out of the standard, or added as another new operation, or am I just missing something obvious among the current set of permitted operations?

Thanks!
   - bob nixon, Emulex


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


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

    Posted 07-16-2010 19:48 
    Hi Bob,

    
Thanks for the question. There are two options for this:
    
One is to extend the get operation to indicate that this is a "get next member from group" request by adding  parameters to the get request payload specifically for groups.  Or we can add a new  iterator operation called  getNextMemberFromGroup.  Adding a new operation is preferable to overloading the existing get operation.  This  operation needs to handle concurrent  requests, and it should be part of the standard.

    
Regards,
    
Krishna Yellepeddy
    
IBM


    
---07/08/2010 03:38:40 PM---Hi, Krishna, just one question for now... It is not clear to me from the presentation how elements o

    


    


    
From:
    
<Bob.Nixon@Emulex.Com>
    



    
To:
    
Krishna Yellepeddy/Austin/IBM@IBMUS, <kmip@lists.oasis-open.org>
    



    
Date:
    
07/08/2010 03:38 PM
    



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

    




    
Hi, Krishna, just one question for now...

    
It is not clear to me from the presentation how elements of the group would be "served out". This does not seem to derive obviously from any of the permitted KMIP operations you listed. Is the "serving" behavior intended to remain out of the standard, or added as another new operation, or am I just missing something obvious among the current set of permitted operations?

    
Thanks!
    
   - bob nixon, Emulex

    

    
                                                
    
					
                                                    

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


Related Content