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:]
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"
<>
To:
Rene Pawlitzek
<>
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:]
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:
http://www.zurich.ibm.com/~rpa/
http://hamlets.sourceforge.net
From:
"Frindell,Alan"
<>
To:
""
<>
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.
