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:  [mailto:]
On Behalf Of Tim Hudson

Sent: Wednesday, May 14, 2014 8:38 PM

To: 

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.