[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]