On Jul 16, 2014, at 10:55 AM, Vijay Venkatachalam
<[email protected]>
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:[email protected]]
> 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:[email protected]]
> 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 <[email protected]>
> wrote:
>
> On Jul 15, 2014, at 10:55 AM, Samuel Bercovici <[email protected]>
> 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:[email protected]]
> > 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:[email protected]]
> > 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
> > [email protected]
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> [email protected]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
> _______________________________________________
> OpenStack-dev mailing list
> [email protected]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
