OASIS Key Management Interoperability Protocol (KMIP) TC

The document named Encoding Options for Key Wrap (key-wrap of unstructured
data.ppt) has been submitted by Mr. Stan Feather to the OASIS Key
Management Interoperability Protocol (KMIP) TC document repository.

Document Description:
This document proposes an encoding option for wrapped keys, to better
support clients behind KMIP proxies.  Additional use cases for key wrap are
also proposed.

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

Download Document:  
http://www.oasis-open.org/committees/download.php/39291/key-wrap%20of%20unstructured%20data.ppt


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

Hi Stan, Indra,

Thanks for putting together this proposal.
At this point I only have a few minor
comments:

- As you state that the Key Value SHALL
be TTLV encoded if the Key Value structure consists of something other
than only a Key Material Byte string (slide 4), this basically rules out
any other Encoding Options (e.g., XML or vendor-specific extensions). Since
you also don't list any extensions in the 9.1.3.2.31 table on Slide 7,
the proposal is consistent. However, explicitly stating whether other encoding
options are possible or not would help to make it more clear.

- On slide 8 for the requested Use Cases
addition, I would suggest that we swap the operations (first Register a
wrapped key, then Get it and finally Destroy it, with different Encoding
Options). If we do it the other way around, the server would end up with
two different keys with the same key material, which might not be allowed
with certain policies (e.g., strict access control).

- If the server is not in possession
of the key material for the Wrapping Key, but only storing the wrapped
key as it was received e.g., through a Register operation, it might not
be possible for the server to serve the key with any other Encoding Option.
For this situation, I would suggest also adding a new Result Reason enumeration
value, or rename the existing "Key Format Type and/or Key Compression
Type Not Supported" Result Reason to also include this case. The error
case in Table 236 in Section 11.11 (Get) should also be modified accordingly
or a new case added.


Regards,
Mathias

Thank you Mathias.  These are excellent points.  I’ll include
this feedback and update the proposal.



Stan







From: Mathias Bjoerkqvist1 [mailto:MBJ@zurich.ibm.com]

Sent: Monday, September 13, 2010 2:24 AM

To: Feather, Stan S; Fitzgerald, Indra

Cc: kmip@lists.oasis-open.org

Subject: Re: [kmip] Groups - Encoding Options for Key Wrap (key-wrap of
unstructured data.ppt) uploaded







Hi Stan, Indra,


Thanks for putting together this
proposal.

At this point I only have a few
minor comments:


- As you state that the Key
Value SHALL be TTLV encoded if the Key Value structure consists of something
other than only a Key Material Byte string (slide 4), this basically rules out
any other Encoding Options (e.g., XML or vendor-specific extensions). Since you
also don't list any extensions in the 9.1.3.2.31 table on Slide 7, the proposal
is consistent. However, explicitly stating whether other encoding options are
possible or not would help to make it more clear.


- On slide 8 for the requested
Use Cases addition, I would suggest that we swap the operations (first Register
a wrapped key, then Get it and finally Destroy it, with different Encoding
Options). If we do it the other way around, the server would end up with two
different keys with the same key material, which might not be allowed with
certain policies (e.g., strict access control).


- If the server is not in
possession of the key material for the Wrapping Key, but only storing the
wrapped key as it was received e.g., through a Register operation, it might not
be possible for the server to serve the key with any other Encoding Option. For
this situation, I would suggest also adding a new Result Reason enumeration
value, or rename the existing "Key Format Type and/or Key Compression Type
Not Supported" Result Reason to also include this case. The error case in
Table 236 in Section 11.11 (Get) should also be modified accordingly or a new
case added.



Regards,

Mathias