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

[John Leiseboer <jl@quintessencelabs.com>]

Hi Bob,

I'm not sure that I fully understand your concerns. Is it basically that servers can store the random that they generate? If this is your concern, then this is easily handled through policy on the server: simply have a policy that does not allow storage of random. With this policy in place, a Get operation on a random object simply generates and returns the random. At the same time, the server - as with other managed crypto objects - supports templates, usage limits, etc. that allow applications to access random in a similar and consistent manner to other cryptographic objects managed by the server.

Or is your concern about the addition of any "get random" capability on the server? As this would also - I imagine - require appropriate review against the various specifications and certifications that you mention below.

John

> -----Original Message-----
> From: Lockhart, Robert [mailto:Robert.Lockhart@thalesesec.com]
> Sent: Thursday, 29 November 2012 11:24 AM
> To: John Leiseboer; kmip@lists.oasis-open.org
> Subject: RE: [kmip] Groups - Get Random Proposal - Marked up
> specification - changes only uploaded
> 
> 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
> 
>