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

[John Leiseboer <jl@quintessencelabs.com>]

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
>