Hi y'all!
On Fri, May 23, 2014 at 1:24 PM, Carlos Garza <carlos.ga...@rackspace.com>wrote: > 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. > 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. 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. 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