Re: [kmip] Groups - Locate By Value 2 uploaded

Hello Bruce,

Yes, you are correct, there is/was an "Operational Policy Name" attribute that defines a policy for the object. And there are some "SHOULD" suggestions as to what policies might look like. But there is nothing there that says how to create a policy, or what sort of detailed things a policy can do. And for good reason -- that's difficult to do.

But I agree that the time is coming to deal with this properly. One place to start is to try to tie down that concept of "Owner" or User or, if we must, Initiator. My earlier idea was that they could be a non-cryptographic managed objects, with a Unique Id, that we could then hang attributes off. But that is all a separate discussion.

Anthony

On Thu, Nov 19, 2015 at 8:30 AM, Bruce Rich <brich@us.ibm.com> wrote:

Anthony,

Now that you've clarified the intended server control policy around this extended Locate, I'm OK with the proposal. Thanks. Kinda leaning to the second representation, but my vote could easily be swayed with a free beverage.

But now I'm puzzled by the assertion in the slides that "Server policy is not part of the KMIP specification". To semi-quote a former US president, perhaps the issue is what "is" means. My view is that the current, OASIS-approved KMIP spec for 1.2 still has section 3.18 in it, which gives clear instruction (in RFC 2119 terms) about required server policy (see lines 770 and following, which state (in part)..."A key management system implementation SHALL implement at least one named operation policy, which is used for objects when the Operation Policy attribute is not specified by the Client in operations that result in a new Managed Object on the server"). So in KMIP 1.2, there is a server policy defined in the specification, and clients that see their object has an OperationPolicyName attribute with a value of "default" would expect the server to honor that policy. We have recently been so bold as to deprecate this mechanism in drafts of KMIP 1.3 without yet defining a successor, but our online discussion has illustrated the problem we may have, to wit, absent a defined server policy and access control mechanism that enforces such policy, why choose a KMIP server to safeguard your secrets? I was reluctant to consider the extended Locate until you asserted policy about access control...and I would note that the deprecated-in-1.3-OperationPolicyName-policy-for-"default" actually would have addressed my concern about access in section 3.18.2.1, by saying that a successful Locate on a "Secret Object" would be restricted to the owner of that object, which is kinda what you asserted should be the case. So maybe OPN is useful enough to not be deprecated just yet. But that's a bigger topic than your proposal here, for which I started off by saying "Now...I'm OK with the proposal".

Bruce A Rich
brich at-sign us dot ibm dot com

From: Anthony Berglas <anthony.berglas@cryptsoft.com>
To: kmip@lists.oasis-open.org
Date: 11/17/2015 09:22 PM
Subject: [kmip] Groups - Locate By Value 2 uploaded
Sent by: <kmip@lists.oasis-open.org>

Submitter's message
Hello All,

This is an updated proposal on Locate by Value in response to the comments by Mark and Bruce.
-- Anthony Berglas
Document Name: Locate By Value 2
Description
Proposal to be able to Locate managed objects based on their values.
Download Latest Revision
Public Download Link
Submitter: Anthony Berglas
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder: Proposals
Date submitted: 2015-11-17 19:21:44

Anthony Berglas Ph.D.
Principal Engineer
Anthony.Berglas@Cryptsoft.com

kmip message