Tim,
I am in sympathy with the goal of getting on the same page regarding the behavior of GET. The spec is now overly terse regarding GET behavior for all objects, and is generally silent about how operations on TEMPLATEs behave.
The original intent of GET was that it would retrieve the body of a cryptographic object. So for SYMMETRIC_KEY, it would mean the key material. But TEMPLATE is not a cryptographic object, it's just a managed object. What would it mean to retrieve its "body"? It doesn't have one, at least not in the sense that cryptographic objects do. And I think that's where the confusion arises. Perhaps it would be useful to introduce the idea of TRANSITIVE ATTRIBUTEs to the discussion. A TRANSITIVE ATTRIBUTE would be one that transfers from a TEMPLATE to the objects to which the TEMPLATE is applied. I think this discussion is heading in the direction of a behavior of "GET on a TEMPLATE SHOULD return only the TRANSITIVE ATTRIBUTEs contained in that ATTRIBUTE." Or something like that. And I'm in favor of such a clarification.
If we are going to head in that direction, we would be amiss if we did not also clarify what is returned from some additional operations on TEMPLATEs. I'm thinking of operations like GET ATTRIBUTE LIST and GET ATTRIBUTES (with no attribute names specified). If we go with the above proposal on GET, I think GET ATTRIBUTE LIST should return the names of ALL attributes associated with the TEMPLATE (both TRANSITIVE and INTRANSITIVE), and that GET ATTRIBUTES(no names) should similarly return ALL attributes associated with the TEMPLATE (both TRANSITIVE and INTRANSITIVE).
As an example, the list of INTRANSITIVE attributes would include things like the NAME of the TEMPLATE and its INITIAL DATE. The list of TRANSITIVE attributes would include things like CRYPTOGRAPHIC ALGORITHM and CRYPTOGRAPHIC LENGTH.
I can flesh this out a bit more, if this meets with general agreement.
Bruce A Rich brich at-sign us dot ibm dot com
From: Tim Hudson <>
To:
Date: 05/03/2012 09:00 AM
Subject: [kmip-interop-tech] Templates
Sent by: <>
What is the "value" of a Template - i.e. what is returned for a GET on a template.
For the following example - register of a template:
OBJECT_TYPE:enum:0x00000006:TEMPLATE TEMPLATE_ATTRIBUTE:stru:4 END_STRUCTURE:stru:4 TEMPLATE:stru:4
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Cryptographic Algorithm
ATTRIBUTE_VALUE:enum:0x00000003
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Cryptographic Length
ATTRIBUTE_VALUE:int4:0x00000100
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Cryptographic Usage Mask
ATTRIBUTE_VALUE:int4:0x0000000c
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Name
ATTRIBUTE_VALUE:stru:6
NAME_VALUE:text:Template1
NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING
END_STRUCTURE:stru:6
END_STRUCTURE:stru:5 END_STRUCTURE:stru:4
This is what I think is "correct" - call this VENDOR-A:
TEMPLATE:stru:4
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Cryptographic Algorithm
ATTRIBUTE_VALUE:enum:0x00000003:AES
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Cryptographic Length
ATTRIBUTE_VALUE:int4:0x00000100
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Cryptographic Usage Mask
ATTRIBUTE_VALUE:int4:0x0000000c:DECRYPT ENCRYPT
END_STRUCTURE:stru:5
END_STRUCTURE:stru:4
Here is an example of something I consider not correct - call this VENDOR-B:
TEMPLATE:stru:4
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Cryptographic Algorithm
ATTRIBUTE_VALUE:enum:0x00000003:AES
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Cryptographic Length
ATTRIBUTE_VALUE:int4:0x00000100
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Cryptographic Usage Mask
ATTRIBUTE_VALUE:int4:0x0000000c:DECRYPT ENCRYPT
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Object Type
ATTRIBUTE_VALUE:enum:0x00000006:TEMPLATE
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Name
ATTRIBUTE_VALUE:stru:6
NAME_VALUE:text:Template1
NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING
END_STRUCTURE:stru:6
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Unique Identifier
ATTRIBUTE_VALUE:text:e176df8d-16de-4bed-8031-0ef7932f8740
END_STRUCTURE:stru:5
END_STRUCTURE:stru:4
Here is an example of something I consider not correct - call this VENDOR-C:
TEMPLATE:stru:4
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Object Type
ATTRIBUTE_VALUE:enum:0x00000006:TEMPLATE
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Cryptographic Algorithm
ATTRIBUTE_VALUE:enum:0x00000003:AES
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Cryptographic Length
ATTRIBUTE_VALUE:int4:0x00000100
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Name
ATTRIBUTE_INDEX:int4:0x00000000
ATTRIBUTE_VALUE:stru:6
NAME_VALUE:text:Template1
NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING
END_STRUCTURE:stru:6
END_STRUCTURE:stru:5
ATTRIBUTE:stru:5
ATTRIBUTE_NAME:text:Initial Date
ATTRIBUTE_VALUE:date:0x000000004f967840:Tue Apr 24 19:54:08 2012
END_STRUCTURE:stru:5
END_STRUCTURE:stru:4
There are other variations on the theme - but the general concept should be clear.
We can argue whether or not the Name belongs in the template - and my argument for that is rather simple - it isn't there for other objects - they are all attributes - and there is no way a template should be treated differently. The concept of the "value" of the template containing attributes other than those which form part of what the template contributes to objects created with reference to the template is (in my view at least) simply unsupportable.
Views?
Tim.
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
