<div dir="ltr">Evgeny--<div><br></div><div>The only reason I see for storing certificate information in Neutron (and not private key information-- just the certificate) is to aid in presenting UI information to the user. Especially GUI users don't care about a certificate's UUID, they care about which hostnames it's valid for. Yes, this can be loaded on the fly whenever public certificate information is accessed, but the perception was that it would be a significant performance increase to cache it.</div>
<div><br></div><div>Stephen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 20, 2014 at 4:32 AM, Evgeny Fedoruk <span dir="ltr"><<a href="mailto:EvgenyF@radware.com" target="_blank">EvgenyF@radware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Hi folks,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">In a current version of TLS capabilities RST certificate SubjectCommonName and SubjectAltName information is cached in a database.<u></u><u></u></p>
<p class="MsoNormal">This may be not necessary and here is why:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p><u></u><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u><span dir="LTR"></span>TLS containers are immutable, meaning once a container was associated to a listener and was validated, it’s not necessary to validate the container anymore.<br>
This is relevant for both, default container and containers used for SNI.<u></u><u></u></p>
<p><u></u><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u><span dir="LTR"></span>LBaaS front-end API can check if TLS containers ids were changed for a listener as part of an update operation. Validation of containers will be done for<br>
new containers only. This is stated in “Performance Impact” section of the RST, excepting the last statement that proposes persistency for SCN and SAN.<u></u><u></u></p>
<p><u></u><span>3.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u><span dir="LTR"></span>Any interaction with Barbican API for getting containers data will be performed via a common module API only. This module’s API is mentioned in<br>
“SNI certificates list management” section of the RST.<u></u><u></u></p>
<p><u></u><span>4.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u><span dir="LTR"></span>In case when driver really needs to extract certificate information prior to the back-end system provisioning, it will do it via the common module API.<u></u><u></u></p>
<p><u></u><span>5.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u><span dir="LTR"></span>Back-end provisioning system may cache any certificate data, except private key, in case of a specific need of the vendor.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">IMO, There is no real need to store certificates data in Neutron database and manage its life cycle.
<u></u><u></u></p>
<p class="MsoNormal">Does anyone sees a reason why caching certificates’ data in Neutron database is critical?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thank you,<u></u><u></u></p>
<p class="MsoNormal">Evg<u></u><u></u></p>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
</div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div>