I'Just park a madule with a stub call that I can populate with pyasn1. On Jul 24, 2014, at 10:38 AM, Evgeny Fedoruk <evge...@radware.com> wrote:
> Hi, > > Following our talk on TLS work items split, > We need to decide how will we validate/extract certificates Barbican TLS > containers. > As we agreed on IRC, the first priority should be certificates fetching. > > TLS RST describes a new common module that will be used by LBaaS API and > LBaaS drivers. > It’s proposed front-end API is currently: > 1. Ensuring Barbican TLS container existence (used by LBaaS API) > 2. Validating Barbican TLS container (used by LBaaS API) > This API will also "register" LBaaS as a container's consumer in > Barbican's repository. > POST request: > http://admin-api/v1/containers/{container-uuid}/consumers > { > "type": "LBaaS", > "URL": "https://lbaas.myurl.net/loadbalancers/<lbaas_loadbalancer_id>/" > } > > 3. Extracting SubjectCommonName and SubjectAltName information > from certificates’ X509 (used by LBaaS front-end API) > As for now, only dNSName (and optionally directoryName) types will be > extracted from > SubjectAltName sequence, > > 4. Fetching certificate’s data from Barbican TLS container > (used by provider/driver code) > > 5. Unregistering LBaaS as a consumer of the container when container is not > used by any listener any more (used by LBaaS front-end API) > > So this new module’s front-end is used by LBaaS API/drivers and its back-end > is facing Barbican API. > Please give your feedback on module API, should we merge 1 and 2? > > I will be able to start working on the new module skeleton on Sunday morning. > It will include API functions. > > TLS implementation patch has a spot where container validation should > happen:https://review.openstack.org/#/c/109035/3/neutron/db/loadbalancer/loadbalancer_dbv2.py > line 518 > After submitting the module skeleton I can make the TLS implementation patch > to depend on that module patch and use its API. > > As an alternative we might leave this job to drivers, if common module will > be not implemented > > What are your thoughts/suggestions/plans? > > Thanks, > Evg > > _______________________________________________ > 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