RE: [kmip] Groups - KMIP NIST Attribute Security uploaded

Hi Tim!

1. From a NIST perspective I interpret the following attributes as sensitive:

· Cryptographic Algorithm

· Cryptographic Length

· Cryptographic Parameters

· Cryptographic Domain Parameters

· Compromise Occurrence Date

· Compromise Date

· Revocation Reason

The Cryptographic components speak to sensitive information on how a key is constructed so in that regard it would be considered valuable information for a nefarious individual to know - plus these are all referenced as sensitive metadata from a NIST perspective.

Revocation Reason, knowing why something was revoked lends itself to be sensitive. Especially if the revoke is tied to a compromise.

Compromise information is sensitive as it is directly associated with something bad happening.

2. The following could be considered sensitive – though this type of information is pretty open as it stands

· Digest

· Digital Signature Algorithm

3. I can think of cases where this is sensitive but in general I think this is a stretch:

· Contact Information

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: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Wednesday, May 14, 2014 8:38 PM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] Groups - KMIP NIST Attribute Security uploaded

On 15/05/2014 10:08 AM, Charles White wrote:

Submitter's message
Good evening KMIP TC!

Please find the attached presentation on z type security attributes for discussion tomorrow.

Chuck, do you happen to have a list of the current attributes which might be considered sensitive in NIST terms?

i.e. is sensitive a property we should be representing against each of the existing attributes to provide an indication to the server as to what should be cryptographically protected in storage for some current attributes and not for others?

As you note KMIP already defines the mechanism for providing and returning wrapped managed objects with optional also-wrapped attributes but perhaps some additional guidance on that side of things in KMIP 1.3 would be good - however I think that is separate from the who sensitive attributes handling items - i.e. wrapping/unwrapping behaviours in general are a separate topic.

Thanks,
Tim.

kmip message