Re: [kmip] Groups - Non Exportable and Sensitive Attributes Clarification uploaded

[Anthony Berglas <anthony.berglas@cryptsoft.com>]

It is also the simple idea that if you say a key is not extractable, then allowing the flag to be changed makes the key actually extractable (by simply changing the flag).  There are some applications for which ensuring a key never ever leaves the key manager is very important.

Ideally we might have a concept of supervising users that could change these flags, as opposed to ordinary users that cannot.  But there is no such concept in KMIP, and that would lead directly to a discussion about what policy really means, which is not something that I wanted to touch here!

On Wed, Apr 5, 2017 at 6:00 AM, Bruce Rich <bar@cryptsoft.com> wrote:

Judy,

These are modeled on PKCS#11, so we are just reflecting what that standard does, rather than what one would normally do in KMIP.

We are "simply" permitting KMIP services to be performed in a manner that would accommodate PKCS#11 usage patterns ("tunneling PKCS#11 through KMIP").

And, yes, once the client/server sets something sensitive, the client can't undo that.

And if the client/server sets something non-extractable, the client can't undo that.

The setting of AlwaysSensitive means the object was created Sensitive, so could not have been retrieved without being wrapped.

The setting of NeverExtractable means the object was created such that it could not have been retrieved from the server (which would imply that it's probably used for remote cryptographic services).

Bruce

On Tue, Apr 4, 2017 at 12:25 PM, Furlong, Judith <Judith.Furlong@dell.com> wrote:

Anthony

 

I looked at the revisions you made to the proposal.  For Sensitive you added the statement once set to True it cannot be set to False and similarly for Extractable you say once set to False then it cannot be set to True.    This would mean once you make an object either sensitive or not extractable you can’t change it.  Is this really what you were trying to achieve?    What if someone wanted to change the sensitivity (or extractability) of an object – they won’t be able to use these attributes to do it.  They would have reregister the object with a new UID and the desired attribute setting.

 

Also if you go this route of saying once sensitive or not extractable you can’t change it then what is the point of having the separate Always Sensitive and Not Extractable attributes?  They would be redundant.

 

Judy

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Anthony Berglas
Sent: Tuesday, April 04, 2017 2:36 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] Groups - Non Exportable and Sensitive Attributes Clarification uploaded

 

Submitter's message
While implementing these I discovered that my specification was not as clear as it should be wrt objects created on the server and clearing the flags. So I propose that this clarification be added.
-- Anthony Berglas

Document Name: Non Exportable and Sensitive Attributes Clarification

---

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-04-03 23:35:11

 

--

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