Open Stack

Evgeny--

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.

Stephen


On Sun, Jul 20, 2014 at 4:32 AM, Evgeny Fedoruk <EvgenyF at radware.com> wrote:

>  Hi folks,
>
>
>
> In a current version of TLS capabilities RST certificate SubjectCommonName
> and SubjectAltName information is cached in a database.
>
> This may be not necessary and here is why:
>
>
>
> 1.       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.
> This is relevant for both, default container and containers used for SNI.
>
> 2.       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
> new containers only. This is stated in “Performance Impact” section of the
> RST, excepting the last statement that proposes persistency for SCN and SAN.
>
> 3.       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
> “SNI certificates list management” section of the RST.
>
> 4.       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.
>
> 5.       Back-end provisioning system may cache any certificate data,
> except private key, in case of a specific need of the vendor.
>
>
>
> IMO, There is no real need to store certificates data in Neutron database
> and manage its life cycle.
>
> Does anyone sees a reason why caching certificates’ data in Neutron
> database is critical?
>
>
>
> Thank you,
>
> Evg
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140721/eeb03325/attachment.html>