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

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

John,

I guess I just look at random as something that is meant to be transitory, one time use and I don't see the storage of random bits as something considered part of normal key management operations.  It could be that I don't see the use cases for storing random bits and you don't really want to use the same value twice.

As for setting rewind to false, this sounds like it is just as easily accomplished using a get random operation since you couldn't (or shouldn't) use a value twice.  I am not saying you can't create a pool of random bits, but storing them where they can be retrieved by multiple devices on purpose or accidentally seems counter intuitive.  If a device wants to use random to derive keys from then it seems that this would be just as well suited to using the secret data or opaque object and wouldn't really require a separate object type.  Based on what I read I only see these kind of use cases as vendor specific implementations and I would prefer we stay out of that business otherwise we overburden the specification.

That is what I was hoping we could use profiles for to be a little more generic in how we implement the specification while supporting specific profiles to ensure interoperability where and when needed.

You'll have to forgive me, lack of sleep and not enough coffee in the house to get me going today.

Bob L.
________________________________________
From: John Leiseboer [jl@quintessencelabs.com]
Sent: Thursday, November 29, 2012 12:02
To: Lockhart, Robert; kmip@lists.oasis-open.org
Subject: RE: [kmip] Groups - Get Random Proposal - Marked up specification - changes only uploaded

I should also have mentioned that the Q'Labs proposal specifically addresses storage of random through two attributes of the random object: Rewind Allowed, and Window Size.

When Rewind Allowed is FALSE, the server does not permit random values to be replayed.

When Window Size is set to 0, the server is not permitted to store random values.

I would expect that server implementations would set these values to match policy.

John

> -----Original Message-----
> From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On
> Behalf Of John Leiseboer
> Sent: Thursday, 29 November 2012 11:44 AM
> To: Lockhart, Robert; kmip@lists.oasis-open.org
> Subject: RE: [kmip] Groups - Get Random Proposal - Marked up
> specification - changes only uploaded
>
> 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
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kmip-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: kmip-help@lists.oasis-open.org
>