Re: Split_Key_Proposal_v0.3.docx uploaded

[Bruce Rich <brich@us.ibm.com>]

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