kmip message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [kmip] Groups - Encoding Options for Key Wrap (key-wrap of unstructureddata.ppt) uploaded
- From: Mathias Bjoerkqvist1 <MBJ@zurich.ibm.com>
- To: stan.feather@hp.com, "Fitzgerald, Indra" <indra.fitzgerald@hp.com>
- Date: Mon, 13 Sep 2010 10:24:20 +0200
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]