OASIS Key Management Interoperability Protocol (KMIP) TC

  • 1.  RE: [kmip] KMIP :: Doubts

    Posted 09-29-2010 16:42

    Some issue with my mail client, So resending this mail again, Ignore if already received this email

    Thank you


    Hi Robert,

    Thank you for the reply.

    My 3rd doubt is still not cleared. Use case 3.1.3 from the use case document uses UUID in locate request. I think I was not clear in expressing my doubt.

    Here is my Doubt:

    In Use case 3.1.3, Locate request, UUID is given in the request payload in an Attribute Structure as:

     Tag: Attribute (0x420008), Type: Structure (0x01), Data:
            Tag: Attribute Name (0x42000A), Type: Text String (0x07), Data: Unique Identifier
            Tag: Attribute Value (0x42000B), Type: Text String (0x07), Data: 1ed28ea5-2b31-4145-bcf2-36d0756d3890

    But in GET operation request, UUID is given in Unique identifier Tag. Like,

    Tag: Unique Identifier (0x420094), Type: Text String (0x07), Data: 1ed28ea5-2b31-4145-bcf2-36d0756d3890

    My doubt is that, why two types exists for UUID specification?

    I mean why can't UUID specified in Attribute structure (present in locate) be used in GET operation request also?

    Is there any specific reason behind the framing of request in this way?

    Please help me understand this.


    Best Regards,
    --------------------
    Trinath Somanchi.
    email : trinath.somanchi@gmail.com
    Mobile: +91 9866 235 130






  • 2.  RE: [kmip] KMIP :: Doubts

    Posted 09-29-2010 18:58

    Hi Trinath, please see below.
    Regards,
    -Robert

    Somanchi Trinath-B22327 <B22327@freescale.com> wrote on 09/29/2010 06:39:50 PM:
    >
    > RE: [kmip] KMIP :: Doubts

    >
    > Somanchi Trinath-B22327

    >
    > to:

    >
    > Robert Haas

    >
    > 09/29/2010 06:43 PM

    >
    > Cc:

    >
    > kmip

    >
    > Some issue with my mail client, So resending this mail again, Ignore
    > if already received this email
    >
    > Thank you
    >
    >
    > Hi Robert,
    >
    > Thank you for the reply.
    >
    > My 3rd doubt is still not cleared. Use case 3.1.3 from the use case
    > document uses UUID in locate request. I think I was not clear in
    > expressing my doubt.
    >
    > Here is my Doubt:
    >
    > In Use case 3.1.3, Locate request, UUID is given in the request
    > payload in an Attribute Structure as:
    >
    >  Tag: Attribute (0x420008), Type: Structure (0x01), Data:
    >         Tag: Attribute Name (0x42000A), Type: Text String (0x07),
    > Data: Unique Identifier
    >         Tag: Attribute Value (0x42000B), Type: Text String (0x07),
    > Data: 1ed28ea5-2b31-4145-bcf2-36d0756d3890
    >
    > But in GET operation request, UUID is given in Unique identifier Tag. Like,
    >
    > Tag: Unique Identifier (0x420094), Type: Text String (0x07), Data:
    > 1ed28ea5-2b31-4145-bcf2-36d0756d3890
    >
    > My doubt is that, why two types exists for UUID specification?


    Thanks for helping me understand your question better.

    Parameters to operations can be base objects (defined in section 2), parameters that correspond to attributes (defined in section 3), enumerations (defined in sections 9.1.3.2.*), or objects that are defined in the operation itself.

    In addition to these parameters that must be listed explicitly in each operation request or response specification, a small set of operations allow to pass parameters that are NOT explicitly listed one by one. This is the case for Locate, Notify, Put, Get Attributes, Add/Modify/Delete Attribute. This is done with an attribute structure with name/index/value, that allows to pass multiple instances if needed.

    In the example you raised, Unique Identifier is not treated differently than other such attribute parameters passed to Locate for matching purposes.

    >
    > I mean why can't UUID specified in Attribute structure (present in
    > locate) be used in GET operation request also?


    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.

    >
    > Is there any specific reason behind the framing of request in this way?
    >
    > Please help me understand this.
    >
    >
    > Best Regards,
    > --------------------
    > Trinath Somanchi.
    > email : trinath.somanchi@gmail.com
    > Mobile: +91 9866 235 130
    >
    >
    >
    >
    mailto:rha@zurich.ibm.com]
    > Sent: Wed 29-Sep-10 9:35 PM
    > To: Somanchi Trinath-B22327
    > Cc: kmip@lists.oasis-open.org
    > Subject: Re: [kmip] KMIP :: Doubts
    >
    >
    > Hi Trinath, please find answers to your questions below.
    > Regards,
    > -Robert
    >
    > Somanchi Trinath-B22327 <B22327@freescale.com> wrote on 09/28/2010
    > 06:52:31 AM:
    > >
    > > [kmip] KMIP :: Doubts
    > >
    > > Somanchi Trinath-B22327
    > >
    > > to:
    > >
    > > kmip
    > >
    > > 09/28/2010 06:54 AM
    > >
    > > Hi-
    > >  
    > > I have the following doubts regarding KMIP.  Please review and help
    > > me understand them.
    > >  
    > > Doubts:
    > >  
    > > [1] An SHA-256 hash is created by the KMIP server when a Symmetric
    > > Key is created. How to generate some other kind of Hash say,
    > > SHA-512? I mean do client need to send add attribute request with
    > > name value pairs of variables present in Digest structure or how
    > > this can be achieved?
    >
    > It is up to a server implementation to choose to have digests beyond
    > the mandatory one. The client cannot request this.
    >
    > >  
    > > [2] With respect to ADD attribute operation, the spec says, READ-
    > > ONLY attributes cannot be added using this operation. READ-ONLY
    > > attribute is defined as 'Attribute that shall not be modified by
    > > either server or client and that shall not be deleted by client'. My
    > > reading through spec document gave me the following NON-READ-ONLY
    > > attributes which can be used in ADD attribute operation. The listing
    > > is as follows:
    >
    > Digest should be removed from your list.
    >
    > > Name
    > > o   Name Value
    > > o   Name Type
    > > Cryptographic Parameters
    > > o   Block Cipher Mode
    > > o   Padding Method
    > > o   Hashing Algorithm
    > > o   Key Role Type
    > > Usage Limits
    > > o   Usage Limits Total
    > > o   Usage Limits Count
    > > o   Usage Limits Unit
    > > Object Group
    > > Link
    > > o   Link Type
    > > o   Linked Object Identifier
    > > Contact Information
    > > Custom Attribute
    > > Activation Date
    > > Process Start Date
    > > Protect Stop Date
    > > Deactivation Date
    > > Digest
    > > Operational Policy
    > > Application Specific Information
    > > o   Application Namespace
    > > o   Application Data
    > > Please comment if I missed any attribute.
    > >  
    > > [3] With respect to the Usage Guide, I'm comparing two requests.
    > > LOCATE and GET operation Requests.
    > >  
    > > In the LOCATE operation request, the UUID is placed in an ATTRIBUTE
    > > BLOCK which is common for all requests. like,
    > >  
    > > Locate
    > > In: uuidKey
    > >  
    > > Tag: Request Message (0x420078), Type: Structure (0x01), Data:
    > >   Tag: Request Header (0x420077), Type: Structure (0x01), Data:
    > >     Tag: Protocol Version (0x420069), Type: Structure (0x01), Data:
    > >       Tag: Protocol Version Major (0x42006A), Type: Integer (0x02),
    > > Data: 0x00000001 (1)
    > >       Tag: Protocol Version Minor (0x42006B), Type: Integer (0x02),
    > > Data: 0x00000000 (0)
    > >     Tag: Batch Count (0x42000D), Type: Integer (0x02), Data: 0x00000001 (1)
    > >   Tag: Batch Item (0x42000F), Type: Structure (0x01), Data:
    > >     Tag: Operation (0x42005C), Type: Enumeration (0x05), Data:
    > > 0x00000008 (Locate)
    > >     Tag: Request Payload (0x420079), Type: Structure (0x01), Data:
    > >       Tag: Attribute (0x420008), Type: Structure (0x01), Data:
    > >         Tag: Attribute Name (0x42000A), Type: Text String (0x07),
    > > Data: Unique Identifier
    > >         Tag: Attribute Value (0x42000B), Type: Text String (0x07),
    > > Data: 1ed28ea5-2b31-4145-bcf2-36d0756d3890
    > >  
    > > But in GET operation request, the UUID is not placed in the ATTRIBUTE block.
    > >  
    > >  
    > > Tag: Request Message (0x420078), Type: Structure (0x01), Data:
    > >   Tag: Request Header (0x420077), Type: Structure (0x01), Data:
    > >     Tag: Protocol Version (0x420069), Type: Structure (0x01), Data:
    > >       Tag: Protocol Version Major (0x42006A), Type: Integer (0x02),
    > > Data: 0x00000001 (1)
    > >       Tag: Protocol Version Minor (0x42006B), Type: Integer (0x02),
    > > Data: 0x00000000 (0)
    > >     Tag: Batch Count (0x42000D), Type: Integer (0x02), Data: 0x00000001 (1)
    > >   Tag: Batch Item (0x42000F), Type: Structure (0x01), Data:
    > >     Tag: Operation (0x42005C), Type: Enumeration (0x05), Data:
    > > 0x0000000A (Get)
    > >     Tag: Request Payload (0x420079), Type: Structure (0x01), Data:
    > >       Tag: Unique Identifier (0x420094), Type: Text String (0x07),
    > > Data: 1ed28ea5-2b31-4145-bcf2-36d0756d3890
    > >  
    > > Why this difference is maintained? Will this differentiation helps
    > > improving KMIP request/response? Please comment on this.
    >
    > Locate returns the Unique Identifier(s) of object(s) matching a
    > given search criteria. So you should not need to specify Unique
    > Identifier in a Locate operation request.
    >
    > >  
    > > [4] With respect to Use case Document, ADD Attribute batch item
    > > request, each batch item has UUID. This facility is provided to
    > > handle adding of attributes to TWO different objects at a time?
    > >  
    >
    > Yes. The use case described repeats the same Unique Identifier in
    > the operation of each batch item, but they could have been different
    > Unique Identifiers as well.
    >
    > > Please help me understand these.
    > >  
    > > Thanking You,
    > >  
    > > Trinath Somanchi,
    > > trinath.somanchi@freescale.com
    > >


  • 3.  RE: [kmip] KMIP :: Doubts

    Posted 09-30-2010 07:28
    
    
    
    
    
    
    
    
    
    
    

    Hi-

    Thanks Robert for clearing my doubts.

    I have the following more doubts:

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

    [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

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

    Please help me understand these doubts.

    Trinath Somanchi,

    trinath.somanchi@freescale.com

    From: Robert Haas [mailto:rha@zurich.ibm.com]
    Sent: Thursday, September 30, 2010 12:28 AM
    To: Somanchi Trinath-B22327
    Cc: kmip@lists.oasis-open.org
    Subject: RE: [kmip] KMIP :: Doubts


    Hi Trinath, please see below.
    Regards,
    -Robert

    Somanchi Trinath-B22327 <B22327@freescale.com> wrote on 09/29/2010 06:39:50 PM:
    >
    > RE: [kmip] KMIP :: Doubts

    >
    > Somanchi Trinath-B22327

    >
    > to:

    >
    > Robert Haas

    >
    > 09/29/2010 06:43 PM

    >
    > Cc:

    >
    > kmip

    >
    > Some issue with my mail client, So resending this mail again, Ignore
    > if already received this email
    >
    > Thank you
    >
    >
    > Hi Robert,
    >
    > Thank you for the reply.
    >
    > My 3rd doubt is still not cleared. Use case 3.1.3 from the use case
    > document uses UUID in locate request. I think I was not clear in
    > expressing my doubt.
    >
    > Here is my Doubt:
    >
    > In Use case 3.1.3, Locate request, UUID is given in the request
    > payload in an Attribute Structure as:
    >
    >  Tag: Attribute (0x420008), Type: Structure (0x01), Data:
    >         Tag: Attribute Name (0x42000A), Type: Text String (0x07),
    > Data: Unique Identifier
    >         Tag: Attribute Value (0x42000B), Type: Text String (0x07),
    > Data: 1ed28ea5-2b31-4145-bcf2-36d0756d3890
    >
    > But in GET operation request, UUID is given in Unique identifier Tag. Like,
    >
    > Tag: Unique Identifier (0x420094), Type: Text String (0x07), Data:
    > 1ed28ea5-2b31-4145-bcf2-36d0756d3890
    >
    > My doubt is that, why two types exists for UUID specification?


    Thanks for helping me understand your question better.

    Parameters to operations can be base objects (defined in section 2), parameters that correspond to attributes (defined in section 3), enumerations (defined in sections 9.1.3.2.*), or objects that are defined in the operation itself.

    In addition to these parameters that must be listed explicitly in each operation request or response specification, a small set of operations allow to pass parameters that are NOT explicitly listed one by one. This is the case for Locate, Notify, Put, Get Attributes, Add/Modify/Delete Attribute. This is done with an attribute structure with name/index/value, that allows to pass multiple instances if needed.

    In the example you raised, Unique Identifier is not treated differently than other such attribute parameters passed to Locate for matching purposes.

    >
    > I mean why can't UUID specified in Attribute structure (present in
    > locate) be used in GET operation request also?


    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.

    >
    > Is there any specific reason behind the framing of request in this way?
    >
    > Please help me understand this.
    >
    >
    > Best Regards,
    > --------------------
    > Trinath Somanchi.
    > email : trinath.somanchi@gmail.com
    > Mobile: +91 9866 235 130
    >
    >
    >
    >


    > From: Robert Haas [mailto:rha@zurich.ibm.com]
    > Sent: Wed 29-Sep-10 9:35 PM
    > To: Somanchi Trinath-B22327
    > Cc: kmip@lists.oasis-open.org
    > Subject: Re: [kmip] KMIP :: Doubts
    >
    >
    > Hi Trinath, please find answers to your questions below.
    > Regards,
    > -Robert
    >
    > Somanchi Trinath-B22327 <B22327@freescale.com> wrote on 09/28/2010
    > 06:52:31 AM:
    > >
    > > [kmip] KMIP :: Doubts
    > >
    > > Somanchi Trinath-B22327
    > >
    > > to:
    > >
    > > kmip
    > >
    > > 09/28/2010 06:54 AM
    > >
    > > Hi-
    > >  
    > > I have the following doubts regarding KMIP.  Please review and help
    > > me understand them.
    > >  
    > > Doubts:
    > >  
    > > [1] An SHA-256 hash is created by the KMIP server when a Symmetric
    > > Key is created. How to generate some other kind of Hash say,
    > > SHA-512? I mean do client need to send add attribute request with
    > > name value pairs of variables present in Digest structure or how
    > > this can be achieved?
    >
    > It is up to a server implementation to choose to have digests beyond
    > the mandatory one. The client cannot request this.
    >
    > >  
    > > [2] With respect to ADD attribute operation, the spec says, READ-
    > > ONLY attributes cannot be added using this operation. READ-ONLY
    > > attribute is defined as 'Attribute that shall not be modified by
    > > either server or client and that shall not be deleted by client'. My
    > > reading through spec document gave me the following NON-READ-ONLY
    > > attributes which can be used in ADD attribute operation. The listing
    > > is as follows:
    >
    > Digest should be removed from your list.
    >
    > > Name
    > > o   Name Value
    > > o   Name Type
    > > Cryptographic Parameters
    > > o   Block Cipher Mode
    > > o   Padding Method
    > > o   Hashing Algorithm
    > > o   Key Role Type
    > > Usage Limits
    > > o   Usage Limits Total
    > > o   Usage Limits Count
    > > o   Usage Limits Unit
    > > Object Group
    > > Link
    > > o   Link Type
    > > o   Linked Object Identifier
    > > Contact Information
    > > Custom Attribute
    > > Activation Date
    > > Process Start Date
    > > Protect Stop Date
    > > Deactivation Date
    > > Digest
    > > Operational Policy
    > > Application Specific Information
    > > o   Application Namespace
    > > o   Application Data
    > > Please comment if I missed any attribute.
    > >  
    > > [3] With respect to the Usage Guide, I'm comparing two requests.
    > > LOCATE and GET operation Requests.
    > >  
    > > In the LOCATE operation request, the UUID is placed in an ATTRIBUTE
    > > BLOCK which is common for all requests. like,
    > >  
    > > Locate
    > > In: uuidKey
    > >  
    > > Tag: Request Message (0x420078), Type: Structure (0x01), Data:
    > >   Tag: Request Header (0x420077), Type: Structure (0x01), Data:
    > >     Tag: Protocol Version (0x420069), Type: Structure (0x01), Data:
    > >       Tag: Protocol Version Major (0x42006A), Type: Integer (0x02),
    > > Data: 0x00000001 (1)
    > >       Tag: Protocol Version Minor (0x42006B), Type: Integer (0x02),
    > > Data: 0x00000000 (0)
    > >     Tag: Batch Count (0x42000D), Type: Integer (0x02), Data: 0x00000001 (1)
    > >   Tag: Batch Item (0x42000F), Type: Structure (0x01), Data:
    > >     Tag: Operation (0x42005C), Type: Enumeration (0x05), Data:
    > > 0x00000008 (Locate)
    > >     Tag: Request Payload (0x420079), Type: Structure (0x01), Data:
    > >       Tag: Attribute (0x420008), Type: Structure (0x01), Data:
    > >         Tag: Attribute Name (0x42000A), Type: Text String (0x07),
    > > Data: Unique Identifier
    > >         Tag: Attribute Value (0x42000B), Type: Text String (0x07),
    > > Data: 1ed28ea5-2b31-4145-bcf2-36d0756d3890
    > >  
    > > But in GET operation request, the UUID is not placed in the ATTRIBUTE block.
    > >  
    > >  
    > > Tag: Request Message (0x420078), Type: Structure (0x01), Data:
    > >   Tag: Request Header (0x420077), Type: Structure (0x01), Data:
    > >     Tag: Protocol Version (0x420069), Type: Structure (0x01), Data:
    > >       Tag: Protocol Version Major (0x42006A), Type: Integer (0x02),
    > > Data: 0x00000001 (1)
    > >       Tag: Protocol Version Minor (0x42006B), Type: Integer (0x02),
    > > Data: 0x00000000 (0)
    > >     Tag: Batch Count (0x42000D), Type: Integer (0x02), Data: 0x00000001 (1)
    > >   Tag: Batch Item (0x42000F), Type: Structure (0x01), Data:
    > >     Tag: Operation (0x42005C), Type: Enumeration (0x05), Data:
    > > 0x0000000A (Get)
    > >     Tag: Request Payload (0x420079), Type: Structure (0x01), Data:
    > >       Tag: Unique Identifier (0x420094), Type: Text String (0x07),
    > > Data: 1ed28ea5-2b31-4145-bcf2-36d0756d3890
    > >  
    > > Why this difference is maintained? Will this differentiation helps
    > > improving KMIP request/response? Please comment on this.
    >
    > Locate returns the Unique Identifier(s) of object(s) matching a
    > given search criteria. So you should not need to specify Unique
    > Identifier in a Locate operation request.
    >
    > >  
    > > [4] With respect to Use case Document, ADD Attribute batch item
    > > request, each batch item has UUID. This facility is provided to
    > > handle adding of attributes to TWO different objects at a time?
    > >  
    >
    > Yes. The use case described repeats the same Unique Identifier in
    > the operation of each batch item, but they could have been different
    > Unique Identifiers as well.
    >
    > > Please help me understand these.
    > >  
    > > Thanking You,
    > >  
    > > Trinath Somanchi,
    > > trinath.somanchi@freescale.com
    > >