Re: [kmip] Split Key proposal

[Kelley Burgin <kwburgi@tycho.ncsc.mil>]

Bob,

Thanks for your input and information on payments use cases. I am not  
familiar with the standards or practices in the payment world, but am  
certainly happy to adjust the Split Key functionality in KMIP to  
accommodate them.

> Next, something easy -- most standards require check values for the  
> end key, and support optional check values for each component.   
> Based on that, might it be prudent to modify the current  
> specification to support an optional 'CHECK VALUE' field on a key  
> split object, and the subsequent splits?  I would guess this is  
> relatively straight forward to affect from a spec standpoint -- we  
> could support an optional check value type during creation/import  
> such that it was clear how the check was performed.  In the current  
> ANSI/PCI world, a 3 byte (6 hex digit) truncated encryption result  
> using the key is prevalent, although NIST are asserting larger  
> minimum sizes for truncated authentication data which may impact us  
> in the future as the industry (HOPEFULLY) moves to stronger crypto  
> primitives.  So being crypto-agile here is probably prudent by  
> supporting a user supplied check value 'type' attribute -- so  
> perhaps the CHECK VALUE is a struct?
I don't see any problem adding an optional field for CHECK VALUE, but  
I do have a few questions about the technical details:

1. How is the CHECK VALUE used? In a Register? Get?

2. What value is encrypted to obtain the CHECK VALUE? I don't see the  
point unless it's an unpredictable or implicit value

> Finally, the hard bit -- one thing that is not clear to me from KMIP  
> is specifically how one might apply ACLs to the derived split  
> objects?  It is not an explicit technical requirement, per-se, but I  
> am just trying to think about how to solve the problem associated  
> with satisfying the "spirit of the law" with respect to having a  
> defensible story for limiting access to the split components.  Do we  
> have any current use cases describing how a key split would work?   
> Either from entering the components separately, or by having the KS  
> generate the split itself.  Your proposal is fairly clear, but I'm  
> having trouble connecting the dots in a KMIP sense.

I see the current benefit of a Split Key operation in the context of  
KMIP aware servers and clients, where the clients who end up using the  
splits can register them with the server, and the creator of the  
splits can destroy the initial copies for auditing purposes. Until  
KMIP allows an object creator to assign ownership to the object (I  
create a split key and tell the server you're the only one who can  
access it), I don't see a solution to your auditing issue in cases  
where a client who ends up using a split is not KMIP aware and the  
server generates the splits. However, from what I can tell based on  
the information you've given, your clients are capable of generating  
and distributing the splits (the example where PC1 = KS in your other  
mail), which sounds like the best solution for now.

Kelley