OASIS Key Management Interoperability Protocol (KMIP) TC

 View Only
  • 1.  Import operation suggestion

    Posted 01-05-2017 23:51
    Anthony On the Import operation why not define a minimum set of attributes that must be supported on both ends for the operation to succeed?   Maybe this is a way to ensure interoperability.    I think one use for this feature could be by a customer to export from one server vendor and move the object to a different vendors product.    Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com On Jan 5, 2017, at 1:28 AM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Um, that should be PKCS#11, not POX intended! Anthony On Thu, Jan 5, 2017 at 7:25 PM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Submitter's message
    Hello All,

    Below is the link to a proposal to add Extractable and Sensitive flags to KMIP. They are modeled after POCS#11 in order to restrict the retrieval of key material.

    I will present this on tomorrow's call.

    -- Anthony Berglas



    Document Name : Non Exportable and Sensitive Attributes proposal

    No description provided.
    Download Latest Revision
    Public Download Link
    Submitter : Anthony Berglas
    Group : OASIS Key Management Interoperability Protocol (KMIP) TC
    Folder : Drafts
    Date submitted : 2017-01-05 01:25:10



    -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com




  • 2.  Re: [kmip] Import operation suggestion

    Posted 01-05-2017 23:58
    Hmm, like maybe a Profile that specifies the required Attributes?  Which would allow you to Query the server to see what profiles it supports, which would net the required Attributes without actually having to enhance Query to deal directly with Attributes, if that makes any sense.  It did when I thought it, but now that I've typed it out it looks odder than most things I type. Bruce On Thu, Jan 5, 2017 at 5:51 PM, Mark Joseph < mark@p6r.com > wrote: Anthony On the Import operation why not define a minimum set of attributes that must be supported on both ends for the operation to succeed?   Maybe this is a way to ensure interoperability.    I think one use for this feature could be by a customer to export from one server vendor and move the object to a different vendors product.    Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com On Jan 5, 2017, at 1:28 AM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Um, that should be PKCS#11, not POX intended! Anthony On Thu, Jan 5, 2017 at 7:25 PM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Submitter's message Hello All, Below is the link to a proposal to add Extractable and Sensitive flags to KMIP. They are modeled after POCS#11 in order to restrict the retrieval of key material. I will present this on tomorrow's call. -- Anthony Berglas Document Name : Non Exportable and Sensitive Attributes proposal No description provided. Download Latest Revision Public Download Link Submitter : Anthony Berglas Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2017-01-05 01:25:10 -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com


  • 3.  Re: [kmip] Import operation suggestion

    Posted 01-06-2017 00:32
    It does make sense Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com On Jan 5, 2017, at 3:57 PM, Bruce Rich < bar@cryptsoft.com > wrote: Hmm, like maybe a Profile that specifies the required Attributes?  Which would allow you to Query the server to see what profiles it supports, which would net the required Attributes without actually having to enhance Query to deal directly with Attributes, if that makes any sense.  It did when I thought it, but now that I've typed it out it looks odder than most things I type. Bruce On Thu, Jan 5, 2017 at 5:51 PM, Mark Joseph < mark@p6r.com > wrote: Anthony On the Import operation why not define a minimum set of attributes that must be supported on both ends for the operation to succeed?   Maybe this is a way to ensure interoperability.    I think one use for this feature could be by a customer to export from one server vendor and move the object to a different vendors product.    Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com On Jan 5, 2017, at 1:28 AM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Um, that should be PKCS#11, not POX intended! Anthony On Thu, Jan 5, 2017 at 7:25 PM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Submitter's message
    Hello All,

    Below is the link to a proposal to add Extractable and Sensitive flags to KMIP. They are modeled after POCS#11 in order to restrict the retrieval of key material.

    I will present this on tomorrow's call.

    -- Anthony Berglas



    Document Name : Non Exportable and Sensitive Attributes proposal

    No description provided.
    Download Latest Revision
    Public Download Link
    Submitter : Anthony Berglas
    Group : OASIS Key Management Interoperability Protocol (KMIP) TC
    Folder : Drafts
    Date submitted : 2017-01-05 01:25:10



    -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com





  • 4.  Re: [kmip] Import operation suggestion

    Posted 01-06-2017 00:47
    I also think that if the server cannot fully perform the import it should just fail, and let the client decide what to do about it, possibly removing some unsupported attributes and trying again. One problem we do have is that the error statuses are not as clear as they could be.  At the last face to face I suggested an additional Error Parameter in the results.  So if you got "Invalid Field" there would be some indication of which field failed (or was the first to fail).  Maybe we should do this as part of 2.0? Anthony On Fri, Jan 6, 2017 at 10:31 AM, Mark Joseph < mark@p6r.com > wrote: It does make sense Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com On Jan 5, 2017, at 3:57 PM, Bruce Rich < bar@cryptsoft.com > wrote: Hmm, like maybe a Profile that specifies the required Attributes?  Which would allow you to Query the server to see what profiles it supports, which would net the required Attributes without actually having to enhance Query to deal directly with Attributes, if that makes any sense.  It did when I thought it, but now that I've typed it out it looks odder than most things I type. Bruce On Thu, Jan 5, 2017 at 5:51 PM, Mark Joseph < mark@p6r.com > wrote: Anthony On the Import operation why not define a minimum set of attributes that must be supported on both ends for the operation to succeed?   Maybe this is a way to ensure interoperability.    I think one use for this feature could be by a customer to export from one server vendor and move the object to a different vendors product.    Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com On Jan 5, 2017, at 1:28 AM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Um, that should be PKCS#11, not POX intended! Anthony On Thu, Jan 5, 2017 at 7:25 PM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Submitter's message Hello All, Below is the link to a proposal to add Extractable and Sensitive flags to KMIP. They are modeled after POCS#11 in order to restrict the retrieval of key material. I will present this on tomorrow's call. -- Anthony Berglas Document Name : Non Exportable and Sensitive Attributes proposal No description provided. Download Latest Revision Public Download Link Submitter : Anthony Berglas Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2017-01-05 01:25:10 -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com


  • 5.  RE: [kmip] Import operation suggestion

    Posted 01-06-2017 01:17




    Hi Anthony,
     
    Before everyone gets carried away with the PKCS#11 flags how about adding a bit map type to KMIP.
     
    Nothing annoys me more that the fact that Usage Mask is treated especially. Define a bit map data type and its special status disappears at least
    as far as an exception on what one can do with searches etc. but there is the backwards compatibility question for that.
     
    If you are going to add PKCS#11 functionality (attributes) to KMIP then either you will come up with more reasons for another special mask such as
    the storage  attributes (private, modifyable, copyable, destroyable, token) or adopt a bit map data type compatible with integer (for bit mask equivalence). Other candidates for items in a mask are SENSITIVE and EXTRACTAABLE with even ALWAYS SENSITIVE and
    NEVER EXTRACTABLE.
    Without the bit mask there will be a proliferation of attributes.
     
    If you want to make a standard that is small, concise and elegant then it should not have any exceptions. Because of Usage Mask the type system is
    obviously lacking.
     
    Well that is my view anyway.
     
    If you would like a more formal description I would be happy to supply one.
     
    John Green
     


    From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
    On Behalf Of Mark Joseph
    Sent: Friday, 6 January 2017 10:51 AM
    To: Anthony Berglas <anthony.berglas@cryptsoft.com>
    Cc: OASIS KMIP Technical Committee <kmip@lists.oasis-open.org>
    Subject: [kmip] Import operation suggestion


     

    Anthony


     


    On the Import operation why not define a minimum set of attributes that must be supported on both ends for the operation to succeed?   Maybe this is a way to ensure interoperability.    I think one use for this feature could be by a customer
    to export from one server vendor and move the object to a different vendors product.   

    Best,

    Mark Joseph


    P6R,  Inc


    408-205-0361


    mark@p6r.com


     




    On Jan 5, 2017, at 1:28 AM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote:





    Um, that should be PKCS#11, not POX intended!

    Anthony


     

    On Thu, Jan 5, 2017 at 7:25 PM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote:

    Submitter's message
    Hello All,

    Below is the link to a proposal to add Extractable and Sensitive flags to KMIP. They are modeled after POCS#11 in order to restrict the retrieval of key material.


    I will present this on tomorrow's call.
    -- Anthony Berglas




    Document Name :

    Non Exportable and Sensitive Attributes proposal





    No description provided.

    Download Latest Revision
    Public Download Link





    Submitter : Anthony Berglas
    Group : OASIS Key Management Interoperability Protocol (KMIP) TC
    Folder : Drafts
    Date submitted : 2017-01-05 01:25:10









    --




    Anthony Berglas Ph.D.
    Principal Engineer
    Anthony.Berglas@Cryptsoft.com








    ______________________________________________________________________
    This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
    ______________________________________________________________________






  • 6.  Re: [kmip] Import operation suggestion

    Posted 01-06-2017 01:47
    BTW All those PKCS#11 attributes you list are type Boolean not a bit mask in P11 Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com On Jan 5, 2017, at 5:16 PM, John Green < JG@quintessencelabs.com > wrote: Hi Anthony,   Before everyone gets carried away with the PKCS#11 flags how about adding a bit map type to KMIP.   Nothing annoys me more that the fact that Usage Mask is treated especially. Define a bit map data type and its special status disappears at least as far as an exception on what one can do with searches etc. but there is the backwards compatibility question for that.   If you are going to add PKCS#11 functionality (attributes) to KMIP then either you will come up with more reasons for another special mask such as the storage  attributes (private, modifyable, copyable, destroyable, token) or adopt a bit map data type compatible with integer (for bit mask equivalence). Other candidates for items in a mask are SENSITIVE and EXTRACTAABLE with even ALWAYS SENSITIVE and NEVER EXTRACTABLE. Without the bit mask there will be a proliferation of attributes.   If you want to make a standard that is small, concise and elegant then it should not have any exceptions. Because of Usage Mask the type system is obviously lacking.   Well that is my view anyway.   If you would like a more formal description I would be happy to supply one.   John Green   From: kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ] On Behalf Of Mark Joseph Sent: Friday, 6 January 2017 10:51 AM To: Anthony Berglas < anthony.berglas@cryptsoft.com > Cc: OASIS KMIP Technical Committee < kmip@lists.oasis-open.org > Subject: [kmip] Import operation suggestion   Anthony   On the Import operation why not define a minimum set of attributes that must be supported on both ends for the operation to succeed?   Maybe this is a way to ensure interoperability.    I think one use for this feature could be by a customer to export from one server vendor and move the object to a different vendors product.    Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com   On Jan 5, 2017, at 1:28 AM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Um, that should be PKCS#11, not POX intended! Anthony   On Thu, Jan 5, 2017 at 7:25 PM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Submitter's message Hello All, Below is the link to a proposal to add Extractable and Sensitive flags to KMIP. They are modeled after POCS#11 in order to restrict the retrieval of key material. I will present this on tomorrow's call. -- Anthony Berglas Document Name : Non Exportable and Sensitive Attributes proposal No description provided. Download Latest Revision Public Download Link Submitter : Anthony Berglas Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2017-01-05 01:25:10 -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd. ______________________________________________________________________


  • 7.  RE: [kmip] Import operation suggestion

    Posted 01-06-2017 02:01




    Thanks Mark,
     
    Yes they are but it becomes a problem when you need them all and even search for a combination. Besides the bit mask is completing the types properly
    for KMIP.
    Otherwise why did Usage Mask need to be special?
     
    Regards
    John
     


    From: Mark Joseph [mailto:mark@p6r.com]

    Sent: Friday, 6 January 2017 12:47 PM
    To: John Green <JG@quintessencelabs.com>
    Cc: Anthony Berglas <anthony.berglas@cryptsoft.com>; OASIS KMIP Technical Committee <kmip@lists.oasis-open.org>
    Subject: Re: [kmip] Import operation suggestion


     

    BTW All those PKCS#11 attributes you list are type Boolean not a bit mask in P11


     




    Best,

    Mark Joseph


    P6R,  Inc


    408-205-0361


    mark@p6r.com


     




    On Jan 5, 2017, at 5:16 PM, John Green < JG@quintessencelabs.com > wrote:



    Hi Anthony,
     
    Before everyone gets carried away with the PKCS#11 flags how about adding a bit map type to KMIP.
     
    Nothing annoys me more that the fact that Usage Mask is treated especially. Define a bit map data type and its special status disappears at least
    as far as an exception on what one can do with searches etc. but there is the backwards compatibility question for that.
     
    If you are going to add PKCS#11 functionality (attributes) to KMIP then either you will come up with more reasons for another special mask such as
    the storage  attributes (private, modifyable, copyable, destroyable, token) or adopt a bit map data type compatible with integer (for bit mask equivalence). Other candidates for items in a mask are SENSITIVE and EXTRACTAABLE with even ALWAYS SENSITIVE and
    NEVER EXTRACTABLE.
    Without the bit mask there will be a proliferation of attributes.
     
    If you want to make a standard that is small, concise and elegant then it should not have any exceptions. Because of Usage Mask the type system is
    obviously lacking.
     
    Well that is my view anyway.
     
    If you would like a more formal description I would be happy to supply one.
     
    John Green
     


    From:
    kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ]
    On Behalf Of Mark Joseph
    Sent: Friday, 6 January 2017 10:51 AM
    To: Anthony Berglas < anthony.berglas@cryptsoft.com >
    Cc: OASIS KMIP Technical Committee < kmip@lists.oasis-open.org >
    Subject: [kmip] Import operation suggestion


     

    Anthony


     


    On the Import operation why not define a minimum set of attributes that must be supported on both ends for the operation to succeed?   Maybe this is a way to ensure interoperability.    I think one use for this feature could be by a customer
    to export from one server vendor and move the object to a different vendors product.   

    Best,

    Mark Joseph


    P6R,  Inc


    408-205-0361


    mark@p6r.com


     




    On Jan 5, 2017, at 1:28 AM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote:





    Um, that should be PKCS#11, not POX intended!

    Anthony


     

    On Thu, Jan 5, 2017 at 7:25 PM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote:

    Submitter's message
    Hello All,

    Below is the link to a proposal to add Extractable and Sensitive flags to KMIP. They are modeled after POCS#11 in order to restrict the retrieval of key material.


    I will present this on tomorrow's call.
    -- Anthony Berglas




    Document Name :

    Non Exportable and Sensitive Attributes proposal







    No description provided.

    Download Latest Revision
    Public Download Link







    Submitter : Anthony Berglas
    Group : OASIS Key Management Interoperability Protocol (KMIP) TC
    Folder : Drafts
    Date submitted : 2017-01-05 01:25:10









    --




    Anthony Berglas Ph.D.
    Principal Engineer
    Anthony.Berglas@Cryptsoft.com








    ______________________________________________________________________
    This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
    ______________________________________________________________________



    ______________________________________________________________________
    This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
    ______________________________________________________________________






  • 8.  Re: [kmip] Import operation suggestion

    Posted 01-06-2017 02:03
    Actually we implement all of these already in our P11 KMIP token as custom attributes as Boolean type.   And search is no problem at all So what is the issue? Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com On Jan 5, 2017, at 6:00 PM, John Green < JG@quintessencelabs.com > wrote: Thanks Mark,   Yes they are but it becomes a problem when you need them all and even search for a combination. Besides the bit mask is completing the types properly for KMIP. Otherwise why did Usage Mask need to be special?   Regards John   From: Mark Joseph [ mailto:mark@p6r.com ] Sent: Friday, 6 January 2017 12:47 PM To: John Green < JG@quintessencelabs.com > Cc: Anthony Berglas < anthony.berglas@cryptsoft.com >; OASIS KMIP Technical Committee < kmip@lists.oasis-open.org > Subject: Re: [kmip] Import operation suggestion   BTW All those PKCS#11 attributes you list are type Boolean not a bit mask in P11   Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com   On Jan 5, 2017, at 5:16 PM, John Green < JG@quintessencelabs.com > wrote: Hi Anthony,   Before everyone gets carried away with the PKCS#11 flags how about adding a bit map type to KMIP.   Nothing annoys me more that the fact that Usage Mask is treated especially. Define a bit map data type and its special status disappears at least as far as an exception on what one can do with searches etc. but there is the backwards compatibility question for that.   If you are going to add PKCS#11 functionality (attributes) to KMIP then either you will come up with more reasons for another special mask such as the storage  attributes (private, modifyable, copyable, destroyable, token) or adopt a bit map data type compatible with integer (for bit mask equivalence). Other candidates for items in a mask are SENSITIVE and EXTRACTAABLE with even ALWAYS SENSITIVE and NEVER EXTRACTABLE. Without the bit mask there will be a proliferation of attributes.   If you want to make a standard that is small, concise and elegant then it should not have any exceptions. Because of Usage Mask the type system is obviously lacking.   Well that is my view anyway.   If you would like a more formal description I would be happy to supply one.   John Green   From: kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ] On Behalf Of Mark Joseph Sent: Friday, 6 January 2017 10:51 AM To: Anthony Berglas < anthony.berglas@cryptsoft.com > Cc: OASIS KMIP Technical Committee < kmip@lists.oasis-open.org > Subject: [kmip] Import operation suggestion   Anthony   On the Import operation why not define a minimum set of attributes that must be supported on both ends for the operation to succeed?   Maybe this is a way to ensure interoperability.    I think one use for this feature could be by a customer to export from one server vendor and move the object to a different vendors product.    Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com   On Jan 5, 2017, at 1:28 AM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Um, that should be PKCS#11, not POX intended! Anthony   On Thu, Jan 5, 2017 at 7:25 PM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Submitter's message Hello All, Below is the link to a proposal to add Extractable and Sensitive flags to KMIP. They are modeled after POCS#11 in order to restrict the retrieval of key material. I will present this on tomorrow's call. -- Anthony Berglas Document Name : Non Exportable and Sensitive Attributes proposal No description provided. Download Latest Revision Public Download Link Submitter : Anthony Berglas Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2017-01-05 01:25:10 -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd. ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd. ______________________________________________________________________


  • 9.  RE: [kmip] Import operation suggestion

    Posted 01-06-2017 02:32




    Then get rid of Usage Mask as a bit map from KMIP.
     
    John Green
     


    From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
    On Behalf Of Mark Joseph
    Sent: Friday, 6 January 2017 1:03 PM
    To: John Green <JG@quintessencelabs.com>
    Cc: Anthony Berglas <anthony.berglas@cryptsoft.com>; OASIS KMIP Technical Committee <kmip@lists.oasis-open.org>
    Subject: Re: [kmip] Import operation suggestion


     

    Actually we implement all of these already in our P11 KMIP token as custom attributes as Boolean type.   And search is no problem at all


     


    So what is the issue?


     




    Best,

    Mark Joseph


    P6R,  Inc


    408-205-0361


    mark@p6r.com


     




    On Jan 5, 2017, at 6:00 PM, John Green < JG@quintessencelabs.com > wrote:



    Thanks Mark,
     
    Yes they are but it becomes a problem when you need them all and even search for a combination. Besides the bit mask is completing the types properly
    for KMIP.
    Otherwise why did Usage Mask need to be special?
     
    Regards
    John
     


    From: Mark Joseph [ mailto:mark@p6r.com ]

    Sent: Friday, 6 January 2017 12:47 PM
    To: John Green < JG@quintessencelabs.com >
    Cc: Anthony Berglas < anthony.berglas@cryptsoft.com >; OASIS KMIP Technical Committee < kmip@lists.oasis-open.org >
    Subject: Re: [kmip] Import operation suggestion


     

    BTW All those PKCS#11 attributes you list are type Boolean not a bit mask in P11


     




    Best,

    Mark Joseph


    P6R,  Inc


    408-205-0361


    mark@p6r.com


     




    On Jan 5, 2017, at 5:16 PM, John Green < JG@quintessencelabs.com > wrote:



    Hi Anthony,
     
    Before everyone gets carried away with the PKCS#11 flags how about adding a bit map type to KMIP.
     
    Nothing annoys me more that the fact that Usage Mask is treated especially. Define a bit map data type and its special status disappears at least
    as far as an exception on what one can do with searches etc. but there is the backwards compatibility question for that.
     
    If you are going to add PKCS#11 functionality (attributes) to KMIP then either you will come up with more reasons for another special mask such as
    the storage  attributes (private, modifyable, copyable, destroyable, token) or adopt a bit map data type compatible with integer (for bit mask equivalence). Other candidates for items in a mask are SENSITIVE and EXTRACTAABLE with even ALWAYS SENSITIVE and
    NEVER EXTRACTABLE.
    Without the bit mask there will be a proliferation of attributes.
     
    If you want to make a standard that is small, concise and elegant then it should not have any exceptions. Because of Usage Mask the type system is
    obviously lacking.
     
    Well that is my view anyway.
     
    If you would like a more formal description I would be happy to supply one.
     
    John Green
     


    From:
    kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ]
    On Behalf Of Mark Joseph
    Sent: Friday, 6 January 2017 10:51 AM
    To: Anthony Berglas < anthony.berglas@cryptsoft.com >
    Cc: OASIS KMIP Technical Committee < kmip@lists.oasis-open.org >
    Subject: [kmip] Import operation suggestion


     

    Anthony


     


    On the Import operation why not define a minimum set of attributes that must be supported on both ends for the operation to succeed?   Maybe this is a way to ensure interoperability.    I think one use for this feature could be by a customer
    to export from one server vendor and move the object to a different vendors product.   

    Best,

    Mark Joseph


    P6R,  Inc


    408-205-0361


    mark@p6r.com


     




    On Jan 5, 2017, at 1:28 AM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote:





    Um, that should be PKCS#11, not POX intended!

    Anthony


     

    On Thu, Jan 5, 2017 at 7:25 PM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote:

    Submitter's message
    Hello All,

    Below is the link to a proposal to add Extractable and Sensitive flags to KMIP. They are modeled after POCS#11 in order to restrict the retrieval of key material.


    I will present this on tomorrow's call.
    -- Anthony Berglas




    Document Name :

    Non Exportable and Sensitive Attributes proposal







    No description provided.

    Download Latest Revision
    Public Download Link







    Submitter : Anthony Berglas
    Group : OASIS Key Management Interoperability Protocol (KMIP) TC
    Folder : Drafts
    Date submitted : 2017-01-05 01:25:10









    --




    Anthony Berglas Ph.D.
    Principal Engineer
    Anthony.Berglas@Cryptsoft.com








    ______________________________________________________________________
    This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
    ______________________________________________________________________



    ______________________________________________________________________
    This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
    ______________________________________________________________________



    ______________________________________________________________________
    This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
    ______________________________________________________________________






  • 10.  Re: [kmip] Import operation suggestion

    Posted 01-06-2017 02:41
    Thanks Joe       As a client vendor we don't see any issue with crypto usage mask as it is.     We have not run into any interop issues either.     Changing this in already shipping products needs a compelling issue.    I have not heard anyone else complain about this either.   Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com On Jan 5, 2017, at 6:32 PM, John Green < JG@quintessencelabs.com > wrote: Then get rid of Usage Mask as a bit map from KMIP.   John Green   From: kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ] On Behalf Of Mark Joseph Sent: Friday, 6 January 2017 1:03 PM To: John Green < JG@quintessencelabs.com > Cc: Anthony Berglas < anthony.berglas@cryptsoft.com >; OASIS KMIP Technical Committee < kmip@lists.oasis-open.org > Subject: Re: [kmip] Import operation suggestion   Actually we implement all of these already in our P11 KMIP token as custom attributes as Boolean type.   And search is no problem at all   So what is the issue?   Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com   On Jan 5, 2017, at 6:00 PM, John Green < JG@quintessencelabs.com > wrote: Thanks Mark,   Yes they are but it becomes a problem when you need them all and even search for a combination. Besides the bit mask is completing the types properly for KMIP. Otherwise why did Usage Mask need to be special?   Regards John   From: Mark Joseph [ mailto:mark@p6r.com ] Sent: Friday, 6 January 2017 12:47 PM To: John Green < JG@quintessencelabs.com > Cc: Anthony Berglas < anthony.berglas@cryptsoft.com >; OASIS KMIP Technical Committee < kmip@lists.oasis-open.org > Subject: Re: [kmip] Import operation suggestion   BTW All those PKCS#11 attributes you list are type Boolean not a bit mask in P11   Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com   On Jan 5, 2017, at 5:16 PM, John Green < JG@quintessencelabs.com > wrote: Hi Anthony,   Before everyone gets carried away with the PKCS#11 flags how about adding a bit map type to KMIP.   Nothing annoys me more that the fact that Usage Mask is treated especially. Define a bit map data type and its special status disappears at least as far as an exception on what one can do with searches etc. but there is the backwards compatibility question for that.   If you are going to add PKCS#11 functionality (attributes) to KMIP then either you will come up with more reasons for another special mask such as the storage  attributes (private, modifyable, copyable, destroyable, token) or adopt a bit map data type compatible with integer (for bit mask equivalence). Other candidates for items in a mask are SENSITIVE and EXTRACTAABLE with even ALWAYS SENSITIVE and NEVER EXTRACTABLE. Without the bit mask there will be a proliferation of attributes.   If you want to make a standard that is small, concise and elegant then it should not have any exceptions. Because of Usage Mask the type system is obviously lacking.   Well that is my view anyway.   If you would like a more formal description I would be happy to supply one.   John Green   From: kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ] On Behalf Of Mark Joseph Sent: Friday, 6 January 2017 10:51 AM To: Anthony Berglas < anthony.berglas@cryptsoft.com > Cc: OASIS KMIP Technical Committee < kmip@lists.oasis-open.org > Subject: [kmip] Import operation suggestion   Anthony   On the Import operation why not define a minimum set of attributes that must be supported on both ends for the operation to succeed?   Maybe this is a way to ensure interoperability.    I think one use for this feature could be by a customer to export from one server vendor and move the object to a different vendors product.    Best, Mark Joseph P6R,  Inc 408-205-0361 mark@p6r.com   On Jan 5, 2017, at 1:28 AM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Um, that should be PKCS#11, not POX intended! Anthony   On Thu, Jan 5, 2017 at 7:25 PM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote: Submitter's message Hello All, Below is the link to a proposal to add Extractable and Sensitive flags to KMIP. They are modeled after POCS#11 in order to restrict the retrieval of key material. I will present this on tomorrow's call. -- Anthony Berglas Document Name : Non Exportable and Sensitive Attributes proposal No description provided. Download Latest Revision Public Download Link Submitter : Anthony Berglas Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2017-01-05 01:25:10 -- Anthony Berglas Ph.D. Principal Engineer Anthony.Berglas@Cryptsoft.com ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd. ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd. ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd. ______________________________________________________________________


  • 11.  RE: [kmip] Import operation suggestion

    Posted 01-06-2017 03:25




    Hi Joe,
     
    My point is that when Usage Mask was defined as it is, a bit mask type should have been defined, not make some special case for it so that servers
    have to go "oh this is a usage mask I have to do something special" and on top of that "I have to be checking for usage mask all the time for the special processing". This is an exception to "get attribute and process it based on its type", one simple rule.
    Every exception adds complexity.
     
    I am not saying we must take it out of course it is there for all eternity but with a bit map type that is constrained to the size of an integer
    usage mask could be possibly be defined as a bit mask without altering or breaking too much. Or leave the special case and live with it. But we should not go on defining special cases when one simple type fixes this.
     
    That does not mean that special cases are actually coming but the direction of discussions suggest that the day will come.
    From the point of view of completeness KMIP is not complete, that is my point.
     
    Cheers
    John
     


    From: Mark Joseph [mailto:mark@p6r.com]

    Sent: Friday, 6 January 2017 1:41 PM
    To: John Green <JG@quintessencelabs.com>
    Cc: Anthony Berglas <anthony.berglas@cryptsoft.com>; OASIS KMIP Technical Committee <kmip@lists.oasis-open.org>
    Subject: Re: [kmip] Import operation suggestion


     

    Thanks Joe


     


          As a client vendor we don't see any issue with crypto usage mask as it is.     We have not run into any interop issues either.     Changing this in already shipping products needs a compelling issue.    I have not heard anyone else
    complain about this either.  

    Best,

    Mark Joseph


    P6R,  Inc


    408-205-0361


    mark@p6r.com


     




    On Jan 5, 2017, at 6:32 PM, John Green < JG@quintessencelabs.com > wrote:



    Then get rid of Usage Mask as a bit map from KMIP.
     
    John Green
     


    From:
    kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ]
    On Behalf Of Mark Joseph
    Sent: Friday, 6 January 2017 1:03 PM
    To: John Green < JG@quintessencelabs.com >
    Cc: Anthony Berglas < anthony.berglas@cryptsoft.com >; OASIS KMIP Technical Committee < kmip@lists.oasis-open.org >
    Subject: Re: [kmip] Import operation suggestion


     

    Actually we implement all of these already in our P11 KMIP token as custom attributes as Boolean type.   And search is no problem at all


     


    So what is the issue?


     




    Best,

    Mark Joseph


    P6R,  Inc


    408-205-0361


    mark@p6r.com


     




    On Jan 5, 2017, at 6:00 PM, John Green < JG@quintessencelabs.com > wrote:



    Thanks Mark,
     
    Yes they are but it becomes a problem when you need them all and even search for a combination. Besides the bit mask is completing the types properly
    for KMIP.
    Otherwise why did Usage Mask need to be special?
     
    Regards
    John
     


    From: Mark Joseph [ mailto:mark@p6r.com ]

    Sent: Friday, 6 January 2017 12:47 PM
    To: John Green < JG@quintessencelabs.com >
    Cc: Anthony Berglas < anthony.berglas@cryptsoft.com >; OASIS KMIP Technical Committee < kmip@lists.oasis-open.org >
    Subject: Re: [kmip] Import operation suggestion


     

    BTW All those PKCS#11 attributes you list are type Boolean not a bit mask in P11


     




    Best,

    Mark Joseph


    P6R,  Inc


    408-205-0361


    mark@p6r.com


     




    On Jan 5, 2017, at 5:16 PM, John Green < JG@quintessencelabs.com > wrote:



    Hi Anthony,
     
    Before everyone gets carried away with the PKCS#11 flags how about adding a bit map type to KMIP.
     
    Nothing annoys me more that the fact that Usage Mask is treated especially. Define a bit map data type and its special status disappears at least
    as far as an exception on what one can do with searches etc. but there is the backwards compatibility question for that.
     
    If you are going to add PKCS#11 functionality (attributes) to KMIP then either you will come up with more reasons for another special mask such as
    the storage  attributes (private, modifyable, copyable, destroyable, token) or adopt a bit map data type compatible with integer (for bit mask equivalence). Other candidates for items in a mask are SENSITIVE and EXTRACTAABLE with even ALWAYS SENSITIVE and
    NEVER EXTRACTABLE.
    Without the bit mask there will be a proliferation of attributes.
     
    If you want to make a standard that is small, concise and elegant then it should not have any exceptions. Because of Usage Mask the type system is
    obviously lacking.
     
    Well that is my view anyway.
     
    If you would like a more formal description I would be happy to supply one.
     
    John Green
     


    From:
    kmip@lists.oasis-open.org [ mailto:kmip@lists.oasis-open.org ]
    On Behalf Of Mark Joseph
    Sent: Friday, 6 January 2017 10:51 AM
    To: Anthony Berglas < anthony.berglas@cryptsoft.com >
    Cc: OASIS KMIP Technical Committee < kmip@lists.oasis-open.org >
    Subject: [kmip] Import operation suggestion


     

    Anthony


     


    On the Import operation why not define a minimum set of attributes that must be supported on both ends for the operation to succeed?   Maybe this is a way to ensure interoperability.    I think one use for this feature could be by a customer
    to export from one server vendor and move the object to a different vendors product.   

    Best,

    Mark Joseph


    P6R,  Inc


    408-205-0361


    mark@p6r.com


     




    On Jan 5, 2017, at 1:28 AM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote:





    Um, that should be PKCS#11, not POX intended!

    Anthony


     

    On Thu, Jan 5, 2017 at 7:25 PM, Anthony Berglas < anthony.berglas@cryptsoft.com > wrote:

    Submitter's message
    Hello All,

    Below is the link to a proposal to add Extractable and Sensitive flags to KMIP. They are modeled after POCS#11 in order to restrict the retrieval of key material.


    I will present this on tomorrow's call.
    -- Anthony Berglas




    Document Name :

    Non Exportable and Sensitive Attributes proposal







    No description provided.

    Download Latest Revision
    Public Download Link







    Submitter : Anthony Berglas
    Group : OASIS Key Management Interoperability Protocol (KMIP) TC
    Folder : Drafts
    Date submitted : 2017-01-05 01:25:10









    --




    Anthony Berglas Ph.D.
    Principal Engineer
    Anthony.Berglas@Cryptsoft.com








    ______________________________________________________________________
    This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
    ______________________________________________________________________



    ______________________________________________________________________
    This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
    ______________________________________________________________________



    ______________________________________________________________________
    This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
    ______________________________________________________________________



    ______________________________________________________________________
    This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
    ______________________________________________________________________