kmip-interop-tech — archive

[Jim Flood]

I can see the logic in having a set of attributes as immutable-template-value, distinct from the attributes of the template-as-a-managed-object, in the sense of having a consistent model where all values are immutable. In the abstract, it's a good argument. But it seems complicated to explain to end users of a key store who are concerned about storing and managing cryptographic keys, where the template is an administrative feature to make it easier to do that. It doesn't seem like it's the right audience to explain how template values are similar to key values, register value produces the get value, the model is consistent for all values, etc. I think the pool of attributes-all-being-equal is better, because it's simpler and easier to explain to people. It is a little confusing that some attributes contribute on a Create, and some, like Initial Date, do not. But I would argue that it is less confusing, and a little mixing up of the nature of attributes is acceptable to the user because templates are this kind of administrative feature, obviously a different animal from a cryptographic object. So from the point of view of describing how people would actually use the key store, I think the pool of attributes explanation is much more simple than the immutable value explanation, and therefore is preferable. (I admit that I may be biased because this is how I have myself implemented templates -- as the pool of attributes, as Mathias wrote.) It's true that in this case, you cannot add a Contact Information, for example, to a template, but is that a necessary feature? And, if the template value had Contact Information, and the template-as-managed-object has Contact Information, wouldn't that lead to confusion for end users? I would prefer to keep it much simpler. Do templates need to be "first class attributed objects"? Jim Flood