OASIS Open Mailing List Archives  ·  All Lists  ·  kmip-interop-tech  ·  2012-09

kmip-interop-tech — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Re: KMIP templates


I would say that this is way too complicated. If I add x-Attr2 to the template, and then Get Attributes and see both x-Attr1 and x-Attr2 coming back, but only x-Attr1 applies to objects created with this template, then I would be confused. If I then Modify Attribute on x-Attr1, what does that mean? Does the modified version apply on the Create, or is modify not allowed because the template value is immutable? But Modify Attribute on x-Attr2 is allowed. Regardless of the complication for implementers of KMIP (which I admit, I would like to avoid!) I think the result would also be too complicated to explain to end-users of KMIP. Therefore, if the value of KMIP managed objects is immutable, then I would like that the value of a template is not defined as the contributing attributes, since after all a template is merely administrative sugar and is not really cryptographic material. I would prefer (and have so implemented) that if you add attribute x-Attr2 to the template, it is treated exactly as x-Attr1. This would be keeping it all simple -- easier to implement, document and understand. Jim Flood On 9/4/2012 2:13 PM, Tim Hudson wrote: Now the fun begins (not that it hasn't been fun so far). When you Add/Modify/Delete Attribute on a managed object that is a template what you are actually conceptually doing? Those operations apply to attributes of the managed object - which means they do not effect the attributes that are the 'value' of the managed object (i.e. in Section 2.2) and applied to objects created that reference a template. So to make this clear: 1) Register Template with x-Attr1 2) Add Attribute x-Attr2 to template 3) Create with reference to template     => the symmetric key returned will have x-Attr1 and not x-Attr2 This all comes back to the fundamental principle in KMIP - that managed objects do not change - they are invariant. Attributes associated with a managed object can change (subject to the rules specified for the particular attribute) but they are not the managed object as such. Now we can reasonably argue that the wording in 2.2.6 is sufficiently unclear that almost any interpretation is possible for what is meant - however the model in KMIP used for managed objects and attributes doesn't really support some of the interpretation I think you are trying to indicate. You actually have to read through the wording in 2.2.6 keeping in mind that Template means the structure in Table 33 in some of the places ( an attribute specified in a Template ) and the object itself ( to the Template ). I think you are missing that distinction. X-NONE X-NONE MicrosoftInternetExplorer4 An attribute specified in a Template is applicable either to the Template itself or to objects created using the Template. That does not say Attributes of a Template are applicable either to the Template itself or to objects created using the Template which appears to be how you are reading it. Or am I completely misreading what you wrote? Tim.

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]