OASIS Key Management Interoperability Protocol (KMIP) TC

  • 1.  Feedback on binary alignment proposal

    Posted 04-27-2009 16:27
      |   view attached

    Attachment(s)

    vcf
    matthew_ball.vcf   330 B 1 version


  • 2.  Re: [kmip] Feedback on binary alignment proposal

    Posted 04-28-2009 00:28
      |   view attached

    Attachment(s)

    vcf
    matthew_ball.vcf   347 B 1 version


  • 3.  RE: [kmip] Feedback on binary alignment proposal

    Posted 04-28-2009 02:09
    
    
    
    
    
    
    I see several reasons for ensuring that we keep both the Tag and type their current 4 byte lengths.  We are still under 255 tags (156) but we are planning to define server to server at some point in the future (v2.0 and beyond) and there are extensions that we want to allow for.  I wouldn't want to hamstring ourselves by not planning for it now.  Plus we don't know what may change for the clients in later versions of the standard that might be useful to this type of device.  I think we should set the expectation now before people potentially code themselves into a corner by accident.
     
    The other issue we would have is that it would limit or remove the number of extensions that we might want to allow either via registration or assignment in the future for other standards that want to make use of KMIP.
     
    I agree with the four byte boundaries but don't want to limit ourselves.  If we do this I like Glen's suggestion in 1C and I don't know how soon we will hit 256 types but I am thinking it will take a little longer to generate them than it would to create another 99 new tags (thinking of server to server & extensions).
     
    My 2 cents for the day,
     
    Bob L.
     

    Robert A. (Bob) Lockhart

    Senior Solutions Architect

    THALES Information Systems Security

     

    -------------------------------------------------------

    T:      +1 408 457 7711 (Direct)

    M:     +1 510 410 0585

    F:      +1 408 457 7681

    E:      rlockhart@ncipher.com

    W:     www.nCipher.com

     

             nCipher product line. See www.nCipher.com


    From: Glen Jaquette [jaquette@us.ibm.com]
    Sent: Monday, April 27, 2009 5:28 PM
    To: kmip@lists.oasis-open.org
    Subject: Re: [kmip] Feedback on binary alignment proposal


    Matt,
            I do see value in revising the TTLV protocol to align it to 4 byte boundaries, I think we just have to work through the details to make sure we find the best trade-off.  Here are my thoughts:

    Your proposal devolves into 2 main ideas which are essentially separable:
    1. You observe that the present composition is essentially a 4 byte Tag followed by a 1 byte Type field (i.e. (4-byte Tag = 0x42.00.00.YZ)) which  immediately throws off the 4 byte alignment, and this is a first thing that needs to be addressed.  There are various ways to address that:
      1. The specific proposal you illustrated on slide 6 is option 1.1 from slide 5 -- namely to drop the leading byte of the four Tag field, which is 0x42 in all cases today, making it effectively a 3 byte Tag.  Then you transpose the Type and Tag fields, giving:
        • (1-byte Type) | (3-byte Tag = 0x00.00.YZ)
        • => Pro: this decreases the number of bytes which need to be communicated to give both Tag and Type by one
        • => Con: in response to which a Tony and Jon observed that this eliminates the 0x42 which has proven useful in the testing so far
      2. Someone else (didn't catch the name) suggested that instead we just pad Tag out to 4 bytes, or effectively:
        • (4-byte Tag = 0x42.00.00.YZ) | 4-byte Type)
        • => Pro: this preserves the 0x42.00.00 that can be used to distinguish the start of a new Tag, and hence the start of a new TTLV message
        • => Con: this increases the number of bytes which need to be communicated to give both Tag and Type by three
      3. A third option which occurs to me is a variation of option 1.2 from your slide 5, namely to cut a different byte from the Tag (0x00 instead of 0x42) and then not transpose or effectively:
        • (4-byte Tag = 0x42.00.YZ) | 1-byte Type)
        • => Pro: this decreases the number of bytes which need to be communicated to give both Tag and Type by one (i.e. same as 1A)
        • => Pro: this preserves the first two of the distinguishable bytes (i.e. 0x42.00) that can be used to distinguish the start of a new Tag, and hence the start of a new TTLV message, though one could argue that is slightly less than the 3 bytes that exist today.
    2. Similarly make the Value modulo 4 bytes by:
      1. Padding binary fields out to the next 4 byte boundary
      2. Making BIGNUM fields an integer number of 4 byte fields long

    As far as #1 above, I would suggest we consider 1C.  As far as #2, I don't see how to improve on your proposal.  

    Regards,
                      Glen Jaquette
                      IBM Distinguished Engineer
                      (520) 799-2192; fax: -4138; tieline 321-



    Matt Ball <Matthew.Ball@Sun.COM>
    Sent by: Matthew.Ball@Sun.COM

    04/27/2009 09:26 AM

    To
    kmip@lists.oasis-open.org
    cc
    Subject
    [kmip] Feedback on binary alignment proposal





    Hi Folks,

    If you have any preferences regarding the encoding choices from last
    Friday's binary alignment presentation, please send them to me by
    tomorrow so that I can incorporate them into the first revision of the
    proposal.  I plan to have the full proposal ready for discussion during
    Thursday's meeting, if there is time available on the agenda.

    Thanks!
    -Matt

    View Document Details:
    http://www.oasis-open.org/committees/document.php?document_id=32244

    Download Document:  
    http://www.oasis-open.org/committees/download.php/32244/Sun%20KMIP%20Alignment%20Proposal.pdf

    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


    The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +1 (781) 994 4000 or email ussales@ncipher.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of nCipher Inc.


  • 4.  RE: [kmip] Feedback on binary alignment proposal

    Posted 04-28-2009 04:11
    
    
    
    
    
    
    
    I agree with Matt, Glen, and BobL on 4-byte alignment of all KMIP protocol elements, and with BobL on keeping lots of headroom in the enumeration spaces. 
     
    I have seen entirely too much R&D effort over the past 38 years spent on kludging and extending opcode/name/address spaces.  It's ~another bit per year, whether you like it or not, so plan ahead.  If you want an architecture to last 16 years, add 2 bytes.  So I would advise 4 bytes tag, 4 bytes type, 4 bytes length, 4N bytes value.  In 3 years or so, nobody will care about brevity, they will be worrying about hitting limits.
     
    My 2 or 3 cents.
    Steve Wierenga
    HP Secure Advantage


    From: Robert Lockhart [mailto:Robert.Lockhart@thalesesec.com]
    Sent: Monday, April 27, 2009 7:08 PM
    To: kmip@lists.oasis-open.org
    Subject: RE: [kmip] Feedback on binary alignment proposal

    I see several reasons for ensuring that we keep both the Tag and type their current 4 byte lengths.  We are still under 255 tags (156) but we are planning to define server to server at some point in the future (v2.0 and beyond) and there are extensions that we want to allow for.  I wouldn't want to hamstring ourselves by not planning for it now.  Plus we don't know what may change for the clients in later versions of the standard that might be useful to this type of device.  I think we should set the expectation now before people potentially code themselves into a corner by accident.
     
    The other issue we would have is that it would limit or remove the number of extensions that we might want to allow either via registration or assignment in the future for other standards that want to make use of KMIP.
     
    I agree with the four byte boundaries but don't want to limit ourselves.  If we do this I like Glen's suggestion in 1C and I don't know how soon we will hit 256 types but I am thinking it will take a little longer to generate them than it would to create another 99 new tags (thinking of server to server & extensions).
     
    My 2 cents for the day,
     
    Bob L.
     

    Robert A. (Bob) Lockhart

    Senior Solutions Architect

    THALES Information Systems Security

     

    -------------------------------------------------------

    T:      +1 408 457 7711 (Direct)

    M:     +1 510 410 0585

    F:      +1 408 457 7681

    E:      rlockhart@ncipher.com

    W:     www.nCipher.com

     

             nCipher product line. See www.nCipher.com


    From: Glen Jaquette [jaquette@us.ibm.com]
    Sent: Monday, April 27, 2009 5:28 PM
    To: kmip@lists.oasis-open.org
    Subject: Re: [kmip] Feedback on binary alignment proposal


    Matt,
            I do see value in revising the TTLV protocol to align it to 4 byte boundaries, I think we just have to work through the details to make sure we find the best trade-off.  Here are my thoughts:

    Your proposal devolves into 2 main ideas which are essentially separable:
    1. You observe that the present composition is essentially a 4 byte Tag followed by a 1 byte Type field (i.e. (4-byte Tag = 0x42.00.00.YZ)) which  immediately throws off the 4 byte alignment, and this is a first thing that needs to be addressed.  There are various ways to address that:
      1. The specific proposal you illustrated on slide 6 is option 1.1 from slide 5 -- namely to drop the leading byte of the four Tag field, which is 0x42 in all cases today, making it effectively a 3 byte Tag.  Then you transpose the Type and Tag fields, giving:
        • (1-byte Type) | (3-byte Tag = 0x00.00.YZ)
        • => Pro: this decreases the number of bytes which need to be communicated to give both Tag and Type by one
        • => Con: in response to which a Tony and Jon observed that this eliminates the 0x42 which has proven useful in the testing so far
      2. Someone else (didn't catch the name) suggested that instead we just pad Tag out to 4 bytes, or effectively:
        • (4-byte Tag = 0x42.00.00.YZ) | 4-byte Type)
        • => Pro: this preserves the 0x42.00.00 that can be used to distinguish the start of a new Tag, and hence the start of a new TTLV message
        • => Con: this increases the number of bytes which need to be communicated to give both Tag and Type by three
      3. A third option which occurs to me is a variation of option 1.2 from your slide 5, namely to cut a different byte from the Tag (0x00 instead of 0x42) and then not transpose or effectively:
        • (4-byte Tag = 0x42.00.YZ) | 1-byte Type)
        • => Pro: this decreases the number of bytes which need to be communicated to give both Tag and Type by one (i.e. same as 1A)
        • => Pro: this preserves the first two of the distinguishable bytes (i.e. 0x42.00) that can be used to distinguish the start of a new Tag, and hence the start of a new TTLV message, though one could argue that is slightly less than the 3 bytes that exist today.
    2. Similarly make the Value modulo 4 bytes by:
      1. Padding binary fields out to the next 4 byte boundary
      2. Making BIGNUM fields an integer number of 4 byte fields long

    As far as #1 above, I would suggest we consider 1C.  As far as #2, I don't see how to improve on your proposal.  

    Regards,
                      Glen Jaquette
                      IBM Distinguished Engineer
                      (520) 799-2192; fax: -4138; tieline 321-



    Matt Ball <Matthew.Ball@Sun.COM>
    Sent by: Matthew.Ball@Sun.COM

    04/27/2009 09:26 AM

    To
    kmip@lists.oasis-open.org
    cc
    Subject
    [kmip] Feedback on binary alignment proposal





    Hi Folks,

    If you have any preferences regarding the encoding choices from last
    Friday's binary alignment presentation, please send them to me by
    tomorrow so that I can incorporate them into the first revision of the
    proposal.  I plan to have the full proposal ready for discussion during
    Thursday's meeting, if there is time available on the agenda.

    Thanks!
    -Matt

    View Document Details:
    http://www.oasis-open.org/committees/document.php?document_id=32244

    Download Document:  
    http://www.oasis-open.org/committees/download.php/32244/Sun%20KMIP%20Alignment%20Proposal.pdf

    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


    The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +1 (781) 994 4000 or email ussales@ncipher.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of nCipher Inc.


  • 5.  Re: [kmip] Feedback on binary alignment proposal

    Posted 04-28-2009 06:17
    We also believe that is critical that we maintain the tag and type as 4 byte lengths would would vigorously oppose any attempt to reduce their length.

    The simplest option (short of giving up on 4 octet alignment) may be #2: pad fields out to 4 octet boundaries.

    chongo () /\oo/\

    =-=

    On 2009-Apr-27, at 19:08, Robert Lockhart wrote:

    I see several reasons for ensuring that we keep both the Tag and type their current 4 byte lengths.  We are still under 255 tags (156) but we are planning to define server to server at some point in the future (v2.0 and beyond) and there are extensions that we want to allow for.  I wouldn't want to hamstring ourselves by not planning for it now.  Plus we don't know what may change for the clients in later versions of the standard that might be useful to this type of device.  I think we should set the expectation now before people potentially code themselves into a corner by accident.
     
    The other issue we would have is that it would limit or remove the number of extensions that we might want to allow either via registration or assignment in the future for other standards that want to make use of KMIP.
     
    I agree with the four byte boundaries but don't want to limit ourselves.  If we do this I like Glen's suggestion in 1C and I don't know how soon we will hit 256 types but I am thinking it will take a little longer to generate them than it would to create another 99 new tags (thinking of server to server & extensions).
     
    My 2 cents for the day,
     
    Bob L.
     
    Robert A. (Bob) Lockhart
    Senior Solutions Architect
    THALES Information Systems Security
     
    -------------------------------------------------------
    T:      +1 408 457 7711 (Direct)
    M:     +1 510 410 0585
    F:      +1 408 457 7681
    E:      rlockhart@ncipher.com
    W:     www.nCipher.com
     
             nCipher product line. See www.nCipher.com

    From: Glen Jaquette [jaquette@us.ibm.com]
    Sent: Monday, April 27, 2009 5:28 PM
    To: kmip@lists.oasis-open.org
    Subject: Re: [kmip] Feedback on binary alignment proposal


    Matt, 
            I do see value in revising the TTLV protocol to align it to 4 byte boundaries, I think we just have to work through the details to make sure we find the best trade-off.  Here are my thoughts: 

    Your proposal devolves into 2 main ideas which are essentially separable: 
    1. You observe that the present composition is essentially a 4 byte Tag followed by a 1 byte Type field (i.e. (4-byte Tag = 0x42.00.00.YZ)) which  immediately throws off the 4 byte alignment, and this is a first thing that needs to be addressed.  There are various ways to address that:
      1. The specific proposal you illustrated on slide 6 is option 1.1 from slide 5 -- namely to drop the leading byte of the four Tag field, which is 0x42 in all cases today, making it effectively a 3 byte Tag.  Then you transpose the Type and Tag fields, giving:
        • (1-byte Type) | (3-byte Tag = 0x00.00.YZ)
        • => Pro: this decreases the number of bytes which need to be communicated to give both Tag and Type by one
        • => Con: in response to which a Tony and Jon observed that this eliminates the 0x42 which has proven useful in the testing so far
      2. Someone else (didn't catch the name) suggested that instead we just pad Tag out to 4 bytes, or effectively:
        • (4-byte Tag = 0x42.00.00.YZ) | 4-byte Type)
        • => Pro: this preserves the 0x42.00.00 that can be used to distinguish the start of a new Tag, and hence the start of a new TTLV message
        • => Con: this increases the number of bytes which need to be communicated to give both Tag and Type by three
      3. A third option which occurs to me is a variation of option 1.2 from your slide 5, namely to cut a different byte from the Tag (0x00 instead of 0x42) and then not transpose or effectively:
        • (4-byte Tag = 0x42.00.YZ) | 1-byte Type)
        • => Pro: this decreases the number of bytes which need to be communicated to give both Tag and Type by one (i.e. same as 1A)
        • => Pro: this preserves the first two of the distinguishable bytes (i.e. 0x42.00) that can be used to distinguish the start of a new Tag, and hence the start of a new TTLV message, though one could argue that is slightly less than the 3 bytes that exist today.
    2. Similarly make the Value modulo 4 bytes by:
      1. Padding binary fields out to the next 4 byte boundary
      2. Making BIGNUM fields an integer number of 4 byte fields long

    As far as #1 above, I would suggest we consider 1C.  As far as #2, I don't see how to improve on your proposal.   

    Regards,
                      Glen Jaquette
                      IBM Distinguished Engineer
                      (520) 799-2192; fax: -4138; tieline 321-



    Matt Ball <Matthew.Ball@Sun.COM> 
    Sent by: Matthew.Ball@Sun.COM
    04/27/2009 09:26 AM
    To
    kmip@lists.oasis-open.org
    cc
    Subject
    [kmip] Feedback on binary alignment proposal





    Hi Folks,

    If you have any preferences regarding the encoding choices from last
    Friday's binary alignment presentation, please send them to me by
    tomorrow so that I can incorporate them into the first revision of the
    proposal.  I plan to have the full proposal ready for discussion during
    Thursday's meeting, if there is time available on the agenda.

    Thanks!
    -Matt

    View Document Details:
    http://www.oasis-open.org/committees/document.php?document_id=32244

    Download Document:  
    http://www.oasis-open.org/committees/download.php/32244/Sun%20KMIP%20Alignment%20Proposal.pdf

    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


    The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +1 (781) 994 4000 or email ussales@ncipher.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of nCipher Inc.