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

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

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


Subject: RE: [kmip] Import operation suggestion


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

 


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

 


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



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