OASIS Key Management Interoperability Protocol (KMIP) TC

Hi Tony   Would you please add the following question regarding ID Placeholder to today’s agenda.   Cheers, … Dave   Initial conditions:   Managed Cryptographic Object (Name) State foo Deactivated bar Active   Batch request: ·          Batch Order Option = true   Batch Item # Operation ID Placeholder (after Operation) Comment 1 Locate [ Name = foo ] ID Placeholder=UID( foo ) Locate by Name sets the ID Placeholder to foo 2 Revoke [ UniqueIdentifier =UID( bar )] ID Placeholder=No change=UID( foo ) This Revoke explicitly sets the UniqueIdentifier . Revoke does not [cannot] set the ID Placeholder. 3 Destroy [ UniqueIdentifier =ID Placeholder] ID Placeholder=No change=UID( foo ) Destroy s foo !? This Destroy does not explicitly set the UniqueIdentifier , so implicitly uses the ID Placeholder, which identifies foo .   It seems strange, and hazardous, that the Locate operation’s setting of the ID Placeholder can leapfrog the Revoke operation’s explicit setting of the UniqueIdentifier to have effect on the operation following Revoke . A reasonable expectation for the above scenario would be that the Revoke operation sets the ID Placeholder to its explicitly set UniqueIdentifier (thereby resulting in the Destroy of bar instead of foo ).   QUESTION : Why does the KMIP specification deny setting of the ID Placeholder to operations like Revoke , Check , Get , and others that operate on a single, possibly explicit UniqueIdentifier ?   BTW – As pointed out by Judy Furlong, the KMIP specification seems to have neglected ID Placeholder w.r.t. some of the newer operations [e.g. Split Key ].   Cheers, … Dave   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.

Just checking - do you think the specification is unclear on the behaviour here or not? Get doesn't "set" the ID Placeholder as it is already set by previous operations - either you know the Unique Identifier and provided it and can provide it equivalently in subsequent batch items or you are using the ID Placeholder in the Get itself and it remains unchanged - that is consistent - and that is the class of behaviour you are basically finding strange - it applies across all the operations which aren't constructors or search operations. It isn't hazardous any more than saying someone could put the wrong unique identifier values in batch items and get something other than what they intended - the request is well defined - the outcome is unambiguous.  That the Create Split Key operation does not use the ID Placeholder was a deliberate choice at the time. It is a constructor of objects - so it follows the same pattern as the other constructor operations - and even though it can construct based on other objects (just like Derive Key can) it also follows that pattern to not use the ID Placeholder.  On Check you need to look at the context - the ID Placeholder is used on Check - but Check itself clears it if the result of the Check would be a failure - deliberately so that it can be combined in a batch and effectively act as a conditional - only if Check passed correctly do the following operations have the required items specified. There is no "leapfrog" going on here  Tim.

Hi Tim   You are quite correct to say that the KMIP specification defines the behaviour unambiguously – if you know the spec you can predict the outcome – but I suggest that this behaviour is counter-intuitive. It makes more sense that an explicitly specified UID would in turn set the ID Placeholder to that same UID. I can foresee issues with changing the spec in the KMIP 1.X timeframe, but this matter could be considered for KMIP 2.0.   W.r.t. ‘Check’, you’re correct – I chose a bad example.   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.   Cheers, … Dave     From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson Sent: Thursday, April 14, 2016 8:42 AM To: kmip@lists.oasis-open.org Subject: Re: [kmip] Question for today's agenda: ID Placeholder   Just checking - do you think the specification is unclear on the behaviour here or not?   Get doesn't "set" the ID Placeholder as it is already set by previous operations - either you know the Unique Identifier and provided it and can provide it equivalently in subsequent batch items or you are using the ID Placeholder in the Get itself and it remains unchanged - that is consistent - and that is the class of behaviour you are basically finding strange - it applies across all the operations which aren't constructors or search operations. It isn't hazardous any more than saying someone could put the wrong unique identifier values in batch items and get something other than what they intended - the request is well defined - the outcome is unambiguous.    That the Create Split Key operation does not use the ID Placeholder was a deliberate choice at the time. It is a constructor of objects - so it follows the same pattern as the other constructor operations - and even though it can construct based on other objects (just like Derive Key can) it also follows that pattern to not use the ID Placeholder.    On Check you need to look at the context - the ID Placeholder is used on Check - but Check itself clears it if the result of the Check would be a failure - deliberately so that it can be combined in a batch and effectively act as a conditional - only if Check passed correctly do the following operations have the required items specified.   There is no "leapfrog" going on here    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.

> 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.

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.

Good point - I missed what you were trying to point out there - the list of operations wasn't updated. Tim. On Thu, Apr 14, 2016 at 11:25 PM, Featherstone, David < David.Featherstone@safenet-inc.com > wrote: 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.

The operations for " Table 321: Operation and Object Cross-reference" and for the Attribute Tables also need updating.  For example Unique Identifier should be implicitly set for Create Split Key, but it is not listed in " Table 43: Attribute Rules".  Table 321 does not have any new operations since version 1.1. Alexander Downey Software Engineer Office: +1 (830) 980-9782 x1332 Cell: +1 (614) 370-9284 E-mail: adowney@futurex.com Connect with us: Web Twitter LinkedIn Google+ Facebook From: kmip@lists.oasis-open.org [kmip@lists.oasis-open.org] on behalf of Tim Hudson [tjh@cryptsoft.com] Sent: Thursday, April 14, 2016 8:30 AM To: kmip@lists.oasis-open.org Subject: Re: [kmip] Question for today's agenda: ID Placeholder Good point - I missed what you were trying to point out there - the list of operations wasn't updated. Tim. On Thu, Apr 14, 2016 at 11:25 PM, Featherstone, David < David.Featherstone@safenet-inc.com > wrote: 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.