RE: [kmip] Client Registration

["Pochuev,Denis" <Denis.Pochuev@safenet-inc.com>]

John raises a good point regarding the need to have owner attribute as a part of the protocol. I would argue that object ownership is fundamental to key management and therefore KMIP. First, the spec already states that object revocation is essentially based on the object ownership. Second, what is the point of defining representations of KMIP clients (Entities) if they cannot have different levels of access to the crypto objects? I'm not suggesting that we have to define Entities and therefore we need object ownership, it is the other way around - we need a model for clients with differing access rights, therefore we need Entities and ownership. Finally, several key management servers have a notion of ownership, should these be aligned?

I believe it is possible to define a framework for representing KMIP clients as Entities and object ownership based on the Entity. It appears that there are alternative models for representing ownership (see Bob L's e-mail earlier). I think that without some ownership model the I in KMIP will suffer.

Regarding the specific questions, here is my take on it:

> If we were to introduce an owner attribute, could it be optional? 
Yes, owner attribute could be optional, but we need to define what that means. In our implementation objects without owners are global and therefore have a special access provision (accessible by any client).

> Could we have more than one owner of the same object? 
I believe there should be a single owner of an object. I am curious to hear Bob L's scheme for a group being the only type of an owner.

> Should the owner always be an entity, or could it be another object; e.g. a group, or a role?
In our proposal only Entity can be an owner. Groups can provide access to objects, but that does not change the ownership. Group-owner may be possible in an alternative model.

> Could we have part-owners; e.g. N-of-M scenarios, where the owner is some defined minimum subset of entities, each having some partial claim to ownership?
Not in our model. What is the use-case here? Only a client that provides N different credentials from a set of M possible ones can access an object? In general, we view access as a separate category from ownership. It sounds to me that the N-of-M scenarios are about access, not ownership.

Regards,
Denis

-----Original Message-----
From: John Leiseboer [mailto:jleiseboer@bigpond.com] 
Sent: Thursday, June 23, 2011 10:46 PM
To: Tim Hudson; kmip@lists.oasis-open.org
Subject: RE: [kmip] Client Registration

Tim Hudson said:
> Bob (Griffin), I'd like to put on the agenda for the next meeting that
> we vote to defer the Entity and Client registration proposals for KMIP
> 1.1 and focus on sorting out the more direct need for device
> ...
> Currently, KMIP 1.0 avoids the entire topic as 'owner' is not visible
> outside of the server internal context.
> I don't think that it is unreasonable for KMIP 1.1 to continue to take
> the same approach.

I'd like to second Tim's call to defer the client registration proposal.

In looking at the client registration proposal, and specifically the
introduction of the new owner attribute, I kept asking myself, "Why is
it necessary to expose an owner attribute in the protocol?" I can see in
some applications that it is useful to have the concept of an owner, but
I'm not convinced that owner needs to be a defined attribute in the KMIP
protocol. Surely it can be handled as a logical attribute by the server.

As far as I can tell, the current proposed changes relating to owner,
mostly just change the default permissions from the "creator" of an
object to the "owner" of the object, where by default, the creator is
the owner. I see no value in this.

If we were to introduce an owner attribute, could it be optional? Could
we have more than one owner of the same object? Should the owner always
be an entity, or could it be another object; e.g. a group, or a role?
Could we have part-owners; e.g. N-of-M scenarios, where the owner is
some defined minimum subset of entities, each having some partial claim
to ownership? I think that all of these scenarios are reasonable, but
perhaps better handled outside the KMIP protocol and inside the server.

John

----------------------------------------------------------------
John Leiseboer                    QuintessenceLabs Pty Ltd
Chief Technology Officer          Suite 23, Physics Building #38
P: +61 7 5494 6740                Science Road
F: +61 2 6125 7180                Australian National University
M: +61 409 487 510                Acton, ACT 0200 Australia
mailto:jl@quintessencelabs.com    www.quintessencelabs.com
----------------------------------------------------------------



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

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.