On Jul 16, 2014, at 3:49 PM, Carlos Garza <carlos.ga...@rackspace.com> wrote:
>
> On Jul 16, 2014, at 12:30 PM, Vijay Venkatachalam
> <vijay.venkatacha...@citrix.com>
> wrote:
>
> We will have the code that will parse the X509 in the API scope of the
> code. The validation I'm refering to is making sure the key matches the cert
> used and that we mandate that at a minimum the backend driver support RSA and
> that since the X509 validation is happeneing at the api layer this same
> module will also handling the extraction of the SANs. I am proposing that the
> methods that can extract the SAN SCN from the x509 be present in the api
> portion of the code and that drivers can call these methods if they need too.
> Infact I'm already working to get these extraction methods contributed to the
> PyOpenSSL project so that they will already available at a more fundemental
> layer then our nuetron/LBAAS code. At the very least I want to spec to
> declare that SAN SCN and parsing must be made available from the API layer.
> If the PyOpenSSL has the methods available at that time then I we can simply
> write wrappers for this in the API or simple write more higher level methods
> in the API module.
I meant to say bottom line I want the parsing code exposed in the API and
not duplicated in everyone elses driver.
> I am partioally open to the idea of letting the driver handle the
> behavior of the cert parsing. Although I defer this to the rest of the folks
> as I get this feeling having differn't implementations exhibiting differen't
> behavior may sound scary.
>
>>
>> I think it is best not to mention about SAN in the OpenStack
>> TLS spec. It is expected that the backend should implement according to the
>> SSL/SNI IETF spec.
>> Let’s leave the implementation/validation part to the driver. For ex.
>> NetScaler does not support SAN and the NetScaler driver could either throw
>> an error if certs with SAN are used or ignore it.
>
> How is netscaler making the decision when choosing the cert to associate
> with the SNI handshake?
>
>>
>> Does anyone see a requirement for detailing?
>>
>>
>> Thanks,
>> Vijay V.
>>
>>
>> From: Vijay Venkatachalam
>> Sent: Wednesday, July 16, 2014 8:54 AM
>> To: 'Samuel Bercovici'; 'OpenStack Development Mailing List (not for usage
>> questions)'
>> Subject: 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.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
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
