Thanks Kelley. I will work with you to confirm that the "get random" proposal supports your use case.
Regards,
John
> -----Original Message-----
> From: [mailto:] On
> Behalf Of Kelley Burgin
> Sent: Saturday, 17 November 2012 1:20 AM
> To:
> Subject: Re: [kmip] Cryptographic Services Proposal - Next Steps
>
> To be clear, I am in support of a proposal that provides a client-to-
> server operation that allows the client to request random from a KMIP
> server (for use in the attested get proposal). I assumed until this
> week that Tim's proposal would go forward which would be sufficient
> for attested get. His proposal has a lot of stuff irrelevant to
> attested get, but if I had been able to make the call this week, I
> would have supported taking his Crypto Services proposal to ballot.
>
> Kelley
>
> On Nov 16, 2012, at 8:10 AM, Kelley Burgin wrote:
>
> > I'm interested in a "get random" operation since it's needed for the
> > current attested get proposal, and I'm willing to contribute towards
> > this.
> >
> > Kelley
> >
> > On Nov 15, 2012, at 8:09 PM, John Leiseboer wrote:
> >
> >> Those who attended today's KMIP TC meeting will know that a motion
> >> to go to ballot with the Cryptographic Services Proposal as it
> >> stands failed. I am sending this email hoping to understand how
> >> much interest there still is among KMIP TC members to proceed with
> >> a "get random" and/or "do crypto" proposal, or proposals.
> >>
> >> If there is interest, please reply to me and/or the group. If you
> >> can also indicate your willingness and ability to contribute to the
> >> development that would be good.
> >>
> >> I have said before that Q'Labs will be proceeding with development
> >> of object-based, managed "get random" using KMIP. I would prefer to
> >> see this work proceed as an approved work item in the TC. However,
> >> even if this is not the case, Q'Labs will contribute sufficient
> >> details of the implementation to allow other vendors to develop
> >> interoperable implementations.
> >>
> >> The artefacts that will be produced include a detailed use case
> >> document, specification changes, usage guide documentation, and
> >> test cases. The intent is to support all the capabilities that I
> >> have previously discussed in TC meetings, in emails, and in
> >> contributed documents. I also intend to provide a security target
> >> and analysis of the specification. The documents that I have
> >> previously contributed to the TC on this subject should give you
> >> all a good idea of the intended design and capability. But if you
> >> have questions, please ask.
> >>
> >> So again, if there is interest in either "get random", or "do
> >> crypto", please let me know; also if you are willing and able to
> >> contribute in some way.
> >>
> >> Regards,
> >> John
> >>
> >> ---------------------------------------------------------------------
> --
> >> John Leiseboer QuintessenceLabs Pty Ltd
> >> Chief Technology Officer Suite 23, Physics Building
> >> #38
> >> Phone: +61 7 5494 9291 (Qld) Science Road
> >> Phone: +61 2 6125 9498 (ACT) Australian National
> >> University
> >> Mobile: +61 409 487 510 Acton ACT 0200
> >> Fax: +61 2 6125 7180 AUSTRALIA
> >> Email: www.quintessencelabs.com
> >> ---------------------------------------------------------------------
> --
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> For additional commands, e-mail:
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
