kmip-interop-tech — archive

Tomorrow's Call

From: Bruce Rich <[email protected]>
To: [email protected]
Date: Wed, 16 May 2012 11:09:00 -0000

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 <[email protected]> To: [email protected] Date: 05/03/2012 09:00 AM Subject: [kmip-interop-tech] Templates Sent by: <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]