Hello Samuel,
The team is working on adding transport key support to Barbican per this
blueprint:
https://blueprints.launchpad.net/barbican/+spec/add-wrapping-key-to-barbican-server
We would like to add convenience methods to the Python barbican client to
support this key wrapping behavior.
________________________________________
From: Samuel Bercovici [samu...@radware.com]
Sent: Thursday, May 29, 2014 7:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for
authentication
+1 to Carlos.
In addition, there should be possible for LBaaS (It might only be just the
LBaaS drivers) to get the information including the private key back so that
the backend can use it.
This means that a "trusted" communication channel between the driver and
Barbican needs to be established so that such information will be passed.
I am waiting for the "code review" in barbican to check that such capabilities
will be available.
Regards,
-Sam.
-----Original Message-----
From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
Sent: Wednesday, May 28, 2014 7:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
On May 27, 2014, at 9:13 PM, Stephen Balukoff <sbaluk...@bluebox.net>
wrote:
> Hi y'all!
>
> I would advocate that if the user asks the front-end API for the private key
> information (ie. "GET" request), what they get back is the key's modulus and
> nothing else. This should work to verify whether a given key matches a given
> cert, and doesn't break security requirements for those who are never allowed
> to actually touch private key data. And if a user added the key themselves
> through the front-end API, I think it's safe to assume the responsibility for
> keeping a copy of the key they can access lies with the user.
I'm thinking at this point all user interaction with their cert and key be
handled by barbican directly instead of through our API. It seems like we've
punted everything but the IDs to barbican. Returning the modulus is still RSA
centric though.
>
> Having said this, of course anything which spins up virtual appliances, or
> configures physical appliances is going to need access to the actual private
> key. So any back-end API(s) will probably need to have different behavior
> here.
>
> One thing I do want to point out is that with the 'transient' nature of
> back-end guests / virtual servers, it's probably going to be important to
> store the private key data in something non-volatile, like barbican's store.
> While it may be a good idea to add a feature that generates a private key and
> certificate signing request via our API someday for certain organizations'
> security requirements, one should never have the only store for this private
> key be a single virtual server. This is also going to be important if a
> certificate + key combination gets re-used in another listener in some way,
> or when horizontal scaling features get added.
I don't think our API needs to handle the CSRs it looks like barbican
aspires to do this so our API really is pretty insulated.
>
> Thanks,
> Stephen
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
> _______________________________________________
> 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
