Open Stack

This is good news, thanks for sharing German!

Kyle

On Fri, May 23, 2014 at 4:54 PM, Eichberger, German
<german.eichberger at 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.garza at 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 <jdennis at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev