Some context for the "KMIP templates" discussion

[Bruce Rich <brich@us.ibm.com>]

FYI.

Bruce A Rich
brich at-sign us dot ibm dot com

----- Forwarded by Bruce
Rich/Austin/IBM on 09/13/2012 10:03 AM -----

From:      
 Bruce Rich/Austin/IBM@IBMUS
To:      
 kmip-interop-tech@lists.oasis-open.org
Date:      
 08/29/2012 05:17 PM
Subject:    
   [kmip-interop-tech]
Re: KMIP templates
Sent by:    
   <kmip-interop-tech@lists.oasis-open.org>

---

OK, I'll interpret "no response"
as "please go on".  Here goes. 

In addition to the material in my original note, I would add that since
a Template was defined as a Managed Object, then it inherits all other
behaviors mandated for the spec for objects of that type, so we are incorporating
those sections by reference... 

Now on to a proposal 

It would seem that since a Template is a Managed Object and NOT a Cryptographic
Object, we need to correct the Response Payload for GET in section 4.11
to say that it returns a Managed Object,, not a Cryptographic Object.  (Cryptographic
Objects are Managed Objects, but the converse is not true.)

Additionally, we would need to add a clause to either Section 2.2.6 or
to 4.11, that says: 

A GET of a Template SHALL return only the attributes "applicable to
objects created using the Template" in section 2.2.6.

If the above text were to be added to section 2.2.6, then we would not
need the self-reference, but in any case, it would be helpful to have a
link to the exact part of section 2.2.6 where the attributes are enumerated.
 I would prefer not to have multiple copies of the list to keep in
synch. 

And this would become testable in the next version of the KMIP spec.

Bruce A Rich
brich at-sign us dot ibm dot com

----- Forwarded by Bruce Rich/Austin/IBM on 08/29/2012 03:56 PM -----

From:        Bruce
Rich/Austin/IBM@IBMUS 
To:        kmip-interop-tech@lists.oasis-open.org
Date:        08/16/2012
11:12 AM 
Subject:        [kmip-interop-tech]
Fw: KMIP templates 
Sent by:        <kmip-interop-tech@lists.oasis-open.org>

---

There has been some discussion of the KMIP TEMPLATE managed object of late.
 In particular, a GET of a TEMPLATE is so underspecified that it will
likely lead to different results in all 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.

So here are what seem to be the most relevant sections.  These are
directly from the 1.1 spec.  Where I've added introductory text, I've
prefaced it with "BAR - ".  Please speak up if I've omitted
something pertinent 

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

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

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

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

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

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