Sent: Thursday, April 14, 2016 8:30 AM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] Question for today's agenda: ID Placeholder
Hi Tim
I beg to differ:
4.38 Create Split Key
This operation requests the server to generate a new split key and register all the splits as individual new
Managed Cryptographic Objects.
The request contains attributes to be assigned to the objects (e.g., Split Key Parts, Split Key Threshold,
Split Key Method, Cryptographic Algorithm, Cryptographic Length, etc.). The request MAY contain the
Unique Identifier of an existing cryptographic object that the client requests be split by the server. If the
attributes supplied in the request do not match those of the key supplied, the attributes of the key take
precedence.
The response contains the Unique Identifiers of all created objects. The ID Placeholder value SHALL be
set to the Unique Identifier of the split whose Key Part Identifier is 1.
But Judy correctly points out that [in the preamble to Section 4 Client-to-Server Operations ] the specification neglects to include Create Split Key [and others] in the list of operations that potentially set the ID Placeholder:
4 Client-to-Server Operations
The following subsections describe the operations that MAY be requested by a key management client.
Not all clients have to be capable of issuing all operation requests; however any client that issues a
specific request SHALL be capable of understanding the response to the request. All Object Management
operations are issued in requests from clients to servers, and results obtained in responses from servers
to clients. Multiple operations MAY be combined within a batch, resulting in a single request/response
message pair.
A number of the operations whose descriptions follow are affected by a mechanism referred to as the ID
Placeholder.
The key management server SHALL implement a temporary variable called the ID Placeholder. This
value consists of a single Unique Identifier. It is a variable stored inside the server that is only valid and
preserved during the execution of a batch of operations. Once the batch of operations has been
completed, the ID Placeholder value SHALL be discarded and/or invalidated by the server, so that
subsequent requests do not find this previous ID Placeholder available.
The ID Placeholder is obtained from the Unique Identifier returned in response to the Create, Create Pair,
Register, Derive Key, Re-key, Re-key Key Pair, Certify, Re-Certify, Locate, and Recover operations. If
any of these operations successfully completes and returns a Unique Identifier, then the server SHALL
copy this Unique Identifier into the ID Placeholder variable, where it is held until the completion of the
operations remaining in the batched request or until a subsequent operation in the batch causes the ID
Placeholder to be replaced. If the Batch Error Continuation Option is set to Stop and the Batch Order
Option is set to true, then subsequent operations in the batched request MAY make use of the ID
Placeholder by omitting the Unique Identifier field from the request payloads for these operations.
Cheers,
… Dave
From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Thursday, April 14, 2016 9:16 AM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] Question for today's agenda: ID Placeholder
> W.r.t. ‘Create Split Key’, you misunderstood: Judy Furlong points out that the specification neglects to state that ‘Create Split Key’ [and some other new operations] sets the ID Placeholder.
Again a deliberate choice - as Create Split Key will generally return more than one unique identifier so the ID Placeholder is not set (unlike in Create Key Pair where there is only a single private key returned so the logic sort of made sense to set the ID Placeholder to that value even though there are two unique identifiers returned). But Create Split Key returns multiple unique identifiers to objects of the same type so there is no "special" one to select out as being the right one.
The whole context of ID Placeholder is to support logical chaining of operations in a single request within the limited set of contexts which made sense to the specification authors at the time.
Tim.
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.
This email and any attached files are confidential and intended solely for the intended recipient(s). If you are not the named recipient you should not read, distribute, copy or alter this email. Any views or opinions expressed in this email are those of the author and do not represent those of the Futurex company. Warning: Although precautions have been taken to make sure no viruses are present in this email, the company cannot accept responsibility for any loss or damage that arise from the use of this email or attachments.