RE: [kmip] Groups - Application Specific IDs (Application Specific IDs.pdf) modified

["Rod Wideman" <Rod.Wideman@quantum.com>]

It seems that the original intent of the Application Specific
Identification attribute was to provide a way to describe how a managed
cryptographic object is used, or to what it is associated (i.e.,
identify the application, not the object).  I think this is still useful
to have, in that objects can then be located that are associated with a
particular application or usage.

The current discussion seems to be oriented around using this attribute
as a means to assign an identifier to the object itself (e.g., in the
case of Scott's proposal, a Key ID, which I think is similar to what
Stan is describing as a key name).  This then makes me wonder what the
Name attribute should be used for, and whether it would make sense to
add one or more additional Name Type enumerations of various "key ID" or
"key name" variants to address that specific need, and let the
Application Specific attribute continue to provide a way to associate
the object with applications.

So for example, I might have a key that has a Name attribute and a Key
ID name type.  I use this key to encrypt files, so have Application
Specific Id. attribute instances to describe the name space(s) of the
files for which I use the key.  

But I may use more than one key to encrypt files in those name spaces,
so if I have another key (having its own Name attribute and different
Key ID name type), then I could set the same Application Specific Id.
attribute instances with it.  Now I can locate all objects (i.e., keys)
associated with that particular application usage.

So I see Name as referencing the object (i.e., pointing to it) and the
Application Specific stuff pointing away from the object (i.e., where
does it go).  The need for "key id" seems to fit the Name attribute, but
perhaps I'm missing something?

Thanks,
Rod Wideman
Quantum Corporation
(please disregard the confidentiality statement below)


-----Original Message-----
From: Feather, Stan S [mailto:stan.feather@hp.com] 
Sent: Friday, June 05, 2009 4:54 PM
To: skipp@brocade.com; kmip@lists.oasis-open.org; Rene
Pawlitzek/Zurich/IBM
Subject: RE: [kmip] Groups - Application Specific IDs (Application
Specific IDs.pdf) modified

Scott, Renee

Here are my suggestions about your proposals, which involve changes to
the same attribute.  This attribute is also the subject of some pending
usage guide proposals from HP, for key naming with streaming/removable
media.

Scott, you propose multiple fields, up to 8.  But as defined, the client
can already create an arbitrary number of instances.  Given that, do you
think multiple ID attributes are still needed?

On Renee's proposal, I have these comments.  First, I have some concerns
about the 2nd paragraph "Clients can provide an instance....".  Overall,
it seems like a given instance of the attribute should be owned by the
client, or the server, but not both.  Mixing ownership of structure
elements in a single instance seems to rely heavily on client-server
integration details, and probably should be out of scope.  But I may not
understand the use case.

So I would suggest the 2nd paragraph be replaced with a simplification,
to the effect that, a given instance of this attribute may be set by the
client, or the server.  Setting the attribute establishes ownership for
that instance, for subsequent modifications or deletions.

Also, moving the examples to the Usage Guide is a great idea.  Those
could be extended with the examples in Scott's proposal.  

As mentioned in the call yesterday, I expect to have a proposal soon
with further Usage Guide changes for this attribute.

Stan Feather
HP StorageWorks, R&D


 



-----Original Message-----
From: skipp@brocade.com [mailto:skipp@brocade.com]
Sent: Wednesday, May 20, 2009 11:27 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] Groups - Application Specific IDs (Application Specific
IDs.pdf) modified

Information about the document named Application Specific IDs
(Application Specific IDs.pdf) has been modified by Scott Kipp.

Document Description:
This proposal suggests to add more than one Applications Specific ID and
change the name and definition to broaden its scope.

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=32335

Download Document:  
http://www.oasis-open.org/committees/download.php/32335/Application%20Sp
ecific%20IDs.pdf


PLEASE NOTE:  If the above links do not work for you, your email
application may be breaking the link into two pieces.  You may be able
to copy and paste the entire link address into the address field of your
web browser.

-OASIS Open Administration

---------------------------------------------------------------------
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 transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum Corporation. Furthermore, Quantum Corporation is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.