[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
Good point Mark! – for 1) I am open to suggestions on how to best expand the language for any managed object. For 2) a couple of points: In the long run I agree with security attributes being in a structure. In the short-term, the objective is to account for sensitive custom attributes that align
with the concept of designating and safeguarding security meta-data. Safeguarding is up to the client and server – designation needs to be captured in the communications. As for X and Y for custom client and server designations, this accounts for implementation specific designation of security attributes. IE Department of Defense
might say “Top Secret”, and a Health Care provider might have a “ “Patient Sensitive” designation. Both are security attributes and will have similar handling associated with them – but they are implementation specific.
In that line of thought, a Security Attribute structure as a part of KMIP 2.0 would allow flexibility to address labels, as for 1.3 – just want to start with
the concept of designation as a starting point. 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: Mark Joseph [mailto:mark@p6r.com]
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 Skype: markjoseph_sc 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]
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 Submitter's message
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]