<div dir="ltr">Hi y'all!<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 23, 2014 at 1:24 PM, Carlos Garza <span dir="ltr"><<a href="mailto:carlos.garza@rackspace.com" target="_blank">carlos.garza@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">    Right so are you advocating that the front end API never return a<br>
private key back to the user once regardless if the key was generated<br>
on the back end or sent in to the API from the user? We kind of are<br>
already are implying that they can refer to the key via a private<br>
key id.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.<br>
<br>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.</div>
<div><br></div><div>Thanks,</div><div>Stephen</div></div><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div></div>