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
