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

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

Understand.  But for example, one could put a volume identifier (e.g., barcode label, serial number) for a removable medium (e.g., tape) in an Application Specific ID and a key ID that was used on that removable medium in the Name.  Then the key could be located by either the App. Spec. ID indirectly, or by the key ID. However, duplicate volume identifiers may exist, so uniqueness in the key ID is a good thing.

 

It seems that the one salient difference is that Names need to be unique within the key management system, whereas App. Spec. IDs do not.  In the particular case of key IDs, I was assuming they would also require the same level of uniqeness, but if not, then App. Spec. IDs would be fine.

 

thanks,

Rod Wideman

Quantum Corporation

(please disregard the confidentiality statement below)

---

From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Thursday, June 11, 2009 8:52 AM
To: Rod Wideman
Cc: kmip@lists.oasis-open.org
Subject: RE: [kmip] Groups - Application Specific IDs (Application Specific IDs.pdf) modified

Rod, 

"Rod Wideman" <Rod.Wideman@quantum.com> wrote on 06/11/2009 
12:06:10 AM:

> 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 App-Specific ID allows applications to resolve the 
cryptographic object they needed, unless applications are directly using the 
KMIP Unique Identifier or KMIP Name. So the App-Specific ID not only identifies 
the application(s) using the object, but also provide the means for the 
application(s) to resolve back to that object. 

For instance, the App-Specific ID may contain a filename of a file 
encrypted with the key. For tape encryption, the application may store its own 
Tape Key ID on the tape cartridge, hence the App-Specific ID would contain that 
same Tape Key ID. 

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

These identifiers (Key 
ID, key name) too are assigned to allow applications to resolve which 
cryptographic object they need. So they could fit under App-Specific IDs as 
well. 

So far, in terms of identification, 
we have defined for each Object: 

- a Unique 
Identifier, which is assigned by the server in a globally-unique fashion and is 
immutable.   

- one or more Names, 
which can be assigned/modified by the client or server, and the server ensures 
Names are unique within a given key management domain. Both Unique Identifier 
and Names are KMIP constructs used primarily for the sake of KMIP operations. 
Names make it for instance easier for humans to manage objects than Unique 
Identifiers. 

- one or more pairs of 
Application Name Space / Application Identifier that are set by applications on 
the client side (possibly involving the server if it is competent for that name 
space and if requested by the client, as proposed by Rene). But generally, this 
App-Specific ID is irrelevant to the KMIP server. 

Applications may decide to directly use the KMIP Unique Identifier or 
KMIP Names to resolve Objects. Alternatively, if these KMIP constructs are not 
suitable (for instance, legacy reasons), the App-Specific ID can be used 
instead. 

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

You can also see KMIP Name as a 
"direct" reference to the object, whereas App-Specific ID enables apps to 
resolve a reference in their own name space (such as filename, Tape Key ID, etc) 
to the actual KMIP Unique Identifier of the corresponding object. 

I think it will depend on the particular use case 
whether it is more appropriate to have an application resolve the cryptographic 
object using the KMIP Unique Identifier, KMIP Name, or App-Specific 
ID. 

Regards, 
-Robert 

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