kmip-interop-tech — archive

Re: KMIP templates

From: Bruce Rich <[email protected]>
To: [email protected]
Date: Wed, 05 Sep 2012 19:02:00 -0000

Yeah, what he said. And I would note that "immutable" does not appear in the spec, so asserting that it's an essential property of KMIP Managed Objects is difficult to agree to. I agree that Managed Cryptographic Objects do not currently have mutators (if one asserts that Attributes are not part of the objects). I believe that's merely an observation, not a specification of anything. And in the case of one object we have that's a Managed Object without being a Managed Cryptographic Object, it's really hard to swallow immutability. The lifecycle of an immutable Template would be weird...an object that is only a collection of attributes cannot be changed, so one could not addAttribute, modifyAttribute, deleteAttribute? One could not edit such a beast. One could only Register and Destroy. Seems like a lot of spec changes, a lot more than just crisping up the behavior of Template.get(). Bruce A Rich brich at-sign us dot ibm dot com From: Mathias Bjoerkqvist1 <[email protected]> To: [email protected] Date: 09/05/2012 07:17 AM Subject: Re: [kmip-interop-tech] Re: KMIP templates Sent by: <[email protected]> All, Treating all attributes that apply to objects created using the Template (the "value" of the Template) as immutable as in Tim's interpretation does have some problems: -Performing Add/Modify/Delete Attribute on any attributes that do not apply to the template itself basically does nothing, since the attribute is not returned in Get or Get Attributes operations, nor is it applied to objects created using the template. -You can only perform Locate queries for templates using the attributes that apply to the template itself. So to find a Template that creates objects belonging to a specific Object Group, you would have to Get all the templates and look at the attributes yourself. Granted, this is also the case for other managed objects (where you cannot do a Locate on the key material for example), but it limits the usefulness of the template and is IMHO another reason for treating it in a different way from the other managed objects. In my interpretation (and implementation) of templates, I am in favor of allowing Add/Modify/Delete Attribute on all attributes for Templates (both the ones that apply to the template and to objects created from it), and I don't differentiate between attributes passed in inside the Template structure or as attributes inside the Template-Attribute structure when registering a template. I find this to be in accordance with the current wording in the spec. I can see Tim's point with the "model" in KMIP, but I still find my interpretation to be in-line with the spec, and having the template "value" be immutable might be limiting its usefulness. Like Bob suggested, it might make sense to take a step back at this point and look at use cases. We should also consider whether or not whatever changes/clarifications we make will be backwards compatible with existing v1.0 and v1.1 implementations, especially if we target v1.2 (as opposed to v2.0). I wouldn't want to have to go through the whole Attribute Index exercise again. Regards, Mathias From: Jim Flood <[email protected]> To: [email protected] Date: 05.09.2012 00:49 Subject: Re: [kmip-interop-tech] Re: KMIP templates Sent by: <[email protected]> Ok then, I see what you mean. In that case, you put the "contributing attributes" into the Template of the Register's Request Payload, after which you cannot add, modify or delete from this set without destroying and re-creating the template. Then it could be clear that an attribute outside of the Template applies the the managed object -- the template -- itself, for example, a Name attribute. The reason Name is not allowed as part of the template value comes from the fact that names must be unique, and so a template can't assign the same Name over and over again, and not for any other special reason. Therefore, Name cannot be included inside the Template (of the Register's Request Payload.) Furthermore, I would argue that Get Attributes would not see any of these attributes passed in the Template of the Register. Get Attributes would only return Name, Initial Date, etc. -- those attributes of the template-as-a-managed-object. Get/Modify/Delete Attributes would be oblivious to the "contributing attributes" -- those part of the immutable value of the template. This would let you manage the templates themselves with attributes such as Object Group, Contact Information, etc., and the only way you could view the contribution of a template is to Get the template and see what was returned. I'm not sure which is easier to explain to end users -- the difference between "all of the attributes of the template" or the difference is "how Get/Delete/Modify Attribute work against a template", i.e. how I understood the spec (and implemented it) vs. how you are describing it. I am lazily in favor of the former vs. the latter, simply to avoid the work involved in changing my implementation, which is not to say that I disagree with your description. Jim Flood On 9/4/2012 2:45 PM, Tim Hudson wrote: On 5/09/2012 6:37 AM, Jim Flood wrote: * SHALL the Name attribute of the Template be passed in the Template Attribute of the Register Request Payload, rather than the Template itself? My view is that the Name should be passed in the Template Attribute in Attribute format. However there is a use case (test case) which does this differently - something which I think should be fixed. * SHALL the attributes of the Template that contribute to created objects (later, in subsequent operations) be passed in the Template object of the Register's Request Payload, OR, can they also be specified in the Template Attribute? (I prefer the latter to be consistent with Create.) My view is that the first is the logical option. Attributes contributed to other objects must be specified in the Template structure. However the specification allows for the usual inheritance from other templates and from the template attribute list - but those I think can reasonably be interpreted as applying the the template object and not to contributing to the 'value' of the template. That interpretation I do not think is precluded by the specification. Consistency with Create would argue that anything specified in Register for attributes are attributes of the object itself and not the value - i.e. those items in TemplateAttribute are for the template itself and only those items in the Template structure apply to created objects. I keep coming back to " None of the client-settable attributes specified in a Template except the Name attribute apply to the template object itself, but instead apply to any object created using the Template. " That to me always made it clear the attributes being contributed to objects came in the Template structure. Mixing up the other attributes which apply to the template object leads to all manner of confusion. Tim.