OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi Trinath,

Please see my responses below.


> > [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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]