<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">OK.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Let me be more precise, extracting the information for view sake / validation would be good.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Providing values that are different than what is in the x509 is what I am opposed to.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">+1 for Carlos on the library and that it should be ubiquitously used.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I will wait for Vijay to speak for himself in this regard…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Sam.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Stephen Balukoff [mailto:sbalukoff@bluebox.net]
<br>
<b>Sent:</b> Tuesday, July 15, 2014 8:35 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">+1 to German's and Carlos' comments.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">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.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Stephen<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza <<a href="mailto:carlos.garza@rackspace.com" target="_blank">carlos.garza@rackspace.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal"><br>
On Jul 15, 2014, at 10:55 AM, Samuel Bercovici <<a href="mailto:SamuelB@Radware.com">SamuelB@Radware.com</a>><br>
wrote:<br>
<br>
> Hi,<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">><br>
><br>
> 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.<o:p></o:p></p>
</div>
<p class="MsoNormal"> 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.<br>
<br>
Carlos D. Garza<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">><br>
> -Sam.<br>
><br>
><br>
><br>
> From: Eichberger, German [mailto:<a href="mailto:german.eichberger@hp.com">german.eichberger@hp.com</a>]<br>
> Sent: Tuesday, July 15, 2014 6:43 PM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509<br>
><br>
> Hi,<br>
><br>
> My impression was that the frontend would extract the names and hand them to the driver. This has the following advantages:<br>
><br>
> · We can be sure all drivers can extract the same names<br>
> · No duplicate code to maintain<br>
> · If we ever allow the user to specify the names on UI rather in the certificate the driver doesn’t need to change.<br>
><br>
> I think I saw Adam say something similar in a comment to the code.<br>
><br>
> Thanks,<br>
> German<br>
><br>
> From: Evgeny Fedoruk [mailto:<a href="mailto:EvgenyF@Radware.com">EvgenyF@Radware.com</a>]<br>
> Sent: Tuesday, July 15, 2014 7:24 AM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509<br>
><br>
> Hi All,<br>
><br>
> Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision.<br>
> Currently, the document says:<br>
><br>
> “<br>
> For SNI functionality, tenant will supply list of TLS containers in specific<br>
> Order.<br>
> In case when specific back-end is not able to support SNI capabilities,<br>
> its driver should throw an exception. The exception message should state<br>
> that this specific back-end (provider) does not support SNI capability.<br>
> The clear sign of listener's requirement for SNI capability is<br>
> a none empty SNI container ids list.<br>
> However, reference implementation must support SNI capability.<br>
><br>
> Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames<br>
> from the certificate which will determine the hostname(s) the certificate<br>
> is associated with.<br>
><br>
> The order of SNI containers list may be used by specific back-end code,<br>
> like Radware's, for specifying priorities among certificates.<br>
> In case when two or more uploaded certificates are valid for the same DNS name<br>
> and the tenant has specific requirements around which one wins this collision,<br>
> certificate ordering provides a mechanism to define which cert wins in the<br>
> event of a collision.<br>
> Employing the order of certificates list is not a common requirement for<br>
> all back-end implementations.<br>
> “<br>
><br>
> The question is about SCN and SAN extraction from X509.<br>
> 1. Extraction of SCN/ SAN should be done while provisioning and not during TLS handshake<br>
> 2. Every back-end code/driver must(?) extract SCN and(?) SAN and use it for certificate determination for host<br>
><br>
> Please give your feedback<br>
><br>
> Thanks,<br>
> Evg<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">> _______________________________________________<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>
<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><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Stephen Balukoff <br>
Blue Box Group, LLC <br>
(800)613-4305 x807 <o:p></o:p></p>
</div>
</div>
</body>
</html>