Several OSSG members have expressed an interest in reviewing this functionality too.
-Rob On 28/05/2014 11:35, "Samuel Bercovici" <samu...@radware.com> wrote: >This very good news. >Please point to the code review in gerrit. > >-Sam. > > >-----Original Message----- >From: Eichberger, German [mailto:german.eichber...@hp.com] >Sent: Saturday, May 24, 2014 12:54 AM >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for >authentication > >All, > >Susanne and I had a demonstration of life code by HP's Barbican team >today for certificate storage. The code is submitted for review in the >Barbican project. > >Barbican will be able to store all the certificate parts (cert, key, pwd) >in a secure "container". We will follow up with more details next week -- > >So in short all we need to store in LBaaS is the container-id. The rest >will come from Barbican and the user will interact straight with Barbican >to upload/manage his certificates, keys, pwd... > >This functionality/use case also is considered in the Marketplace / >Murano project -- making the need for a central certificate storage in >OpenStack a bit more pressing. > >German > >-----Original Message----- >From: Carlos Garza [mailto:carlos.ga...@rackspace.com] >Sent: Friday, May 23, 2014 1:25 PM >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for >authentication > > Right so are you advocating that the front end API never return a >private key back to the user once regardless if the key was generated on >the back end or sent in to the API from the user? We kind of are already >are implying that they can refer to the key via a private key id. > > >On May 23, 2014, at 9:11 AM, John Dennis <jden...@redhat.com> > wrote: > >> Using standard formats such as PEM and PKCS12 (most people don't use >> PKCS8 directly) is a good approach. > > We had to deal with PKCS8 manually in our CLB1.0 offering at >rackspace. Too many customers complained. > >> Be mindful that some cryptographic >> services do not provide *any* direct access to private keys (makes >> sense, right?). Private keys are shielded in some hardened container >> and the only way to refer to the private key is via some form of name >> association. > > Were anticipating referring the keys via a barbican key id which will >be named later. > > >> Therefore your design should never depend on having access to a >> private key and > > But we need access enough to transport the key to the back end >implementation though. > >> should permit having the private key stored in some type of secure key >> storage. > > A secure repository for the private key is already a requirement that >we are attempting to meat with barbican. > > >> -- >> John >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev