The object type is not needed in Create Split Key but it is needed
in Join Split Key and the split could have been performed on any
managed cryptographic object and without that information we may not
have sufficient detail to be able to construct a joined object of
the correct type.
Currently you cannot split Opaque Data - as the 2.2.5 definition
states "managed cryptographic object" - but you can split Secret
Data - and for secret data to join will require knowledge of the
Secret Data Type to produce - so that will need to be an optional
parameter.
Summary: removing ObjectType from CreateSplitKey makes sense but is
inconsistent with Create (as noted by Bruce); removing ObjectType
from JoinSplitKey doesn't make sense - it is required and for
SecretData we will also need the SecretDataType - as an optional
parameter.
Alternatively we could place the ObjectType and SecretDataType into
the Split Key object itself so that each part carries the
information about the original object (which may have been
registered or the result of a CreateSplitKey operation).
Tim.
On 24/04/2013 12:12 AM, Kelley Burgin wrote:
Hi Bruce,
You're right that I included the Object Type in Create Split
Key to mimic the Create request. I don't think it's needed and
am happy to take it out - you're not the first person to point
this out. I'm less certain that it's unnecessary in Join Split
Key - I could make the Object Type optional in the Join Split
Key request. What do you think?
Kelley
On Apr 23, 2013, at 7:11 AM, Bruce Rich wrote:
Kelley,
A couple of questions
regarding the required ObjectType input parameter. It
kinda makes sense on JoinSplitKeys (maybe). I don't quite
get why it's a required input on CreateSplitKeys, and
exactly what it should be, given that the server is
supposed to object if the wrong ObjectType is specified.
I suspect that you were
more or less reflecting the Create operation for a
SymmetricKey, where it's a required input parameter. At
this point, I think its presence on that API is vestigial,
that at one point, Create was anticipated to be the
mechanism for all object creation, but later we realized
that the input parameters were going to be different for
different object types, so what made sense at a high level
made no sense at a lower level, but we never circled back
around and removed it.
However, if the ObjectType
is meaningful as input on CreateSplitKeys, then you need
to discuss how the server would behave differently based
on the value supplied as input. And I guess that really
also applies to JoinSplitKeys...how should the server
behave differently based on the ObjectType requested? If
no behavioral changes are implied, then I don't see why
it's there. And if behavioral changes are implied, then
we need to spell them out so that we can get
interoperability.
And I'm OK with the Link
discussion in the Usage Guide, given that it's
non-normative and relegated to client optional behavior.
Bruce A Rich
brich at-sign us dot ibm dot com
From:
Kelley Burgin
<kwburgi@tycho.ncsc.mil>
To: kmip@lists.oasis-open.org
Date:
04/16/2013 05:42
AM
Subject:
[kmip] Groups
- Split_Key_Proposal_v0.5.docx uploaded
Sent by:
<kmip@lists.oasis-open.org>
Submitter's message
Includes Usage Guide text.
-- Mr. Kelley Burgin
|