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: [GRAYMAIL] [kmip] Groups - Handling Instruction_w_Examples.xlsx uploaded

Something to definitely discuss next meeting.  I have some additional questions that can wait and maybe clarify my particular use case which was government oriented.  Also I want to be sure we are not requiring every attribute have a structure associated with it are we?  Just the ones that require additional protection based on an associated security level for a given attribute.


Bob L.


Robert A. (Bob) Lockhart

Chief Solutions Architect

Technical Directorate

Thales e-Security, Inc.


From: Mark Joseph [mailto:mark@p6r.com]
Sent: Thursday, May 05, 2016 12:45 PM
To: Lockhart, Robert <Robert.Lockhart@thalesesec.com>
Cc: Chuck White <chuck@fornetix.com>
Subject: Re: [GRAYMAIL] [kmip] Groups - Handling Instruction_w_Examples.xlsx uploaded


My understanding was that one of the primary use cases for this was multi-level secure systems.    In which case it is using mandatory access controls.    So the notion of a time out on an attribute does not make sense in that domain unless I have misunderstood your description


I do agree with your general approach let's pick a few domains and run with just those.   Using a structure like key block which can morph into different things.   


We could also make most of the structures repeatable.   So for one domain there will be just one attitude (e.g. US security label) but other domains can have multiple.    This may let us avoid the US vs Australia defense thing.   Just a thought.   


Mark Joseph

P6R,  Inc



On May 5, 2016, at 12:05 PM, Lockhart, Robert <Robert.Lockhart@thalesesec.com> wrote:



I am a bit concerned about getting too granular with tags.  While I know we have way more than enough numbers, I would prefer to keep them non-specific and if someone wants to define an extension that denotes US vs. Australia then leave it to them to define in more depth or request we add one for them.  I would lump the domains into very generic buckets similar to what you did for PII data.  If an organization wants us to define a specific domain for them, they can request it and we can decide then.  Until then I would consider keeping it simple.  Otherwise you end up with around ~206 defense/defence organization tags, 194+ health care tags and a subset of those with financial bodies you would need to include.


My suggestion would be to narrow it down to the following for simplicity (forgive my lack of international spelling as I only write American courtesy of my spell checker):

0                                  Defense/Military

1                                  Governmental Non-defense

2                                  Financial

3                                  Health Care

4                                  Personally Identifiable Information

5 – 7fffffff                     Reserved for future use

80000000 – FFFFFFFF   Custom Extensions


I would also like to see expiration or destruction date for attributes that require security in the Distribution Protection, Storage Protection section or as its own attribute in the Object Structure.  I have seen a use case that required that a portion of the information on a particular object had to go buh-bye prior to the actual object it was about (redaction anyone? – Can’t wait to display black felt pen marks on a key detail screen).  We could get long haired here and discuss a validity time versus a date on the off chance someone uses a common structure for multiple objects but I would prefer to stay away from it for now and just specify an attribute destroy date.


P.S. The 206 number comes from counting countries that don’t have global recognition like Taiwan, Kosovo, Western Sahara, Greenland, Palestine, etc… and only count the UK as one country instead of the four countries it is comprised of along with a few nation-states thrown in for fun.  The 194 number is from the number of countries or at least by worldatlas.com.


P.P.S.  The U.S. recognizes 195 countries today.


That’s it from me for today’s geography and international politics lesson.


Bob L.


Robert A. (Bob) Lockhart

Chief Solutions Architect

Technical Directorate

Thales e-Security, Inc.


From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Chuck White
Sent: Thursday, April 28, 2016 1:07 PM
To: Mark Joseph <mark@p6r.com>; kmip@lists.oasis-open.org
Subject: [kmip] RE: [GRAYMAIL] [kmip] Groups - Handling Instruction_w_Examples.xlsx uploaded


Howdy Mark!


Great points all!


Answers below


From: Mark Joseph [mailto:mark@p6r.com]
Sent: Thursday, April 28, 2016 3:43 PM
To: Chuck White <chuck@fornetix.com>; kmip@lists.oasis-open.org
Subject: Re: [GRAYMAIL] [kmip] Groups - Handling Instruction_w_Examples.xlsx uploaded


Hi Chuck,


   Two questions, just asking for clarification 


1) In the Department of Defense example the table has two security labels one at TS and one at S.   How can one piece of data have two labels?

Consider a MLS solutions where something could be authorized for Secret or Top Secret Storage that was the idea. Where there are multiple labels associated with all the authorized security levels.



2) In the US health care case, access is typically controlled by RBAC (we have a customer in this area and this seems how its done)   I just see

peoples names in the who has access no notion of access rules.

This is more of an Attribute Based Access Control (ABAC) model that takes it cues from the providers (My esteemed colleagues and Dr. Howser) and the appropriate ICD 10 tags for conditions as part of the labeling scheme that ends up being a combination of provider and condition.



3) Also in the who has access I just see text names, these are some type of user ids right?

Those are IDs and can be any type of ID….. kept those human readable for the sake of example










From: Charles White <chuck@fornetix.com>
To: <kmip@lists.oasis-open.org>
Sent: 4/28/2016 8:40 AM
Subject: [GRAYMAIL] [kmip] Groups - Handling Instruction_w_Examples.xlsx uploaded

Submitter's message
Howdy KMIP TC!

Here is the updated spreadsheet for Handling Instructions with examples for Healthcare and DoD.


-- Mr. Charles White

Document Name: Handling Instruction_w_Examples.xlsx

Updated with Department of Defense and Healthcare Example
Download Latest Revision
Public Download Link

Submitter: Mr. Charles White
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder: Drafts
Date submitted: 2016-04-28 08:40:39


Attachment: smime.p7s
Description: S/MIME cryptographic signature

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