kmip-interop-tech — archive

[Bruce Rich]

The usage of Templates in KMIP seems underspecified in even the most recent release, 1.1.  In particular, a GET of a TEMPLATE is so underspecified that it will likely lead to different results in all/most/some of the current implementations.  With the goal of reducing that unpredictability, let's review the current spec, with an eye to specification of the proper usage in KMIP.  This first note will just serve to attempt to include all of the relevant sections.  Once we have agreement on that, we can proceed.  Is this good enough to start with?  And is it adequate to confine the discussion to this list for now? Section 2.2.6 A Template is a named Managed Object containing the client-settable attributes of a Managed Cryptographic Object (i.e., a stored, named list of attributes). A Template is used to specify the attributes of a new Managed Cryptographic Object in various operations. It is intended to be used to specify the cryptographic attributes of new objects in a standardized or convenient way. 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. The Template MAY be the subject of the Register, Locate, Get, Get Attributes, Get Attribute List, Add Attribute, Modify Attribute, Delete Attribute, and Destroy operations. An attribute specified in a Template is applicable either to the Template itself or to objects created using the Template. Attributes applicable to the Template itself are: Unique Identifier, Object Type, Name, Initial Date, Archive Date, and Last Change Date. Attributes applicable to objects created using the Template are: ·         Cryptographic Algorithm ·         Cryptographic Length ·         Cryptographic Domain Parameters ·         Cryptographic Parameters ·         Certificate Length ·         Operation Policy Name ·         Cryptographic Usage Mask ·         Digital Signature Algorithm ·         Usage Limits ·         Activation Date ·         Process Start Date ·         Protect Stop Date ·         Deactivation Date ·         Object Group ·         Application Specific Information ·         Contact Information ·         Custom Attribute Object Encoding REQUIRED Template Structure Attribute Attribute Object, see 2.1.1 Yes. MAY be repeated. Table 33: Template Object Structure If we then drop down to Section 4, lines 1069-1076, we see how all objects (including Templates) are handled, both on CREATE* calls and REGISTER: Requests MAY contain attribute values to be assigned to the object. This information is specified with a Template-Attribute (see Section 2.1.8) that contains zero or more template names and zero or more individual attributes. If more than one template name is specified, and there is a conflict between the single-instance attributes in the templates, then the value in the last of the conflicting templates takes precedence. If there is a conflict between the single-instance attributes in the request and the single-instance attributes in a specified template, then the attribute values in the request take precedence. For multi-instance attributes, the union of attribute values is used when the attributes are specified more than once. Apparently, this discussion in the overview of the operations sections is considered adequate, as little or nothing is really mentioned in the CREATE- or REGISTER-specific sections If we then go to section 4.11, the one for GET, all we see is: Response Payload Object REQUIRED Description Object Type, see 3.3 Yes Type of object. Unique Identifier, see 3.1 Yes The Unique Identifier of the object. Certificate, Symmetric Key, Private Key, Public Key, Split Key, Template, Secret Data, or Opaque Object, see 2.2 Yes The cryptographic object being returned. And Section 2.2 just has the layouts for the different objects, the one for TEMPLATE is section 2.2.6, which is how we started off this journey. But there are also a couple of out-lier sections that we should also pull in, those that talk about PUBLIC TEMPLATES and PRIVATE TEMPLATES, both from the area where the default operation policy is discussed: 3.18.2.3 Default Operation Policy for Template Objects The operation policy specified as an attribute in the Register operation for a template object is the operation policy used for objects created using that template, and is not the policy used to control operations on the template itself. There is no mechanism to specify a policy used to control operations on template objects, so the default policy for template objects is always used for templates created by clients using the Register operation to create template objects. Default Operation Policy for Private Template Objects Operation Policy Locate Allowed to creator only Get Allowed to creator only Get Attributes Allowed to creator only Get Attribute List Allowed to creator only Add Attribute Allowed to creator only Modify Attribute Allowed to creator only Delete Attribute Allowed to creator only Destroy Allowed to creator only Any operation referencing the Template using a Template-Attribute Allowed to creator only Table 76: Default Operation Policy for Private Template Objects In addition to private template objects (which are controlled by the above policy, and which MAY be created by clients or the server), publicly known and usable templates MAY be created and managed by the server, with a default policy different from private template objects. Default Operation Policy for Public Template Objects Operation Policy Locate Allowed to all Get Allowed to all Get Attributes Allowed to all Get Attribute List Allowed to all Add Attribute Disallowed to all Modify Attribute Disallowed to all Delete Attribute Disallowed to all Destroy Disallowed to all Any operation referencing the Template using a Template-Attribute Allowed to all Table 77: Default Operation Policy for Public Template Objects Bruce A Rich brich at-sign us dot ibm dot com