kmip message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Fw: [kmip] Re: Split_Key_Proposal_v0.3.docx uploaded
- From: Bruce Rich <brich@us.ibm.com>
- To: kmip@lists.oasis-open.org
- Date: Wed, 27 Mar 2013 10:05:52 -0500
Hmm, looks like the "certificate"
form of credential was removed before we got to KMIP 1.0, so that would
need to be added back in before this proposal would have a chance. Right
now, certificates are imputed from the TLS connection.
Bruce A Rich
brich at-sign us dot ibm dot com
----- Forwarded by Bruce
Rich/Austin/IBM on 03/27/2013 09:58 AM -----
From:
Bruce Rich/Austin/IBM@IBMUS
To:
kmip@lists.oasis-open.org
Date:
03/26/2013 10:10 PM
Subject:
[kmip] Re: Split_Key_Proposal_v0.3.docx
uploaded
Sent by:
<kmip@lists.oasis-open.org>
As per direction on the 14 March KMIP
call, I took a pass at this proposal, with a view to the current access
control model and how we might harmonize this a bit better. I also
discussed most of these ideas with Kelley, but please don't blame him for
this. Here goes:
I see a couple of issues with the current proposal:
1) The SplitKeys that are created are not linked in any way to a specific
owner, so the server cannot tell whether a get() for split #x should be
allowed or not.
2) If we fix issue 1 such that they do have owners, the splits have links
to someone else's objects, and access rules are not going to allow such
a link chain to be traversed.
Here's a different proposal, one that purports to address those issues
(and will no doubt raise others, but perhaps generate more light than heat):
The CreateSplitKey operation will pass an array of references to the owners
for the various splits. These references could be Credential objects,
or could be UUIDs. Since "owners" are not UUIDs now (from
a specification view), I would initially propose Credential objects.
Examples of such Credential objects
would include certificates or the UsernameAndPassword(with the Password
omitted). These two examples are both public information that can
be known about others.
We will NOT create Links between the splits, but rather the CreateSplitKeys
will return the UUID of a new managed object (a SplitKeyController?) that
records the metadata about the splits and their owners, including voting
scheme if not all split owners need to participate for things to succeed.
So I guess the operation morphs from CreateSplitKeys to CreateSplitKeyController.
This SplitKeyController will have an owner that is the current caller,
as per usual KMIP rules, and lifecycle is usual KMIP rules ("I brought
you into this world, and I can take you out"). The thing that
would be different for a SplitKeyController is that anyone who is listed
as an owner of a split could get() it, so they could see the UUIDs for
the splits and the respective owners...and we need to be able to locate()
these splits. Since we are creating a new managed object, we get
to define what the default access policy would be... And I think
it would be helpful if the SplitKey objects had a reference (UUID) back
to the SplitKeyController, but that's perhaps debatable.
The creator of the SplitKeyController may initialize it at creation with
a SymmetricKey that they already own (UUID reference), and that SymmetricKey
could optionally cease to exist as a separate cryptographic managed object,
having been subsumed into the collective. Or we could appeal to server
policy, but I'd rather not as that seems to lead to noninteroperability..
Additional thoughts
Additional lifecycle operations on a SplitKeyController? like rekey() for
example. Or a new operation to have the SplitKeyController be the
controller for a voting scheme mechanism for the SplitKeys it "controls",
but that probably involves preservation of state on the server, and I'd
rather not see us go that way. Lacking this, we'd be leaving the
algorithm by which one comes up with the necessary parts (e.g., voting)
outside of KMIP protocol control, which may be OK, or not, depending on
usecase.
Names for SplitKeys? Perhaps if the CreateSplitKeyController had
a single Name attribute passed in, the newly-created individual SplitKey
objects could have a Name that was "nameOfController"."splitnumber".
This way we can have rekey of a SplitKey done at the Controller level,
and owners of the splits can find them without needing read access to the
SplitKeyController metadata.
Since the splits have a creator now that reflects who should have access,
one can find a new split by locating SplitKey objects and seeing what the
controller UUID is. Or if subnames are used as suggested above, one
can find them that way.
Exercises for student...if controller created the SplitKey, should the
owner of the new SplitKey be able to destroy() it?
And I suppose that if we're going to be creating splits for entities other
than ourselves, we might optionally also have enough info to notify() them
about SplitKeys having been created for them, and it might be handy during
additional lifecycle events...
Does this solve any problems? Or did I make things worse? Not
having a complete use case defined makes it difficult to see progress.
Bruce A Rich
brich at-sign us dot ibm dot com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]