Replies Inline!
> -----Original Message----- > From: Evgeny Fedoruk [mailto:evge...@radware.com] > Sent: Thursday, December 12, 2013 5:56 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate > as first-class citizen - SSL Termination (Revised) > > Thanks for your review Vijay > > 1. Pass-Info is for the backend. Used for informing the Back-End regarding > SSL termination details. Will SSL Termination details be passed through HTTP headers? If so, what will be the http header names? Also "ssl_policy.pass_info" is a string, how does it work? Do you see a strong use case? Otherwise this can be skipped for phase-1. > 2. Added cipher-suites groups > 3. Added default policy > 4. Added SNI support. I think our model should support it, since EC2 supports > it. > 5. Renamed "Trusted Key" to "Trusted Certificate". I thought CA is obvious, > "Back-End Certificate" is an option too, What do you think? "Trusted Certificate" seems fine. "ssl_trusted_key (new)" datamodel and its properties are still not changed. You might want to rename ssl_trusted_key* => ssl_trusted_certificate* ssl_trusted_key_id also can be renamed > 6. Renamed Certificate's public key to certificate. > There are still keys used in place of certificate public_key : PEM-formatted string > Regards, > Evg > > -----Original Message----- > From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] > Sent: Wednesday, December 11, 2013 2:05 PM > To: OpenStack Development Mailing List (not for usage questions) > Cc: Abhishek Gautam > Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate > as first-class citizen - SSL Termination (Revised) > > Thanks for the detailed write-up Evg. > > What is the use of SSLPolicy.PassInfo? > Managing as individual ciphers is a pain, Can we introduce an entity called > cipher groups? This enables to provide built-in cipher groups (HIGH, LOW, > DES etc) as well. At the least we can provide this in the UI+CLI layer. > Also, it will be good to have a built-in DEFAULT ssl policy, which contains > default set of SSL protocols, ciphers etc. which is to be used when sslpolicy > is > not provided. > Is there a need for binding multiple certificates for a VIP, because SNI is > not > modeled now? We could have vip_id as the key in vip_ssl_certificate_assoc. > > Also, it will be good to have the following nomenclature corrected: > TrustedKey: This entity refers to a CA certificate, usage key can be avoided. > My suggestion is to call it CA or cacert. > SSLCertificate.PublicKey: The property contains a server certificate (actually > PublicKey + more info). My suggestion is to call the property as certificate > > Thanks, > Vijay V. > > > > -----Original Message----- > > From: Evgeny Fedoruk [mailto:evge...@radware.com] > > Sent: Sunday, December 08, 2013 10:24 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for > > certificate as first-class citizen - SSL Termination (Revised) > > > > Hi All. > > The wiki page for LBaaS SSL support was updated. > > Please see and comment > > https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL#Vip_SSL_Association > > > > Thank you! > > Evg > > > > -----Original Message----- > > From: Samuel Bercovici > > Sent: Thursday, December 05, 2013 9:14 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Cc: Evgeny Fedoruk; Samuel Bercovici > > Subject: RE: [openstack-dev] [Neutron][LBaaS] Vote required for > > certificate as first-class citizen - SSL Termination (Revised) > > > > Correct. > > > > Evgeny will update the WIKI accordingly. > > We will add a flag in the SSL Certificate to allow specifying that the > > private key can't be persisted. And in this case, the private key > > could be passed when associating the cert_id with the VIP. > > > > Regards, > > -Sam. > > > > -----Original Message----- > > From: Nachi Ueno [mailto:na...@ntti3.com] > > Sent: Thursday, December 05, 2013 8:21 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for > > certificate as first-class citizen - SSL Termination (Revised) > > > > Hi folks > > > > OK, It looks like we get consensus on > > separate resource" way. > > > > Best > > Nachi > > > > 2013/12/5 Eugene Nikanorov <enikano...@mirantis.com>: > > > Hi, > > > > > > My vote is for separate resource (e.g. 'New Model'). Also I'd like > > > to see certificate handling as a separate extension/db mixing(in > > > fact, persistence > > > driver) similar to service_type extension. > > > > > > Thanks, > > > Eugene. > > > > > > > > > On Thu, Dec 5, 2013 at 2:13 PM, Stephen Gran > > > <stephen.g...@theguardian.com> > > > wrote: > > >> > > >> Hi, > > >> > > >> Right, sorry, I see that wasn't clear - I blame lack of coffee :) > > >> > > >> I would prefer the "Revised New Model". I much prefer the ability > > >> to restore a loadbalancer from config in the event of node failure, > > >> and the ability to do basic sharing of certificates between VIPs. > > >> > > >> I think that a longer term plan may involve putting the > > >> certificates in a smarter system if we decide we want to do things > > >> like evaluate trust models, but just storing them locally for now > > >> will do most of what I think people want to do with SSL termination. > > >> > > >> Cheers, > > >> > > >> > > >> On 05/12/13 09:57, Samuel Bercovici wrote: > > >>> > > >>> Hi Stephen, > > >>> > > >>> To make sure I understand, which model is fine "Basic/Simple" or > "New". > > >>> > > >>> Thanks, > > >>> -Sam. > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Stephen Gran [mailto:stephen.g...@theguardian.com] > > >>> Sent: Thursday, December 05, 2013 8:22 AM > > >>> To: openstack-dev@lists.openstack.org > > >>> Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for > > >>> certificate as first-class citizen - SSL Termination (Revised) > > >>> > > >>> Hi, > > >>> > > >>> I would be happy with this model. Yes, longer term it might be > > >>> nice to have an independent certificate store so that when you > > >>> need to be able to validate ssl you can, but this is a good intermediate > step. > > >>> > > >>> Cheers, > > >>> > > >>> On 02/12/13 09:16, Vijay Venkatachalam wrote: > > >>>> > > >>>> > > >>>> LBaaS enthusiasts: Your vote on the revised model for SSL > Termination? > > >>>> > > >>>> Here is a comparison between the original and revised model for > > >>>> SSL > > >>>> Termination: > > >>>> > > >>>> *************** > > >>>> Original Basic Model that was proposed in summit > > >>>> *************** > > >>>> * Certificate parameters introduced as part of VIP resource. > > >>>> * This model is for basic config and there will be a model > > >>>> introduced in future for detailed use case. > > >>>> * Each certificate is created for one and only one VIP. > > >>>> * Certificate params not stored in DB and sent directly to > loadbalancer. > > >>>> * In case of failures, there is no way to restart the operation > > >>>> from details stored in DB. > > >>>> *************** > > >>>> Revised New Model > > >>>> *************** > > >>>> * Certificate parameters will be part of an independent > > >>>> certificate resource. A first-class citizen handled by LBaaS plugin. > > >>>> * It is a forwarding looking model and aligns with AWS for > > >>>> uploading server certificates. > > >>>> * A certificate can be reused in many VIPs. > > >>>> * Certificate params stored in DB. > > >>>> * In case of failures, parameters stored in DB will be used to > > >>>> restore the system. > > >>>> > > >>>> A more detailed comparison can be viewed in the following link > > >>>> > > >>>> > > > https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8F > > >>>> qVe > > >>>> ZISh07iGs/edit?usp=sharing > > >> > > >> > > >> -- > > >> Stephen Gran > > >> Senior Systems Integrator - theguardian.com Please consider the > > >> environment before printing this email. > > >> ------------------------------------------------------------------ > > >> Visit theguardian.com > > >> On your mobile, download the Guardian iPhone app > > theguardian.com/iphone > > >> and our iPad edition theguardian.com/iPad Save up to 33% by > subscribing > > to > > >> the Guardian and Observer - choose the papers you want and get full > > >> digital access. > > >> Visit subscribe.theguardian.com > > >> > > >> This e-mail and all attachments are confidential and may also be > > >> privileged. If you are not the named recipient, please notify the > > >> sender and delete the e-mail and all attachments immediately. > > >> Do not disclose the contents to another person. You may not use the > > >> information for any purpose, or store, or copy, it in any way. > > >> > > >> Guardian News & Media Limited is not liable for any computer > > >> viruses or other material transmitted with or as part of this > > >> e-mail. You should employ virus checking software. > > >> > > >> Guardian News & Media Limited > > >> > > >> A member of Guardian Media Group plc Registered Office PO Box 68164 > > >> Kings Place > > >> 90 York Way > > >> London > > >> N1P 2AP > > >> > > >> Registered in England Number 908396 > > >> > > >> ------------------------------------------------------------------- > > >> -- > > >> ----- > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev