Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
conflict resolution is handled. I will be responding to all three of the currently ongoing mailing list discussions with this info: • Driver does not have to use SAN that is passed from API layer, but SAN will be available to drivers at the API layer. This will be mentioned explicitly in the spec. • Order is a mandatory attribute. It's intended to be used as a hint for hostname conflict resolution, but it's ultimately up to the driver to decide how to resolve the conflict. (In other words, although it is a mandatory attribute in our model, drivers are free to ignore it.) • Drivers are allowed to vary their behavior when choosing how to implement hostname conflict resolution since there is no single algorithm here that all vendors are able to support. (This is anticipated to be a rare edge case anyway.) I think Evgeny will be updating the specs to reflect this decision so that it is documented-- we hope to get ultimate approval of the spec in the next day or two. Thanks, Stephen On Wed, Jul 16, 2014 at 7:31 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: Just saw this thread after responding to the other: I'm in favor of Evgeny's proposal. It sounds like it should resolve most (if not all) of the operators', vendors' and users' concerns with regard to handling TLS certificates. Stephen On Wed, Jul 16, 2014 at 12:35 PM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 16, 2014, at 10:55 AM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Apologies for the delayed response. I am OK with displaying the certificates contents as part of the API, that should not harm. I think the discussion has to be split into 2 topics. 1. Certificate conflict resolution. Meaning what is expected when 2 or more certificates become eligible during SSL negotiation 2. SAN support Ok cool that makes more sense. #2 seems to be met by Evgeny proposal. I'll let you folks decide the conflict resolution issue #1. I will send out 2 separate mails on this. From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Tuesday, July 15, 2014 11:52 PM To: OpenStack Development Mailing List (not for usage questions); Vijay Venkatachalam Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 OK. Let me be more precise, extracting the information for view sake / validation would be good. Providing values that are different than what is in the x509 is what I am opposed to. +1 for Carlos on the library and that it should be ubiquitously used. I will wait for Vijay to speak for himself in this regard… -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Tuesday, July 15, 2014 8:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 +1 to German's and Carlos' comments. It's also worth pointing out that some UIs will definitely want to show SAN information and the like, so either having this available as part of the API, or as a standard library we write which then gets used by multiple drivers is going to be necessary. If we're extracting the Subject Common Name in any place in the code then we also need to be extracting the Subject Alternative Names at the same place. From the perspective of the SNI standard, there's no difference in how these fields should be treated, and if we were to treat SANs differently then we're both breaking the standard and setting a bad precedent. Stephen On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.com wrote: Hi, Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code. You can do what ever you want in *your* driver. The code to extract this information will be apart of the API and needs to be mentioned in the spec now. PyOpenSSL with PyASN1 are the most likely candidates. Carlos D. Garza -Sam. From: Eichberger, German [mailto:german.eichber...@hp.com] Sent: Tuesday, July 15, 2014 6:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi, My impression was that the frontend would extract the names and hand them
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
Ok, folks! Per the IRC meeting this morning, we came to the following consensus regarding how TLS certificates are handled, how SAN is handled, and how hostname conflict resolution is handled. I will be responding to all three of the currently ongoing mailing list discussions with this info: - Driver does not have to use SAN that is passed from API layer, but SAN will be available to drivers at the API layer. This will be mentioned explicitly in the spec. - Order is a mandatory attribute. It's intended to be used as a hint for hostname conflict resolution, but it's ultimately up to the driver to decide how to resolve the conflict. (In other words, although it is a mandatory attribute in our model, drivers are free to ignore it.) - Drivers are allowed to vary their behavior when choosing how to implement hostname conflict resolution since there is no single algorithm here that all vendors are able to support. (This is anticipated to be a rare edge case anyway.) I think Evgeny will be updating the specs to reflect this decision so that it is documented-- we hope to get ultimate approval of the spec in the next day or two. Thanks, Stephen On Wed, Jul 16, 2014 at 7:31 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: Just saw this thread after responding to the other: I'm in favor of Evgeny's proposal. It sounds like it should resolve most (if not all) of the operators', vendors' and users' concerns with regard to handling TLS certificates. Stephen On Wed, Jul 16, 2014 at 12:35 PM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 16, 2014, at 10:55 AM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Apologies for the delayed response. I am OK with displaying the certificates contents as part of the API, that should not harm. I think the discussion has to be split into 2 topics. 1. Certificate conflict resolution. Meaning what is expected when 2 or more certificates become eligible during SSL negotiation 2. SAN support Ok cool that makes more sense. #2 seems to be met by Evgeny proposal. I'll let you folks decide the conflict resolution issue #1. I will send out 2 separate mails on this. From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Tuesday, July 15, 2014 11:52 PM To: OpenStack Development Mailing List (not for usage questions); Vijay Venkatachalam Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 OK. Let me be more precise, extracting the information for view sake / validation would be good. Providing values that are different than what is in the x509 is what I am opposed to. +1 for Carlos on the library and that it should be ubiquitously used. I will wait for Vijay to speak for himself in this regard… -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Tuesday, July 15, 2014 8:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 +1 to German's and Carlos' comments. It's also worth pointing out that some UIs will definitely want to show SAN information and the like, so either having this available as part of the API, or as a standard library we write which then gets used by multiple drivers is going to be necessary. If we're extracting the Subject Common Name in any place in the code then we also need to be extracting the Subject Alternative Names at the same place. From the perspective of the SNI standard, there's no difference in how these fields should be treated, and if we were to treat SANs differently then we're both breaking the standard and setting a bad precedent. Stephen On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.com wrote: Hi, Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code. You can do what ever you want in *your* driver. The code to extract this information will be apart of the API and needs to be mentioned in the spec now. PyOpenSSL with PyASN1 are the most likely candidates. Carlos D. Garza -Sam. From: Eichberger, German [mailto:german.eichber...@hp.com] Sent: Tuesday, July 15, 2014 6:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi, My impression was that the frontend would extract the names and hand them to the driver. This has
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
Thanks for summarizing it, Stephen. I made changes and pushed a new patch for review. https://review.openstack.org/#/c/98640/14 Please review it. Thank you all ! Evg From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Thursday, July 17, 2014 6:20 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Ok, folks! Per the IRC meeting this morning, we came to the following consensus regarding how TLS certificates are handled, how SAN is handled, and how hostname conflict resolution is handled. I will be responding to all three of the currently ongoing mailing list discussions with this info: * Driver does not have to use SAN that is passed from API layer, but SAN will be available to drivers at the API layer. This will be mentioned explicitly in the spec. * Order is a mandatory attribute. It's intended to be used as a hint for hostname conflict resolution, but it's ultimately up to the driver to decide how to resolve the conflict. (In other words, although it is a mandatory attribute in our model, drivers are free to ignore it.) * Drivers are allowed to vary their behavior when choosing how to implement hostname conflict resolution since there is no single algorithm here that all vendors are able to support. (This is anticipated to be a rare edge case anyway.) I think Evgeny will be updating the specs to reflect this decision so that it is documented-- we hope to get ultimate approval of the spec in the next day or two. Thanks, Stephen On Wed, Jul 16, 2014 at 7:31 PM, Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote: Just saw this thread after responding to the other: I'm in favor of Evgeny's proposal. It sounds like it should resolve most (if not all) of the operators', vendors' and users' concerns with regard to handling TLS certificates. Stephen On Wed, Jul 16, 2014 at 12:35 PM, Carlos Garza carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote: On Jul 16, 2014, at 10:55 AM, Vijay Venkatachalam vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote: Apologies for the delayed response. I am OK with displaying the certificates contents as part of the API, that should not harm. I think the discussion has to be split into 2 topics. 1. Certificate conflict resolution. Meaning what is expected when 2 or more certificates become eligible during SSL negotiation 2. SAN support Ok cool that makes more sense. #2 seems to be met by Evgeny proposal. I'll let you folks decide the conflict resolution issue #1. I will send out 2 separate mails on this. From: Samuel Bercovici [mailto:samu...@radware.commailto:samu...@radware.com] Sent: Tuesday, July 15, 2014 11:52 PM To: OpenStack Development Mailing List (not for usage questions); Vijay Venkatachalam Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 OK. Let me be more precise, extracting the information for view sake / validation would be good. Providing values that are different than what is in the x509 is what I am opposed to. +1 for Carlos on the library and that it should be ubiquitously used. I will wait for Vijay to speak for himself in this regard… -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net] Sent: Tuesday, July 15, 2014 8:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 +1 to German's and Carlos' comments. It's also worth pointing out that some UIs will definitely want to show SAN information and the like, so either having this available as part of the API, or as a standard library we write which then gets used by multiple drivers is going to be necessary. If we're extracting the Subject Common Name in any place in the code then we also need to be extracting the Subject Alternative Names at the same place. From the perspective of the SNI standard, there's no difference in how these fields should be treated, and if we were to treat SANs differently then we're both breaking the standard and setting a bad precedent. Stephen On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote: On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code. You can do what ever you want in *your* driver. The code
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
I added the following comments to patch 14 but I'm not -1 it but I think its a
mistake
to assume the altSubjectName is a string type. See below.
--- Comments on patch 14 below
SubjectAltNames are not a string and should be thought
of as an array of tuples. Example
[('dNSName','www.somehost.com'),
('dirNameCN','www.somehostFromAltCN.org'),
('dirNameCN','www.anotherHostFromAltCN.org')]
for right now we only care about entries that are of type dNSName
or the entries that are of type DirName that also contain a CN in the DirName
container. All other AltNames can be ignores as they don't seem to be apart of
hostname validation in PKIX
Also we don't need to store these in the object model. since these
can be extracted from the X509 on the fly. Just be aware though that
the SubjectAltName should not be treated as a simple string but as a
list of (general_name_type,general_name_value) tuples
were really close to the end but we can't mess this one up.
I'm flexible if you want these values store in the database
or not. If we do store it in a database we need a table called
general_names that contains varchars for type and value for
now with what ever you guys want to use for the keys. to
map back to the tls_container_id. unless we want with a
firm decision on what strings in type should map to
GEN_DNS and GEN_DIRNAME CN entries from the
OpenSSL layer.
For now we can skip GEN_DIRNAME entries since RFC2818 doesn't mandate its
support and I'm not sure if fetching the CN from the DirName is in practice
now. I'm leery of using CN's from DirName entries as I can imagine people
signing differen't X509Names as a DirName with no intention of host name
validation. Excample
(dirName, 'cn=john.garza,ou=people,o=somecompany)
dNSName and DirName encodings are mentioned in RFC2459. if you want a more
formal definition.
On Jul 17, 2014, at 10:19 AM, Stephen Balukoff sbaluk...@bluebox.net wrote:
Ok, folks!
Per the IRC meeting this morning, we came to the following consensus
regarding how TLS certificates are handled, how SAN is handled, and how
hostname conflict resolution is handled. I will be responding to all three of
the currently ongoing mailing list discussions with this info:
• Driver does not have to use SAN that is passed from API layer, but
SAN will be available to drivers at the API layer. This will be mentioned
explicitly in the spec.
• Order is a mandatory attribute. It's intended to be used as a hint
for hostname conflict resolution, but it's ultimately up to the driver to
decide how to resolve the conflict. (In other words, although it is a
mandatory attribute in our model, drivers are free to ignore it.)
• Drivers are allowed to vary their behavior when choosing how to
implement hostname conflict resolution since there is no single algorithm
here that all vendors are able to support. (This is anticipated to be a rare
edge case anyway.)
I think Evgeny will be updating the specs to reflect this decision so that it
is documented-- we hope to get ultimate approval of the spec in the next day
or two.
Thanks,
Stephen
On Wed, Jul 16, 2014 at 7:31 PM, Stephen Balukoff sbaluk...@bluebox.net
wrote:
Just saw this thread after responding to the other:
I'm in favor of Evgeny's proposal. It sounds like it should resolve most (if
not all) of the operators', vendors' and users' concerns with regard to
handling TLS certificates.
Stephen
On Wed, Jul 16, 2014 at 12:35 PM, Carlos Garza carlos.ga...@rackspace.com
wrote:
On Jul 16, 2014, at 10:55 AM, Vijay Venkatachalam
vijay.venkatacha...@citrix.com
wrote:
Apologies for the delayed response.
I am OK with displaying the certificates contents as part of the API, that
should not harm.
I think the discussion has to be split into 2 topics.
1. Certificate conflict resolution. Meaning what is expected when 2
or more certificates become eligible during SSL negotiation
2. SAN support
Ok cool that makes more sense. #2 seems to be met by Evgeny proposal.
I'll let you folks decide the conflict resolution issue #1.
I will send out 2 separate mails on this.
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Tuesday, July 15, 2014 11:52 PM
To: OpenStack Development Mailing List (not for usage questions); Vijay
Venkatachalam
Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI -
Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
OK.
Let me be more precise, extracting the information for view sake /
validation would be good.
Providing values that are different than what is in the x509 is what I am
opposed to.
+1 for Carlos on the library and that it should be ubiquitously used.
I will wait for Vijay to speak for himself in this regard…
-Sam.
From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, July 15, 2014 8:35 PM
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
ultimate approval of the spec in the next day or two. Thanks, Stephen On Wed, Jul 16, 2014 at 7:31 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: Just saw this thread after responding to the other: I'm in favor of Evgeny's proposal. It sounds like it should resolve most (if not all) of the operators', vendors' and users' concerns with regard to handling TLS certificates. Stephen On Wed, Jul 16, 2014 at 12:35 PM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 16, 2014, at 10:55 AM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Apologies for the delayed response. I am OK with displaying the certificates contents as part of the API, that should not harm. I think the discussion has to be split into 2 topics. 1. Certificate conflict resolution. Meaning what is expected when 2 or more certificates become eligible during SSL negotiation 2. SAN support Ok cool that makes more sense. #2 seems to be met by Evgeny proposal. I'll let you folks decide the conflict resolution issue #1. I will send out 2 separate mails on this. From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Tuesday, July 15, 2014 11:52 PM To: OpenStack Development Mailing List (not for usage questions); Vijay Venkatachalam Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 OK. Let me be more precise, extracting the information for view sake / validation would be good. Providing values that are different than what is in the x509 is what I am opposed to. +1 for Carlos on the library and that it should be ubiquitously used. I will wait for Vijay to speak for himself in this regard… -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Tuesday, July 15, 2014 8:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 +1 to German's and Carlos' comments. It's also worth pointing out that some UIs will definitely want to show SAN information and the like, so either having this available as part of the API, or as a standard library we write which then gets used by multiple drivers is going to be necessary. If we're extracting the Subject Common Name in any place in the code then we also need to be extracting the Subject Alternative Names at the same place. From the perspective of the SNI standard, there's no difference in how these fields should be treated, and if we were to treat SANs differently then we're both breaking the standard and setting a bad precedent. Stephen On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.com wrote: Hi, Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code. You can do what ever you want in *your* driver. The code to extract this information will be apart of the API and needs to be mentioned in the spec now. PyOpenSSL with PyASN1 are the most likely candidates. Carlos D. Garza -Sam. From: Eichberger, German [mailto:german.eichber...@hp.com] Sent: Tuesday, July 15, 2014 6:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi, My impression was that the frontend would extract the names and hand them to the driver. This has the following advantages: · We can be sure all drivers can extract the same names · No duplicate code to maintain · If we ever allow the user to specify the names on UI rather in the certificate the driver doesn’t need to change. I think I saw Adam say something similar in a comment to the code. Thanks, German From: Evgeny Fedoruk [mailto:evge...@radware.com] Sent: Tuesday, July 15, 2014 7:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi All, Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision. Currently, the document says: “ For SNI functionality, tenant will supply list of TLS containers in specific Order. In case when specific back-end is not able to support SNI capabilities
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
OK. Let me be more precise, extracting the information for view sake / validation would be good. Providing values that are different than what is in the x509 is what I am opposed to. +1 for Carlos on the library and that it should be ubiquitously used. I will wait for Vijay to speak for himself in this regard… -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Tuesday, July 15, 2014 8:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 +1 to German's and Carlos' comments. It's also worth pointing out that some UIs will definitely want to show SAN information and the like, so either having this available as part of the API, or as a standard library we write which then gets used by multiple drivers is going to be necessary. If we're extracting the Subject Common Name in any place in the code then we also need to be extracting the Subject Alternative Names at the same place. From the perspective of the SNI standard, there's no difference in how these fields should be treated, and if we were to treat SANs differently then we're both breaking the standard and setting a bad precedent. Stephen On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote: On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code. You can do what ever you want in *your* driver. The code to extract this information will be apart of the API and needs to be mentioned in the spec now. PyOpenSSL with PyASN1 are the most likely candidates. Carlos D. Garza -Sam. From: Eichberger, German [mailto:german.eichber...@hp.commailto:german.eichber...@hp.com] Sent: Tuesday, July 15, 2014 6:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi, My impression was that the frontend would extract the names and hand them to the driver. This has the following advantages: · We can be sure all drivers can extract the same names · No duplicate code to maintain · If we ever allow the user to specify the names on UI rather in the certificate the driver doesn’t need to change. I think I saw Adam say something similar in a comment to the code. Thanks, German From: Evgeny Fedoruk [mailto:evge...@radware.commailto:evge...@radware.com] Sent: Tuesday, July 15, 2014 7:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi All, Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision. Currently, the document says: “ For SNI functionality, tenant will supply list of TLS containers in specific Order. In case when specific back-end is not able to support SNI capabilities, its driver should throw an exception. The exception message should state that this specific back-end (provider) does not support SNI capability. The clear sign of listener's requirement for SNI capability is a none empty SNI container ids list. However, reference implementation must support SNI capability. Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames from the certificate which will determine the hostname(s) the certificate is associated with. The order of SNI containers list may be used by specific back-end code, like Radware's, for specifying priorities among certificates. In case when two or more uploaded certificates are valid for the same DNS name and the tenant has specific requirements around which one wins this collision, certificate ordering provides a mechanism to define which cert wins in the event of a collision. Employing the order of certificates list is not a common requirement for all back-end implementations. “ The question is about SCN and SAN extraction from X509. 1. Extraction of SCN/ SAN should be done while provisioning and not during TLS handshake 2. Every back-end code/driver must(?) extract SCN and(?) SAN and use it for certificate determination for host Please give your feedback Thanks, Evg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
Thanks for your feedbacks and comments, guys This is a proposal for modified SNI management part for next RST patch: “ For SNI functionality, tenant will supply list of TLS containers in specific Order. In case when specific back-end is not able to support SNI capabilities, its driver should throw an exception. The exception message should state that this specific back-end (provider) does not support SNI capability. The clear sign of listener's requirement for SNI capability is a none empty SNI container ids list. However, reference implementation must support SNI capability. New separate module will be developed in Neutron LBaaS for Barbican TLS containers interactions. The module will have API for: 1. Ensuring Barbican TLS container existence (used by LBaaS front-end API) 2. Validating Barbican TLS container (used by LBaaS front-end API) 3. Extracting SubjectCommonName and SubjecAlternativetNames from certificates’ X509 (used by LBaaS front-end API) 4. Extracting certificate’s data from Barbican TLS container (used by provider/driver code) The module will use pyOpenSSL and PyASN1 packages. Only this new common module should be used by Neutron LBaaS code for Barbican containers interactions. Front-end LBaaS API (plugin) code will use a new developed module for validating Barbican TLS containers and extracting SubjectCommonName and SubjecAlternativetNames from certificates’ X509. When SNI settings are forwarded to the driver, this SubjectCommonName and SubjecAlternativetNames info will be attached along with each SNI container id. Driver, in its turn, can use this info for its specific SNI implementation. Any specific driver implementation may extract host names info from certificates using the mentioned above common module only, if needed. The order of SNI containers list may be used by specific back-end code, like Radware's, for specifying priorities among certificates. In case when two or more uploaded certificates are valid for the same DNS name and the tenant has specific requirements around which one wins this collision, certificate ordering provides a mechanism to define which cert wins in the event of a collision. Employing the order of certificates list is not a common requirement for all back-end implementations. “ Other parts of the RST document will be modified according to this approach. Please post your thoughts. If this is acceptable by all, I will push a new patch. Thank you, Evg From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Tuesday, July 15, 2014 8:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 +1 to German's and Carlos' comments. It's also worth pointing out that some UIs will definitely want to show SAN information and the like, so either having this available as part of the API, or as a standard library we write which then gets used by multiple drivers is going to be necessary. If we're extracting the Subject Common Name in any place in the code then we also need to be extracting the Subject Alternative Names at the same place. From the perspective of the SNI standard, there's no difference in how these fields should be treated, and if we were to treat SANs differently then we're both breaking the standard and setting a bad precedent. Stephen On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote: On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code. You can do what ever you want in *your* driver. The code to extract this information will be apart of the API and needs to be mentioned in the spec now. PyOpenSSL with PyASN1 are the most likely candidates. Carlos D. Garza -Sam. From: Eichberger, German [mailto:german.eichber...@hp.commailto:german.eichber...@hp.com] Sent: Tuesday, July 15, 2014 6:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi, My impression was that the frontend would extract the names and hand them to the driver. This has the following advantages: · We can be sure all drivers can extract the same names · No duplicate code to maintain · If we ever allow the user to specify the names on UI rather in the certificate the driver doesn’t need to change. I think I saw Adam say something similar in a comment to the code. Thanks, German From: Evgeny Fedoruk [mailto:evge...@radware.commailto:evge...@radware.com
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
Apologies for the delayed response. I am OK with displaying the certificates contents as part of the API, that should not harm. I think the discussion has to be split into 2 topics. 1. Certificate conflict resolution. Meaning what is expected when 2 or more certificates become eligible during SSL negotiation 2. SAN support I will send out 2 separate mails on this. From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Tuesday, July 15, 2014 11:52 PM To: OpenStack Development Mailing List (not for usage questions); Vijay Venkatachalam Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 OK. Let me be more precise, extracting the information for view sake / validation would be good. Providing values that are different than what is in the x509 is what I am opposed to. +1 for Carlos on the library and that it should be ubiquitously used. I will wait for Vijay to speak for himself in this regard… -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Tuesday, July 15, 2014 8:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 +1 to German's and Carlos' comments. It's also worth pointing out that some UIs will definitely want to show SAN information and the like, so either having this available as part of the API, or as a standard library we write which then gets used by multiple drivers is going to be necessary. If we're extracting the Subject Common Name in any place in the code then we also need to be extracting the Subject Alternative Names at the same place. From the perspective of the SNI standard, there's no difference in how these fields should be treated, and if we were to treat SANs differently then we're both breaking the standard and setting a bad precedent. Stephen On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote: On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code. You can do what ever you want in *your* driver. The code to extract this information will be apart of the API and needs to be mentioned in the spec now. PyOpenSSL with PyASN1 are the most likely candidates. Carlos D. Garza -Sam. From: Eichberger, German [mailto:german.eichber...@hp.commailto:german.eichber...@hp.com] Sent: Tuesday, July 15, 2014 6:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi, My impression was that the frontend would extract the names and hand them to the driver. This has the following advantages: · We can be sure all drivers can extract the same names · No duplicate code to maintain · If we ever allow the user to specify the names on UI rather in the certificate the driver doesn’t need to change. I think I saw Adam say something similar in a comment to the code. Thanks, German From: Evgeny Fedoruk [mailto:evge...@radware.commailto:evge...@radware.com] Sent: Tuesday, July 15, 2014 7:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi All, Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision. Currently, the document says: “ For SNI functionality, tenant will supply list of TLS containers in specific Order. In case when specific back-end is not able to support SNI capabilities, its driver should throw an exception. The exception message should state that this specific back-end (provider) does not support SNI capability. The clear sign of listener's requirement for SNI capability is a none empty SNI container ids list. However, reference implementation must support SNI capability. Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames from the certificate which will determine the hostname(s) the certificate is associated with. The order of SNI containers list may be used by specific back-end code, like Radware's, for specifying priorities among certificates. In case when two or more uploaded certificates are valid for the same DNS name and the tenant has specific requirements around which one wins this collision, certificate ordering provides a mechanism to define which cert wins in the event of a collision
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
On Jul 16, 2014, at 10:55 AM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Apologies for the delayed response. I am OK with displaying the certificates contents as part of the API, that should not harm. I think the discussion has to be split into 2 topics. 1. Certificate conflict resolution. Meaning what is expected when 2 or more certificates become eligible during SSL negotiation 2. SAN support Ok cool that makes more sense. #2 seems to be met by Evgeny proposal. I'll let you folks decide the conflict resolution issue #1. I will send out 2 separate mails on this. From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Tuesday, July 15, 2014 11:52 PM To: OpenStack Development Mailing List (not for usage questions); Vijay Venkatachalam Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 OK. Let me be more precise, extracting the information for view sake / validation would be good. Providing values that are different than what is in the x509 is what I am opposed to. +1 for Carlos on the library and that it should be ubiquitously used. I will wait for Vijay to speak for himself in this regard… -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Tuesday, July 15, 2014 8:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 +1 to German's and Carlos' comments. It's also worth pointing out that some UIs will definitely want to show SAN information and the like, so either having this available as part of the API, or as a standard library we write which then gets used by multiple drivers is going to be necessary. If we're extracting the Subject Common Name in any place in the code then we also need to be extracting the Subject Alternative Names at the same place. From the perspective of the SNI standard, there's no difference in how these fields should be treated, and if we were to treat SANs differently then we're both breaking the standard and setting a bad precedent. Stephen On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.com wrote: Hi, Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code. You can do what ever you want in *your* driver. The code to extract this information will be apart of the API and needs to be mentioned in the spec now. PyOpenSSL with PyASN1 are the most likely candidates. Carlos D. Garza -Sam. From: Eichberger, German [mailto:german.eichber...@hp.com] Sent: Tuesday, July 15, 2014 6:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi, My impression was that the frontend would extract the names and hand them to the driver. This has the following advantages: · We can be sure all drivers can extract the same names · No duplicate code to maintain · If we ever allow the user to specify the names on UI rather in the certificate the driver doesn’t need to change. I think I saw Adam say something similar in a comment to the code. Thanks, German From: Evgeny Fedoruk [mailto:evge...@radware.com] Sent: Tuesday, July 15, 2014 7:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi All, Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision. Currently, the document says: “ For SNI functionality, tenant will supply list of TLS containers in specific Order. In case when specific back-end is not able to support SNI capabilities, its driver should throw an exception. The exception message should state that this specific back-end (provider) does not support SNI capability. The clear sign of listener's requirement for SNI capability is a none empty SNI container ids list. However, reference implementation must support SNI capability. Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames from the certificate which will determine the hostname(s) the certificate is associated with. The order of SNI containers list may be used by specific back-end code, like Radware's, for specifying priorities
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
Just saw this thread after responding to the other: I'm in favor of Evgeny's proposal. It sounds like it should resolve most (if not all) of the operators', vendors' and users' concerns with regard to handling TLS certificates. Stephen On Wed, Jul 16, 2014 at 12:35 PM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 16, 2014, at 10:55 AM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Apologies for the delayed response. I am OK with displaying the certificates contents as part of the API, that should not harm. I think the discussion has to be split into 2 topics. 1. Certificate conflict resolution. Meaning what is expected when 2 or more certificates become eligible during SSL negotiation 2. SAN support Ok cool that makes more sense. #2 seems to be met by Evgeny proposal. I'll let you folks decide the conflict resolution issue #1. I will send out 2 separate mails on this. From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Tuesday, July 15, 2014 11:52 PM To: OpenStack Development Mailing List (not for usage questions); Vijay Venkatachalam Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 OK. Let me be more precise, extracting the information for view sake / validation would be good. Providing values that are different than what is in the x509 is what I am opposed to. +1 for Carlos on the library and that it should be ubiquitously used. I will wait for Vijay to speak for himself in this regard… -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Tuesday, July 15, 2014 8:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 +1 to German's and Carlos' comments. It's also worth pointing out that some UIs will definitely want to show SAN information and the like, so either having this available as part of the API, or as a standard library we write which then gets used by multiple drivers is going to be necessary. If we're extracting the Subject Common Name in any place in the code then we also need to be extracting the Subject Alternative Names at the same place. From the perspective of the SNI standard, there's no difference in how these fields should be treated, and if we were to treat SANs differently then we're both breaking the standard and setting a bad precedent. Stephen On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.com wrote: Hi, Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code. You can do what ever you want in *your* driver. The code to extract this information will be apart of the API and needs to be mentioned in the spec now. PyOpenSSL with PyASN1 are the most likely candidates. Carlos D. Garza -Sam. From: Eichberger, German [mailto:german.eichber...@hp.com] Sent: Tuesday, July 15, 2014 6:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi, My impression was that the frontend would extract the names and hand them to the driver. This has the following advantages: · We can be sure all drivers can extract the same names · No duplicate code to maintain · If we ever allow the user to specify the names on UI rather in the certificate the driver doesn’t need to change. I think I saw Adam say something similar in a comment to the code. Thanks, German From: Evgeny Fedoruk [mailto:evge...@radware.com] Sent: Tuesday, July 15, 2014 7:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi All, Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision. Currently, the document says: “ For SNI functionality, tenant will supply list of TLS containers in specific Order. In case when specific back-end is not able to support SNI capabilities, its driver should throw an exception. The exception message should state that this specific back-end (provider) does not support SNI capability. The clear sign of listener's requirement for SNI capability is a none empty SNI container ids list. However, reference
[openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
Hi All, Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision. Currently, the document says: For SNI functionality, tenant will supply list of TLS containers in specific Order. In case when specific back-end is not able to support SNI capabilities, its driver should throw an exception. The exception message should state that this specific back-end (provider) does not support SNI capability. The clear sign of listener's requirement for SNI capability is a none empty SNI container ids list. However, reference implementation must support SNI capability. Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames from the certificate which will determine the hostname(s) the certificate is associated with. The order of SNI containers list may be used by specific back-end code, like Radware's, for specifying priorities among certificates. In case when two or more uploaded certificates are valid for the same DNS name and the tenant has specific requirements around which one wins this collision, certificate ordering provides a mechanism to define which cert wins in the event of a collision. Employing the order of certificates list is not a common requirement for all back-end implementations. The question is about SCN and SAN extraction from X509. 1. Extraction of SCN/ SAN should be done while provisioning and not during TLS handshake 2. Every back-end code/driver must(?) extract SCN and(?) SAN and use it for certificate determination for host Please give your feedback Thanks, Evg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
Hi, My impression was that the frontend would extract the names and hand them to the driver. This has the following advantages: * We can be sure all drivers can extract the same names * No duplicate code to maintain * If we ever allow the user to specify the names on UI rather in the certificate the driver doesn't need to change. I think I saw Adam say something similar in a comment to the code. Thanks, German From: Evgeny Fedoruk [mailto:evge...@radware.com] Sent: Tuesday, July 15, 2014 7:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi All, Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision. Currently, the document says: For SNI functionality, tenant will supply list of TLS containers in specific Order. In case when specific back-end is not able to support SNI capabilities, its driver should throw an exception. The exception message should state that this specific back-end (provider) does not support SNI capability. The clear sign of listener's requirement for SNI capability is a none empty SNI container ids list. However, reference implementation must support SNI capability. Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames from the certificate which will determine the hostname(s) the certificate is associated with. The order of SNI containers list may be used by specific back-end code, like Radware's, for specifying priorities among certificates. In case when two or more uploaded certificates are valid for the same DNS name and the tenant has specific requirements around which one wins this collision, certificate ordering provides a mechanism to define which cert wins in the event of a collision. Employing the order of certificates list is not a common requirement for all back-end implementations. The question is about SCN and SAN extraction from X509. 1. Extraction of SCN/ SAN should be done while provisioning and not during TLS handshake 2. Every back-end code/driver must(?) extract SCN and(?) SAN and use it for certificate determination for host Please give your feedback Thanks, Evg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
On Jul 15, 2014, at 9:24 AM, Evgeny Fedoruk evge...@radware.com wrote: The question is about SCN and SAN extraction from X509. 1. Extraction of SCN/ SAN should be done while provisioning and not during TLS handshake Yes that makes the most sense. If some strange backend really wants to repeatedly extract this during TLS hand shake I guess they are free to do this although its pretty brain damaged since the extracted fields will always be the same. 2. Every back-end code/driver must(?) extract SCN and(?) SAN and use it for certificate determination for host No need for this to be in driver code. It was my understanding that the X509 was going to be pulled apart in the API code via pyOpenSSL(Which is what I'm working on now). Since we would be validating the key and x509 at the API layer already it made more sense to extract the SubjectAltName and SubjectSN here as well. If you want to do it in the driver as well at least use the same code thats already in the API layer. Please give your feedback 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
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
Hi, I think that the discussion have asked that obtaining information out of the x509 via the SAN field will not be defined as mandatory. For example Radware's backend extracts this information from the x509 in the (virtual) device itself, specifying dns values different than what exists in the x509 is not relevant. I think that NetScaler case, is similar with the exception (if I understand correctly) that it does not extract the values from the SAN field. Also in this case, if the front end will provide the domain name outside the x509 it will not matter. Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code. -Sam. From: Eichberger, German [mailto:german.eichber...@hp.com] Sent: Tuesday, July 15, 2014 6:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi, My impression was that the frontend would extract the names and hand them to the driver. This has the following advantages: * We can be sure all drivers can extract the same names * No duplicate code to maintain * If we ever allow the user to specify the names on UI rather in the certificate the driver doesn't need to change. I think I saw Adam say something similar in a comment to the code. Thanks, German From: Evgeny Fedoruk [mailto:evge...@radware.com] Sent: Tuesday, July 15, 2014 7:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi All, Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision. Currently, the document says: For SNI functionality, tenant will supply list of TLS containers in specific Order. In case when specific back-end is not able to support SNI capabilities, its driver should throw an exception. The exception message should state that this specific back-end (provider) does not support SNI capability. The clear sign of listener's requirement for SNI capability is a none empty SNI container ids list. However, reference implementation must support SNI capability. Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames from the certificate which will determine the hostname(s) the certificate is associated with. The order of SNI containers list may be used by specific back-end code, like Radware's, for specifying priorities among certificates. In case when two or more uploaded certificates are valid for the same DNS name and the tenant has specific requirements around which one wins this collision, certificate ordering provides a mechanism to define which cert wins in the event of a collision. Employing the order of certificates list is not a common requirement for all back-end implementations. The question is about SCN and SAN extraction from X509. 1. Extraction of SCN/ SAN should be done while provisioning and not during TLS handshake 2. Every back-end code/driver must(?) extract SCN and(?) SAN and use it for certificate determination for host Please give your feedback Thanks, Evg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.com wrote: Hi, Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code. You can do what ever you want in *your* driver. The code to extract this information will be apart of the API and needs to be mentioned in the spec now. PyOpenSSL with PyASN1 are the most likely candidates. Carlos D. Garza -Sam. From: Eichberger, German [mailto:german.eichber...@hp.com] Sent: Tuesday, July 15, 2014 6:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi, My impression was that the frontend would extract the names and hand them to the driver. This has the following advantages: · We can be sure all drivers can extract the same names · No duplicate code to maintain · If we ever allow the user to specify the names on UI rather in the certificate the driver doesn’t need to change. I think I saw Adam say something similar in a comment to the code. Thanks, German From: Evgeny Fedoruk [mailto:evge...@radware.com] Sent: Tuesday, July 15, 2014 7:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi All, Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision. Currently, the document says: “ For SNI functionality, tenant will supply list of TLS containers in specific Order. In case when specific back-end is not able to support SNI capabilities, its driver should throw an exception. The exception message should state that this specific back-end (provider) does not support SNI capability. The clear sign of listener's requirement for SNI capability is a none empty SNI container ids list. However, reference implementation must support SNI capability. Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames from the certificate which will determine the hostname(s) the certificate is associated with. The order of SNI containers list may be used by specific back-end code, like Radware's, for specifying priorities among certificates. In case when two or more uploaded certificates are valid for the same DNS name and the tenant has specific requirements around which one wins this collision, certificate ordering provides a mechanism to define which cert wins in the event of a collision. Employing the order of certificates list is not a common requirement for all back-end implementations. “ The question is about SCN and SAN extraction from X509. 1. Extraction of SCN/ SAN should be done while provisioning and not during TLS handshake 2. Every back-end code/driver must(?) extract SCN and(?) SAN and use it for certificate determination for host Please give your feedback 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
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
+1 to German's and Carlos' comments. It's also worth pointing out that some UIs will definitely want to show SAN information and the like, so either having this available as part of the API, or as a standard library we write which then gets used by multiple drivers is going to be necessary. If we're extracting the Subject Common Name in any place in the code then we also need to be extracting the Subject Alternative Names at the same place. From the perspective of the SNI standard, there's no difference in how these fields should be treated, and if we were to treat SANs differently then we're both breaking the standard and setting a bad precedent. Stephen On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.com wrote: Hi, Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code. You can do what ever you want in *your* driver. The code to extract this information will be apart of the API and needs to be mentioned in the spec now. PyOpenSSL with PyASN1 are the most likely candidates. Carlos D. Garza -Sam. From: Eichberger, German [mailto:german.eichber...@hp.com] Sent: Tuesday, July 15, 2014 6:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi, My impression was that the frontend would extract the names and hand them to the driver. This has the following advantages: · We can be sure all drivers can extract the same names · No duplicate code to maintain · If we ever allow the user to specify the names on UI rather in the certificate the driver doesn’t need to change. I think I saw Adam say something similar in a comment to the code. Thanks, German From: Evgeny Fedoruk [mailto:evge...@radware.com] Sent: Tuesday, July 15, 2014 7:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 Hi All, Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision. Currently, the document says: “ For SNI functionality, tenant will supply list of TLS containers in specific Order. In case when specific back-end is not able to support SNI capabilities, its driver should throw an exception. The exception message should state that this specific back-end (provider) does not support SNI capability. The clear sign of listener's requirement for SNI capability is a none empty SNI container ids list. However, reference implementation must support SNI capability. Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames from the certificate which will determine the hostname(s) the certificate is associated with. The order of SNI containers list may be used by specific back-end code, like Radware's, for specifying priorities among certificates. In case when two or more uploaded certificates are valid for the same DNS name and the tenant has specific requirements around which one wins this collision, certificate ordering provides a mechanism to define which cert wins in the event of a collision. Employing the order of certificates list is not a common requirement for all back-end implementations. “ The question is about SCN and SAN extraction from X509. 1. Extraction of SCN/ SAN should be done while provisioning and not during TLS handshake 2. Every back-end code/driver must(?) extract SCN and(?) SAN and use it for certificate determination for host Please give your feedback 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 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
