OASIS Key Management Interoperability Protocol (KMIP) TC

Hello Trinath,

Please see below for my responses to your questions.

Regards,
Mathias


Somanchi Trinath-B22327 <B22327@freescale.com>
wrote on 05.10.2010 06:12:52:

>
> [1] With respect to your comment “It's a decision
in the

> specification to use the straight TTLV encoding for parameters that

> are explicitly specified (whether they are attributes, base objects,

> or enumerations), as opposed to using the heavier attribute name/

> index/value structure used only in the cases I mention above. “ Why

> can’t Locate operation request have light structure like in Get

> operation? Why Get operation itself should have light weight structures.
>

If we had the same light structure in Locate as in
Get, we would have to
use different representation for Custom attributes
and other attributes
(since normal attributes could be identified by a
tag, whereas Custom
attributes can only be identified by the text string
name). We felt it
was a better design to treat all attributes in the
same way, rather than
going for smaller message size by treating custom
attributes differently.
In Get it makes sense to have the light structure,
since only a specific
subset of parameters can be passed in the request.


> [2] In the Use case document, in the starting
sections a Template

> was created and using the same a symmetric key is generated. But

> while using the template in Symmetric key creation, NAME of the

> Template is mentions in Simple NAME structure. Can UUID be also be

> used in place of NAME to identify the template to be used while

> creating the symmetric key. 
>  
> Now the template is identified by its NAME this
way,
>  
> From Use case Doc, section  3.1.2
> Tag: Template-Attribute (0x420091), Type: Structure
(0x01), Data:
>         Tag: Name (0x420053),
Type: Structure (0x01), Data:
>           Tag: Name
Value (0x420055), Type: Text String (0x07),

> Data: Template1
>           Tag: Name
Type (0x420054), Type: Enumeration (0x05), Data:

> 0x00000001 (Uninterpreted text string)
>  
> So when giving UUID of the Template object, can
UUID be given this way,
>  
> Tag: Template-Attribute (0x420091), Type: Structure
(0x01), Data:
> Tag: Unique Identifier (0x420094), Type: Text
String (0x07), Data:

> fc8833de-70d2-4ece-b063-fede3a3c59fe
>

When referring to Templates in Register, Create, Create
Key-pair etc.,
it is only possible to identify the Template by name,
not by UUID.
This was a conscious design decision. This is because
we wanted the
Template reference to be human-interpretable and rememberable.

Please see Section 3.6 in the Usage Guide for more
information on
how to use Templates.


> [3] What is the use of Criticality Indicator?
In the Use case

> document I see two use cases for showcasing this attribute. 
> In the first use case, it is set to false, symmetric
key is created,

> since the server did not understand the extension, and criticality

> indicator is set to false, the server created the symmetric key.
> In the second use case, criticality indicator
is set to true, server

> did not understand the extension and identified criticality

> indicator is set to true, and returned error, symmetric key is not
created. 
> Sine in both the cases the new extension is not
understood by the

> server. How this criticality indicator is used?
>

The criticality indicator is defined in Section 6.16
of the KMIP
specification. It indicates the criticality of the
vendor-specific batch
item extension. If it is only "nice-to-know"
information, then the
client can set the criticality indicator to false,
thus allowing
a server that does not understand the batch item extension
to ignore it
and process the rest of the batch item normally. If,
however, the batch
item extension contains critical information that
substantially changes
the meaning of the request or the normal parameters
passed in the request
payload, then the client sets the criticality indicator
to true. In this
case, if the server does not understand the batch
item extension, it has
to fail the request.

Hi Mathias,



Thank you for the reply..



Please see below for my responses ..



Trinath Somanchi,

trinath.somanchi@freescale.com





From: Mathias
Bjoerkqvist1 [mailto:MBJ@zurich.ibm.com]

Sent: Tuesday, October 05, 2010 2:20 PM

To: Somanchi Trinath-B22327

Cc: kmip@lists.oasis-open.org

Subject: Re: FW: [kmip] KMIP :: Doubts







Hello Trinath,


Please see below for my responses to your
questions.


Regards,

Mathias



Somanchi Trinath-B22327
<B22327@freescale.com> wrote on 05.10.2010 06:12:52:

>

> [1] With respect to your comment
“It's a decision in the 

> specification to use the straight TTLV encoding for parameters that 

> are explicitly specified (whether they are attributes, base objects,

> or enumerations), as opposed to using the heavier attribute name/

> index/value structure used only in the cases I mention above. “
Why 

> can’t Locate operation request have light structure like in Get 

> operation? Why Get operation itself should have light weight
structures.

>


If we had the same light structure in Locate
as in Get, we would have to

use different representation for Custom
attributes and other attributes

(since normal attributes could be identified
by a tag, whereas Custom

attributes can only be identified by the
text string name). We felt it

was a better design to treat all attributes
in the same way, rather than

going for smaller message size by treating
custom attributes differently.

In Get it makes sense to have the light
structure, since only a specific

subset of parameters can be passed in the
request. 



[B22327] But then in GET operation If I want to get a key using
some custom attribute which the user thinks is the unique one. How we go about
it?





> [2] In the Use case document, in the
starting sections a Template 

> was created and using the same a symmetric key is generated. But 

> while using the template in Symmetric key creation, NAME of the 

> Template is mentions in Simple NAME structure. Can UUID be also be 

> used in place of NAME to identify the template to be used while 

> creating the symmetric key. 

>  

> Now the template is identified by its
NAME this way,

>  

> From Use case Doc, section  3.1.2

> Tag: Template-Attribute (0x420091),
Type: Structure (0x01), Data:

>         Tag: Name
(0x420053), Type: Structure (0x01), Data:

>           Tag:
Name Value (0x420055), Type: Text String (0x07), 

> Data: Template1

>           Tag:
Name Type (0x420054), Type: Enumeration (0x05), Data:

> 0x00000001 (Uninterpreted text string)

>  

> So when giving UUID of the Template
object, can UUID be given this way,

>  

> Tag: Template-Attribute (0x420091),
Type: Structure (0x01), Data:

> Tag: Unique Identifier (0x420094),
Type: Text String (0x07), Data: 

> fc8833de-70d2-4ece-b063-fede3a3c59fe

>


When referring to Templates in Register,
Create, Create Key-pair etc.,

it is only possible to identify the Template
by name, not by UUID.

This was a conscious design decision. This
is because we wanted the

Template reference to be human-interpretable
and rememberable.




[B22327] okay.. then is it okay to send UUID if needed or MUST
follow this way



Please see Section 3.6 in the Usage Guide
for more information on

how to use Templates.



> [3] What is the use of Criticality
Indicator? In the Use case 

> document I see two use cases for showcasing this attribute. 

> In the first use case, it is set to
false, symmetric key is created,

> since the server did not understand the extension, and criticality 

> indicator is set to false, the server created the symmetric key.

> In the second use case, criticality
indicator is set to true, server

> did not understand the extension and identified criticality 

> indicator is set to true, and returned error, symmetric key is not
created. 

> Sine in both the cases the new
extension is not understood by the 

> server. How this criticality indicator is used?

>


The criticality indicator is defined in
Section 6.16 of the KMIP

specification. It indicates the criticality
of the vendor-specific batch

item extension. If it is only "nice-to-know"
information, then the

client can set the criticality indicator to
false, thus allowing

a server that does not understand the batch
item extension to ignore it

and process the rest of the batch item
normally. If, however, the batch

item extension contains critical information
that substantially changes

the meaning of the request or the normal
parameters passed in the request

payload, then the client sets the
criticality indicator to true. In this

case, if the server does not understand the
batch item extension, it has

to fail the request. 

[B22327] Any way in both the cases server doesn’t
understand the extension parameters right? Then what help does this provide. Is
the attribute used to stop throwing an error when such data is sent though
valid at user end. 

Hi Trinath,

Please see my responses below.

Regards,
Mathias


> > [1] With respect to your comment “It's
a decision in the

> > specification to use the straight TTLV encoding for parameters
that

> > are explicitly specified (whether they are attributes, base objects,

> > or enumerations), as opposed to using the heavier attribute name/

> > index/value structure used only in the cases I mention above.
“ Why

> > can’t Locate operation request have light structure like in
Get

> > operation? Why Get operation itself should have light weight
structures.

> >

>

> If we had the same light structure in Locate as in Get, we would have
to

> use different representation for Custom attributes and other attributes

> (since normal attributes could be identified by a tag, whereas Custom

> attributes can only be identified by the text string name). We felt
it

> was a better design to treat all attributes in the same way, rather
than

> going for smaller message size by treating custom attributes differently.

> In Get it makes sense to have the light structure, since only a specific

> subset of parameters can be passed in the request. 
>  
> [B22327] But then in GET operation If I want
to get a key using some

> custom attribute which the user thinks is the unique one. How we go
about it?
> 

You would perform a Locate with the custom attribute,
which will return
zero or more UUIDs. Custom attributes are not guaranteed
to be unique,
which is why more than one UUID may be returned in
the Locate response.
You can thereafter do a Get operation to get the key(s)
identified by
the returned UUID(s).



>

> > [2] In the Use case document, in the starting sections a Template

> > was created and using the same a symmetric key is generated.
But

> > while using the template in Symmetric key creation, NAME of the

> > Template is mentions in Simple NAME structure. Can UUID be also
be

> > used in place of NAME to identify the template to be used while

> > creating the symmetric key.

> >  

> > Now the template is identified by its NAME this way,

> >  

> > From Use case Doc, section  3.1.2

> > Tag: Template-Attribute (0x420091), Type: Structure (0x01), Data:

> >         Tag: Name (0x420053), Type: Structure
(0x01), Data:

> >           Tag: Name Value (0x420055),
Type: Text String (0x07),

> > Data: Template1

> >           Tag: Name Type (0x420054),
Type: Enumeration (0x05), Data:

> > 0x00000001 (Uninterpreted text string)

> >  

> > So when giving UUID of the Template object, can UUID be given
this way,

> >  

> > Tag: Template-Attribute (0x420091), Type: Structure (0x01), Data:

> > Tag: Unique Identifier (0x420094), Type: Text String (0x07),
Data:

> > fc8833de-70d2-4ece-b063-fede3a3c59fe

> >

>

> When referring to Templates in Register, Create, Create Key-pair etc.,

> it is only possible to identify the Template by name, not by UUID.

> This was a conscious design decision. This is because we wanted the

> Template reference to be human-interpretable and rememberable.


> [B22327] okay.. then is it okay to send UUID
if needed or MUST follow this way
> 

It is not okay to send UUID. You can obtain the Name(s)
for the Template
with a given UUID using Get Attribute, and then use
this Name to refer to
the Template in Register, Create etc. operations.



> Please see Section 3.6 in the Usage Guide for more information on

> how to use Templates.

>

>

> > [3] What is the use of Criticality Indicator? In the Use case

> > document I see two use cases for showcasing this attribute.

> > In the first use case, it is set to false, symmetric key is created,

> > since the server did not understand the extension, and criticality

> > indicator is set to false, the server created the symmetric key.

> > In the second use case, criticality indicator is set to true,
server

> > did not understand the extension and identified criticality

> > indicator is set to true, and returned error, symmetric key is
notcreated.

> > Sine in both the cases the new extension is not understood by
the

> > server. How this criticality indicator is used?

> >

>

> The criticality indicator is defined in Section 6.16 of the KMIP

> specification. It indicates the criticality of the vendor-specific
batch

> item extension. If it is only "nice-to-know" information,
then the

> client can set the criticality indicator to false, thus allowing

> a server that does not understand the batch item extension to ignore
it

> and process the rest of the batch item normally. If, however, the
batch

> item extension contains critical information that substantially changes

> the meaning of the request or the normal parameters passed in the
request

> payload, then the client sets the criticality indicator to true. In
this

> case, if the server does not understand the batch item extension,
it has

> to fail the request. 
> [B22327] Any way in both the cases server doesn’t
understand the

> extension parameters right? Then what help does this provide. Is the

> attribute used to stop throwing an error when such data is sent

> though valid at user end. 

If the client doesn't care one way or the other, it
can set the criticality
indicator to false. Like you said, it can be used
to stop throwing an error
when the server does not understand the extension,
but it is valid at the
user end.

Hi,



Thank you for the reply.. 



I have doubt at this point.



“ It is not okay to
send UUID. You can obtain the Name(s) for the Template

with a given UUID using Get Attribute, and
then use this Name to refer to

the Template in Register, Create etc.
operations.”



Since name attribute has instances too, then a template can have
multiple names.. and same names get repeated for other templates cn be a
possibility. In that case UUID of template will be a helpful one. 





Trinath Somanchi,

trinath.somanchi@freescale.com





From: Mathias
Bjoerkqvist1 [mailto:MBJ@zurich.ibm.com]

Sent: Tuesday, October 05, 2010 3:08 PM

To: Somanchi Trinath-B22327

Cc: kmip@lists.oasis-open.org

Subject: RE: FW: [kmip] KMIP :: Doubts







Hi Trinath,


Please see my responses below.


Regards,

Mathias



> > [1] With respect to your comment
“It's a decision in the 

> > specification to use the straight TTLV encoding for parameters
that 

> > are explicitly specified (whether they are attributes, base
objects,

> > or enumerations), as opposed to using the heavier attribute name/

> > index/value structure used only in the cases I mention above.
“ Why 

> > can’t Locate operation request have light structure like in
Get 

> > operation? Why Get operation itself should have light weight
structures. 

> > 

> 

> If we had the same light structure in Locate as in Get, we would have
to 

> use different representation for Custom attributes and other
attributes 

> (since normal attributes could be identified by a tag, whereas Custom 

> attributes can only be identified by the text string name). We felt it


> was a better design to treat all attributes in the same way, rather
than 

> going for smaller message size by treating custom attributes
differently. 

> In Get it makes sense to have the light structure, since only a
specific 

> subset of parameters can be passed in the request. 

>  

> [B22327] But then in GET operation If I
want to get a key using some

> custom attribute which the user thinks is the unique one. How we go
about it?

> 


You would perform a Locate with the custom
attribute, which will return

zero or more UUIDs. Custom attributes are
not guaranteed to be unique,

which is why more than one UUID may be
returned in the Locate response.

You can thereafter do a Get operation to get
the key(s) identified by

the returned UUID(s).





> 

> > [2] In the Use case document, in the starting sections a Template


> > was created and using the same a symmetric key is generated. But 

> > while using the template in Symmetric key creation, NAME of the 

> > Template is mentions in Simple NAME structure. Can UUID be also
be 

> > used in place of NAME to identify the template to be used while 

> > creating the symmetric key. 

> >   

> > Now the template is identified by its NAME this way, 

> >   

> > From Use case Doc, section  3.1.2 

> > Tag: Template-Attribute (0x420091), Type: Structure (0x01), Data:


> >         Tag: Name (0x420053), Type: Structure
(0x01), Data: 

> >           Tag: Name Value (0x420055),
Type: Text String (0x07), 

> > Data: Template1 

> >           Tag: Name Type (0x420054),
Type: Enumeration (0x05), Data:

> > 0x00000001 (Uninterpreted text string) 

> >   

> > So when giving UUID of the Template object, can UUID be given
this way, 

> >   

> > Tag: Template-Attribute (0x420091), Type: Structure (0x01), Data:


> > Tag: Unique Identifier (0x420094), Type: Text String (0x07),
Data: 

> > fc8833de-70d2-4ece-b063-fede3a3c59fe 

> > 

> 

> When referring to Templates in Register, Create, Create Key-pair etc.,


> it is only possible to identify the Template by name, not by UUID. 

> This was a conscious design decision. This is because we wanted the 

> Template reference to be human-interpretable and rememberable. 



> [B22327] okay.. then is it okay to send
UUID if needed or MUST follow this way

> 


It is not okay to send UUID. You can obtain
the Name(s) for the Template

with a given UUID using Get Attribute, and
then use this Name to refer to

the Template in Register, Create etc.
operations.




> Please see Section 3.6 in the Usage Guide for more information on 

> how to use Templates. 

> 

> 

> > [3] What is the use of Criticality Indicator? In the Use case 

> > document I see two use cases for showcasing this attribute. 

> > In the first use case, it is set to false, symmetric key is
created,

> > since the server did not understand the extension, and
criticality 

> > indicator is set to false, the server created the symmetric key. 

> > In the second use case, criticality indicator is set to true,
server

> > did not understand the extension and identified criticality 

> > indicator is set to true, and returned error, symmetric key is
notcreated. 

> > Sine in both the cases the new extension is not understood by the


> > server. How this criticality indicator is used? 

> > 

> 

> The criticality indicator is defined in Section 6.16 of the KMIP 

> specification. It indicates the criticality of the vendor-specific
batch 

> item extension. If it is only "nice-to-know" information,
then the 

> client can set the criticality indicator to false, thus allowing 

> a server that does not understand the batch item extension to ignore
it 

> and process the rest of the batch item normally. If, however, the
batch 

> item extension contains critical information that substantially
changes 

> the meaning of the request or the normal parameters passed in the
request 

> payload, then the client sets the criticality indicator to true. In
this 

> case, if the server does not understand the batch item extension, it
has 

> to fail the request. 

> [B22327] Any way in both the cases
server doesn’t understand the 

> extension parameters right? Then what help does this provide. Is the

> attribute used to stop throwing an error when such data is sent 

> though valid at user end. 


If the client doesn't care one way or the
other, it can set the criticality

indicator to false. Like you said, it can be
used to stop throwing an error

when the server does not understand the
extension, but it is valid at the

user end. 

Hi Trinath,

>  
> I have doubt at this point.
>  
> “ It is not okay to send UUID. You can obtain
the Name(s) for the Template

> with a given UUID using Get Attribute, and then use this Name to refer
to

> the Template in Register, Create etc. operations.”
>  
> Since name attribute has instances too, then
a template can have

> multiple names.. and same names get repeated for other templates cn

> be a possibility. In that case UUID of template will be a helpful
one. 
>  

Templates can indeed have multiple instances of the
Name attribute. You
can use to any of these Names when referring to the
Template in Create,
Register etc. operations. However, since Names are
required to be unique
within a key management domain (see Section 3.2 in
the spec), a conflict
between two Templates (i.e., two Templates having
the same Name(s)) is
not possible.


Regards,
Mathias

Hi-



I have a doubt with GET ATTRIBUTES operation. Please help me
understand the same.



Will GET ATTRIBUTES operation returns NAME attribute when
queried? I have checked with IBM, HP and Cryptsoft servers, all are not
returning NAME attribute though request specifies NAME attribute in it.



Thanking You.



Trinath Somanchi,

trinath.somanchi@freescale.com





From: Mathias
Bjoerkqvist1 [mailto:MBJ@zurich.ibm.com]

Sent: Tuesday, October 05, 2010 5:05 PM

To: Somanchi Trinath-B22327

Cc: kmip@lists.oasis-open.org

Subject: RE: FW: [kmip] KMIP :: Doubts







Hi Trinath,


>  

> I have doubt at this point.

>  

> “ It is not okay to send UUID.
You can obtain the Name(s) for the Template 

> with a given UUID using Get Attribute, and then use this Name to refer
to 

> the Template in Register, Create etc. operations.”

>  

> Since name attribute has instances too,
then a template can have 

> multiple names.. and same names get repeated for other templates cn 

> be a possibility. In that case UUID of template will be a helpful one.


>  


Templates can indeed have multiple instances
of the Name attribute. You

can use to any of these Names when referring
to the Template in Create,

Register etc. operations. However, since
Names are required to be unique

within a key management domain (see Section
3.2 in the spec), a conflict

between two Templates (i.e., two Templates
having the same Name(s)) is

not possible.



Regards,

Mathias

Hi Trinath,

Somanchi Trinath-B22327 <B22327@freescale.com>
wrote on 08.10.2010 09:31:53:

>  
> Will GET ATTRIBUTES operation returns NAME attribute
when queried? I

> have checked with IBM, HP and Cryptsoft servers, all are not

> returning NAME attribute though request specifies NAME attribute in
it.
>  

Yes, the Get Attributes operation returns the Name
attribute when queried.

I could not find any Get Attributes requests from
you in our server log.
However, retrieving the Name attribute is tested in
Use Case 3.1.4 which
should be supported by all server implementers. If
you are having some
issues with a specific implementer's server, it is
best to contact them
directly. It would also be helpful if you could send
the TTLV message
exchange related to any error.


Regards,
Mathias