Re: [kmip] Re: Groups - KMIP AC in v1.1 (AC-kmipf2f-mar2010.pdf)

[Marcus Streets <Marcus.Streets@thales-esecurity.com>]

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 <Role> to allow keys to wrap/be wrapped by any key that is
owned by an identity that belongs to that role.


-- 
Marcus Streets
Security Standards Officer

THALES Information Systems Security
nCipher product line

------------------------------------------------------
T:  +44 (0) 1223 723613 (Direct)
F:  +44 (0) 1223 723601
E:  Marcus.Streets@thales-esecurity.com
W:  www.thalesgroup.com/iss

OpenPGP digital signature