Some context for the "KMIP templates" discussion

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:      
 

Date:      
 08/29/2012 05:17 PM

Subject:    
   [kmip-interop-tech]
Re: KMIP templates

Sent by:    
   <>

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:        

Date:        08/16/2012
11:12 AM 

Subject:        [kmip-interop-tech]
Fw: KMIP templates 

Sent by:        <>

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