Howdy David – Let’s start with the idea of “Mark and Control” where “Mark” defines a method to associate security attributes with an object and “Control” defines
a set of rules for handling an object based on the security attributes.
in that regard consider what we are doing is setting a up a framework to “Mark” security attributes for a client or server – “Controlling” by the client and
server becomes an internal function of the client and server and I’m not certain if that falls into the purview of KMIP. So that would become issues of compliance for the client and server vendors to implement.
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 11:00 AM
To: Chuck White; kmip@lists.oasis-open.org
Subject: RE: [kmip] Groups - KMIP 1.3 Custom Security Attribute Proposal uploaded
Thanks. I see.
So will the proposal eventually
prescribe the “steps [to be] taken by the client and server to secure [these Custom Security Attributes] upon reception”? (I’m thinking that without a prescription for the handling of Custom Security Attributes, the Custom Security Attributes would essentially
be identical to the existing Custom Attributes.)
Regards,
… Dave
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.
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.
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.