RE: [kmip] Groups - Get Random Proposal - Marked up specification - changes only uploaded

["Lockhart, Robert" <Robert.Lockhart@thalesesec.com>]

John,

After a read through the proposed changes, most seem to cover the random object within existing operations and attributes.  This is major area of concern for me.  Get random as an operation is fine because it is a key management function and we need it for those that use a random source not associated with their key generation functions.

The random object adds potentially too much additional functionality that would need a lot of review and would have to be put up against the various specifications and certifications required for RNG functionality for applications such as payments, link encryption, etc...  This includes specifications and certifications from PCI, X9, FIPS, Common Criteria,  and others that don't come immediately to mind.  Mostly I am worried that we don't want to break vendor implementations that have been certified by trying to implement a solution that allows storage and reuse of random bits that may not be allowed under the various specs and certs.

If there is a specific use case for storing random bits, it would seem to be better to store them as secret data or opaque objects and potentially provide operations that could act on the values as needed.  This allows you to store any number of bits as needed.  This would also be best defined by a profile separate from the KMIP specification to make it optional to implement for those vendors that want to implement the full specification without potential issues stated above.  All associated attributes and operations could be defined as extensions and this keeps us out of vendor specific implementation issues and potentially causing problems with certifications.

There is no reason that this couldn't be moved into the specification in a future release if it proves to be a valid and widely used use case.  This is a good case for that "experimental" profile that Kiran had brought up previously.  If it proves out add it to the specification, if it doesn't then it can stay a profile with registered extensions.

If we do consider this we would need to do a fine tooth comb through all of the existing specifications and certifications on RNG/RBG requirements.

I would be happy to further discuss my concerns either as part of a regular call or offline as needed.

Bob L.

Robert A. (Bob) Lockhart
Chief Solution Architect - Key Management
THALES e-Security, Inc.

________________________________
From: kmip@lists.oasis-open.org [kmip@lists.oasis-open.org] On Behalf Of John Leiseboer [jl@quintessencelabs.com]
Sent: Tuesday, November 27, 2012 15:54
To: kmip@lists.oasis-open.org
Subject: [kmip] Groups - Get Random Proposal - Marked up specification - changes only uploaded

Document Name: Get Random Proposal - Marked up specification - changes only<https://www.oasis-open.org/apps/org/workgroup/kmip/document.php?document_id=47565>
________________________________
Description
A Random Object is a type of Managed Cryptographic Object. As such, a
Random Object supports much of the functionality of other Managed
Cryptographic Objects. All use cases presented to the KMIP committee for
"get random" known to the authors can be satisfied by this proposal.
Download Latest Revision<https://www.oasis-open.org/apps/org/workgroup/kmip/download.php/47565/latest/kmip-spec-v1.1-csprd02-random-02-changes.pdf>
Public Download Link<https://www.oasis-open.org/committees/document.php?document_id=47565&wg_abbrev=kmip>
________________________________
Submitter: John Leiseboer
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder: Drafts
Date submitted: 2012-11-27 15:54:48