OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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 ofunstructured data.ppt) uploaded

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





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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]