Howdy Mark!
As long as the exported data is leaving the defined crypto boundary of a given server in an encrypted format (TLS, SSL, IPSEC, etc) it is FIPS compliant from
my understanding.
A failure attribute per imported attribute maybe? It could be an attribute type that defines the name of the attribute that failed
Chaining Export seems like a good idea – maybe an export type? Something along the lines of a recursive export.
Thanks!
Chuck
From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
On Behalf Of Mark Joseph
Sent: Thursday, November 17, 2016 3:41 PM
To: Anthony Berglas <anthony.berglas@cryptsoft.com>; kmip@lists.oasis-open.org
Subject: [kmip] Re: [GRAYMAIL] [kmip] Groups - Import Export Operation uploaded
Hi Anthony,
I like this idea and we would add it into our client SDK library.
I do have a few questions:
(1) How do we export a chain of objects? So for example, lets say we have 2 Opaque objects on a KMIP server where one has a Child link / Parent Link between the two. I believe your description would have them exported / imported separately,
but why not as one unit? Exporting / importing as one unit will decrease the chance of links being broken. This is also relevant for Re-keyed objects.
(2) Also what happens if an importing server does not understand all the attributes? I know of a KMIP server that does not implement all 1.2 attributes.
(3) I do believe we have an issue with unique identifiers. If a customer wants to export from one vendor into a completely different vendor the scheme you suggest might lead to import failures.
(4) Can this work if a KMIP server is in FIPS mode?
From: Anthony Berglas <anthony.berglas@cryptsoft.com>
To: <kmip@lists.oasis-open.org>
Sent: 11/16/2016 11:37 PM
Subject: [GRAYMAIL] [kmip] Groups - Import Export Operation uploaded
Submitter's message
This is an update to the proposal presented at this year's face to face to enable objects to be exported and imported. It addresses the concerns that were raised.
-- Anthony Berglas