OASIS Key Management Interoperability Protocol (KMIP) TC

Marko,


Thanks for putting together the Access Control proposal.  Looks good.  Couple of comments:


On page 10 - last row of the table: We should put Certify, Re-certify and Validate in a separate row /category from Query, Cancel and Poll.  This is because Certify, Re-certify and Validate are operations

performed on a managed object, whereas  the other 3 operations are for interrogating server capabilities or refer to outstanding asynchronous operations.  Calling out the distinctions between these  operations will help avoid confusion in operational and access control policy definitions.  Thanks.



Subject: Groups - KMIP AC in v1.1 (AC-kmipf2f-mar2010.pdf) uploaded


From: mvu@zurich.ibm.com 
To: kmip@lists.oasis-open.org 
Date: 4 Mar 2010 19:26:55 -0000 


The document named KMIP AC in v1.1 (AC-kmipf2f-mar2010.pdf) has been

submitted by Dr. Marko Vukolic to the OASIS Key Management Interoperability

Protocol (KMIP) TC document repository.


Document Description:

Proposal draft related to KMIP Access Control (v1.1 item). To be discussed

on KMIP f2f.


View Document Details:

http://www.oasis-open.org/committees/document.php?document_id=36692


Download Document:  

http://www.oasis-open.org/committees/download.php/36692/AC-kmipf2f-mar2010.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




Regards,

Krishna

Lead Architect - Tivoli Key Lifecycle Manager |  Master Inventor

Marko

First I would like to echo Krishna's sentiment, thanks for putting this
together, it looks good. A comment and a few suggested extensions.

Change State
-------------

I think that Activate and Revoke are different for Add/Modify/Delete
object and should have their own Object permission - Change State


Extension for role permissions
-----------------------------
I think it might be useful if role permissions could take a template
name - if the template is specified then that role may only create a key
using the specified template.

We may the want to split create key and create key pair, as the latter
would need a pair of template, one for the private key and one for the
public key.

To enable a role to create keys with different template they would need
multiple permissions, on for each template.

Obviously we need to be able to permit unrestricted creates, I can see
two ways of doing this. Either make template name optional - and
interpret an entry without a template name as allowing any template
Or invent a special names "Any" that permits any defined template and
"None" that allows creation of keys without specifying a template.

I prefer the latter.

Obviously the Admin role would have to be given [Register "None"] by
default or you could never register any templates.

IF we do this then we can permit referencing a Template in Template/Attr
structure to all - rather than requiring the role to have
read_attributes on the template.

I am actually more concerned with users being allowed to override the
attributes defined in a template. I would prefer that more facilities to
force users to stick to the defined templates - rather than putting any
roadblocks in the way of clients using them.


Read Attribute / Modify_Attribute
---------------------------------

Is there any mileage in allowing the acl to specify a list of attributes
that can be read / modified?

Again we can use either and empty list or "Any" to allow access to al
attributes. Once again I would prefer the latter option.

Export
------

Do we want to restrict which keys can be used to wrap another key - for
example by adding a list of UUIDs to either export of wrap permissions.

The list on export would specify the keys that are permitted to wrap
this key. The list on export would specify the keys that this key could
be used to wrap.

Again we can use either and empty list or "Any" to allow wrapping of/by
any key. Once again I would prefer the latter option.

Two final extensions - but these might be getting too rococo.

We might want to allow "Owner" to allow keys to wrap/be wrapped by any
key that is owned by the same Identity.

And perhaps 

Hi Marcus,

thanks for your comments! Please look below for the responses and please
let me know your position on particular questions.

Thanks,
Marko

Marcus Streets