OASIS Key Management Interoperability Protocol (KMIP) TC

  • 1.  KMIP :: Doubts

    Posted 09-28-2010 04:53 
    










    


    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?
    


    


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


          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.
    


    


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


    


    Please help me understand these.
    


    


    Thanking You,
    


    


    Trinath Somanchi,
    


    trinath.somanchi@freescale.com


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

    Posted 09-29-2010 16:06 

    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
    >  


Related Content