This is good news, thanks for sharing German! Kyle
On Fri, May 23, 2014 at 4:54 PM, Eichberger, German <german.eichber...@hp.com> wrote: > 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
