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] Groups - KMIP 1.3 Custom Security Attribute Proposal uploaded


Hi Chuck,

   I had a few comments:

1) Seems like you are restricting this (at least in the text you wrote) to key material.   Security attributes should be for any managed object including opaque objects.

2) The definition of the "Custom Security Attribute" to me seems a little too open ended.   You are going to have different types of these things and it makes sense to have a type field.   So it should be a structure to start off with.   Also the restriction to not have sub structures seems arbitrary and overly restrictive.   I would add a type field and define at least one of these like a security label to start off with.  You can always have a type value of opaque or "extension" if you really want that.   Why are we making this a X- and y- attribute?  Why not make it a real attribute and do this right?


Best,

Mark Joseph, Ph.D. 
President P6R, Inc 
408-205-0361 
mark@p6r.com 
Skype: markjoseph_sc 
http://www.linkedin.com/pub/mark-joseph/0/752/4b4


Chuck White <cwhite@semper-fortis.com> , 7/16/2014 7:47 AM:

Howdy David!

 

A Custom Security attribute is there to help both a client and server understand that a given piece of information is considered sensitive and should have steps taken by the client and server to secure that information upon reception.

 

Arguably this could be accomplished with plain custom attributes – but that does not map to NIST SP800-130 and 152 and the framework requirement to designate and safeguard security metadata.

 

It is also worth pointing out that this is a first step with Security Attributes that helps further align KMIP with NIST guidance.  Much like our conversation last week on string  vs integer (tag vs text value), there is much more work to go into security attributes in KMIP 2.0 and beyond.  So consider this “the thin edge of the wedge”

 

And in all of this – there is also the conversation to be had on existing attributes like Cryptographic Length, Algorithm, etc that are also considered sensitive.  Just want to make sure we collectively consider that as well.

 

Hope this helps.

 

Thanks!

 

Chuck

 

Charles White

Semper Fortis Solutions, LLC

 


This message contains information from Semper Fortis Solutions, LLC which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited.

 

From: Featherstone, David [mailto:David.Featherstone@safenet-inc.com]
Sent: Wednesday, July 16, 2014 10:22 AM
To: Chuck White; kmip@lists.oasis-open.org
Subject: RE: [kmip] Groups - KMIP 1.3 Custom Security Attribute Proposal uploaded

 

Hi Chuck

 

Would you please explain the semantic difference between Custom Security Attribute and Custom Attribute?

 

e.g. What could a client (server) achieve with zx-My-Special-Client-Attribute (zy-My-Special-Server-Attribute) that could not be achieved with x-My-Special-Client-Attribute (y-My-Special-Server-Attribute)?

                                                                                                                                                                                                                                                        

I presume that a semantic difference is intended, but I didn’t see that difference in the proposal.

 

Regards,

… Dave

 

 

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Charles White
Sent: Wednesday, July 16, 2014 8:17 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] Groups - KMIP 1.3 Custom Security Attribute Proposal uploaded

 

Submitter's message
Good morning KMIP TC!

I have uploaded the Custom Security Attributes Proposal for TC review. Feel free to ask questions.

Thanks!

Chuck
-- Charles White

Document Name: KMIP 1.3 Custom Security Attribute Proposal


Description
Update for the KMIP 1.3 Specification that reflects creation of custom z-x-
and z-y- custom security attributes that can be used for sensitive
information associated with managed objects.
Download Latest Revision
Public Download Link


Submitter: Charles White
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder: Drafts
Date submitted: 2014-07-16 05:17:00

 

The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.
 
 


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