kmip message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [kmip] Groups - Application Specific IDs (Application Specific IDs.pdf) modified
- From: Robert Haas <rha@zurich.ibm.com>
- To: "Rod Wideman" <Rod.Wideman@quantum.com>
- Date: Thu, 11 Jun 2009 15:52:29 +0200
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
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]