kmip-interop-tech — archive

Tomorrow's Call

From: Jim Flood <[email protected]>
To: [email protected]
Date: Wed, 16 May 2012 23:05:00 -0000

I have a related question on transitive attributes : A key can be created with a Template Attribute that specifies multiple templates, as well as individual attributes, and can include implicitly-added attributes (according to server policy.) A Re-Key can also specify template and attributes, and also includes any carry-over attributes from the source key managed object. Of these transitive attributes, as I interpret the spec, the last single-instance attribute found in the resolution of the request payload (i.e. after searching all templates and then looking at all individual attributes in the Template Attribute), is the one used. For example, if one or more templates include Contact Information, and then the Template Attribute includes one or more Contact Information attributes, since this is a single-instance attribute, the very last one found in the request payload is the one used in the new object. This has precedence over carry-over attributes from a source object on a Re-Key, too. Of these attributes which are multiple-instance, all instances of the attributes collect and they are *all* added to the created object. If several templates each have a particular multiple-instance custom attribute x-Something , for example, and multiple x-Something attributes are also included in the request Template Attribute, and the source of a Re-Key has one or more x-Something attributes, then the resulting new object will have all of those added to it. That is, for single-instance attributes that are transitive, the last one found in the request payload (which includes templates first, and next, immediate attributes) is the one given to the new object, and any previous ones are ignored, without error. For multiple-instance attributes, all of the attributes in the request payload and in the source object, if any, are included in the new object. I guess this is not an interpretation of the spec as written, but more how I imagine how it should be, if the spec described this in detail. Is this a reasonable assumption for how the server should operate? Regards, Jim Flood On 5/16/2012 4:07 AM, Bruce Rich wrote: 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]