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