FW: [kmip] Application Specific Information conerns

["Frindell,Alan" <Alan.Frindell@safenet-inc.com>]

FYI - Rene and I exchanged a few emails on this topic.  See below for the use-case and discussion related to server set Application Specific Information.

 

Thanks

 

-Alan

---

From: Rene Pawlitzek [mailto:rpa@zurich.ibm.com]
Sent: Thursday, July 23, 2009 2:12 AM
To: Frindell,Alan
Cc: ZRL Key Management
Subject: RE: [kmip] Application Specific Information conerns

Hi Alain: 

A client is indeed not able to generate these short IDs, 
so the server must do it for the client. You wrote: 

  "Any naming scheme more sophisticated than a 
purely random identifier however, is likely to be very application or domain 
specific." 

The Application Specific 
Information attribute is exactly for this purpose. It doesn't matter if it is 
not understood by all applications. Information stored by this attribute is only 
relevant to some applications. I don't think that protocol extensions should be 
used to implement this functionality. 

The KMIP usage guide should list a number of application name spaces and 
the query operation could potentially list all application name spaces supported 
by a server. 

Rene 

PS: Please feel free to forward our 
discussion to the list.

From:	"Frindell,Alan" <Alan.Frindell@safenet-inc.com>
To:	Rene Pawlitzek <rpa@zurich.ibm.com>
Date:	07/23/2009 02:17 AM
Subject:	RE: [kmip] Application Specific Information conerns

---

Hi Rene, thanks for the reply. 
 I understand why tapes or other client applications might need a lookup 
identifier other than the key ID.  My first thought is that the client 
should be responsible for generating these IDs, and setting them as a Name, 
Custom or Application Specific attribute.  If the client needs the server 
to enforce a uniqueness constraint, the lookup identifier should be set in the 
Name attribute, which the spec says must be unique in the KM domain. 
  
  
I can foresee applications where the client is technically not able to 
generate these IDs.  For generating a random ID of different length than 
the key ID, I wouldn't object to an option for clients to request the server 
create an N byte unique Name attribute during a Create or Register 
operation. 
  
Any naming scheme more sophisticated than a purely random identifier 
however, is likely to be very application or domain specific.  I think such 
requests for 'special' server generated names should be handled via a protocol 
extension.  The challenge I see with the current proposal is that a server 
implementer is given no guidance with how to respond to a request containing 
AppNameSpace=LTO-4-IBM, other than to fail the request.  My hope in making 
this an explicit extension, rather than an implicit one, is two-fold. 
 First, that the algorithms to generate these names will be published and 
shared with all KMIP server vendors, to promote interoperability.  Second, 
that clients will understand they are utilizing functionality that may not be 
provided by all KMIP vendors, and should not rely on this functionality always 
being present. 
  
Also, would you mind if I forwarded our discussion to the 
list?  There may be other members of the TC would would appreciate seeing 
the use-cases and engaging in the discussion. 
  
Thanks 
  
-Alan

---

From: Rene Pawlitzek [mailto:rpa@zurich.ibm.com] 
Sent: Wednesday, July 22, 2009 4:37 AM
To: 
Frindell,Alan
Subject: Re: [kmip] Application Specific Information 
conerns


Hi 
Alan: 

One of the 
use-cases for the server-set Application Specific Information attribute is the 
exchange of encrypted tapes. These tapes store terabytes of data but offer only 
a limited number of bytes to store the ID of the key that was used to encrypt 
the tape. For IBM written tapes, only 12 bytes can be used to store a key ID! 
The unique identifier of managed objects in KMIP won't fit in 12 bytes. In other 
words, the statement 

  uuid = createKey (...);   // creates a key and returns a 
long uuid 

returns an identifier (uuid) that is too long. The server-set 
Application Specific Information attribute can help to generate a short 
(12-byte) ID: the client can set an Application Specific Information instance 
but omit the data value. The server would then fill in the Application Specific 
Information value and return it to the client. Of course, this would only occur 
if the server is aware of the Application Specific Name Space used in the call. 
In other words, the sequence 

 uuid = createKey (...);   // creates a key 
and returns a long uuid 
 shortID = setAttribute (uuid, AppSpecInfo { 
AppNameSpace=LTO-4-IBM });  // server understands name space LTO-4-IBM and 
returns a short ID 

allows you to obtain a short (12-byte) ID that you can store on the 
tape. When the tape is read again, you can do a locate to search for a key with 
a Application Specific Information attribute that contains the short ID. 

As you can see, 
this simple mechanism will enable the exchange of encrypted tapes (without 
pre-generating the short IDs for all keys upfront). We have convinced HP (Stan 
Feather) to agree that all future encrypted tape exchange will happen using this 
mechanism. 

The 
mechanism can be used in all circumstances where you need to generate 
information at the server-side on demand. I hope that I could also convince you 
of the usefulness of this feature. 

Wishing you a nice day 
Rene 

--

Rene Pawlitzek 
dipl.ing.inf.ETH 
Principal R&D Engineer 
& 
Advisory 
Project Manager
IBM Zurich Research Lab.
Department of Computer 
Science
Saeumerstr. 4
CH-8803 Rueschlikon
Switzerland
tel.: 
+41-44-724-8683
mail: rpa@zurich.ibm.com
http://www.zurich.ibm.com/~rpa/

http://hamlets.sourceforge.net

From:	"Frindell,Alan" <Alan.Frindell@safenet-inc.com>
To:	"kmip@lists.oasis-open.org" <kmip@lists.oasis-open.org>
Date:	07/21/2009 06:21 PM
Subject:	[kmip] Application Specific Information conerns

---

I'd like to echo Indra's 
earlier concerns regarding a provision in the Application Specific Information 
proposal.

The provision creates an option for the client to ask the 
server to set the application specific information for any namespace, and 
requires the server to return an error if the namespace is not understood. 
 The namespaces listed are merely examples, however, and no data is given 
for how the server should set the data for any particular namespace.  A 
server implementer who follows the specification and usage guide will not know 
how to set any Application Specific Information values, and therefore will not 
be interoperable with clients relying on this functionality.  In effect, 
any arbitrary namespace string is an implicit critical extension to the 
protocol.

The severity of the impact depends on how the client responds 
to this error.  A sophisticated client might have enough logic to handle 
the failure, and send a new request without the App Specific Info request. 
 A more naive client will simply not interoperate.

A related issue 
is that different vendors could end up using the same Application Specific 
namespace with different expectations for how the values should be set, 
resulting in more interoperability problems.

Wouldn't it be better to 
leave Application Specific Information to be explicitly set by the client or 
template values, and define extensions governing how the server should set given 
namespace-specific information (per section 6.16)?  This has the advantage 
that clients requiring this functionality for operation can set the criticality 
indicator to True.  Though not presently defined, extensions could be 
registered to prevent collisions.  Hopefully vendors will publish their 
extension specifications so other KMIP servers can serve enhanced 
clients.

Rene, can you explain the intended use-cases for server-set App 
Specific Information?  Do you think extensions might be a more 
interoperable way to address them?

Thanks

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




---------------------------------------------------------------------
To 
unsubscribe from this mail list, you must leave the OASIS TC that
generates 
this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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