.
From: Samuel Bercovici [samu...@radware.com]
Sent: Thursday, May 29, 2014 7:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS APIsupport for
authentication
+1 to Carlos.
In
28, 2014 7:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
On May 27, 2014, at 9:13 PM, Stephen Balukoff
wrote:
> Hi y'all!
>
> I would advocate that if the user asks the
On May 27, 2014, at 9:13 PM, Stephen Balukoff
wrote:
> Hi y'all!
>
> I would advocate that if the user asks the front-end API for the private key
> information (ie. "GET" request), what they get back is the key's modulus and
> nothing else. This should work to verify whether a given key matc
ger, German [mailto:german.eichber...@hp.com]
>Sent: Saturday, May 24, 2014 12:54 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for
>authentication
>
>All,
>
>Susanne and I had a demonstration
nt Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
Right so are you advocating that the front end API never return a private
key back to the user once regardless if the key was generated on the back end
or sent in to the AP
Hi y'all!
On Fri, May 23, 2014 at 1:24 PM, Carlos Garza wrote:
> Right so are you advocating that the front end API never return a
> private key back to the user once regardless if the key was generated
> on the back end or sent in to the API from the user? We kind of are
> already are imply
>
> German
>
> -Original Message-
> From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
> Sent: Friday, May 23, 2014 1:25 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for
> authenti
ns)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
Right so are you advocating that the front end API never return a
private key back to the user once regardless if the key was generated
on the back end or sent in to the API from the user? We kind of are
already are imp
Right so are you advocating that the front end API never return a
private key back to the user once regardless if the key was generated
on the back end or sent in to the API from the user? We kind of are
already are implying that they can refer to the key via a private
key id.
On May 23, 20
Using standard formats such as PEM and PKCS12 (most people don't use
PKCS8 directly) is a good approach. Be mindful that some cryptographic
services do not provide *any* direct access to private keys (makes
sense, right?). Private keys are shielded in some hardened container and
the only way to ref
y 22, 2014 at 12:53 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
Hi Sam,
I totally agree – this will definitely reduce our scope and i
: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication
Hi Everone,
I would like to defer addressing client authentication and back-end-server
authentication for a 2nd phase - after Juno.
This means that from looking
Hi Everone,
I would like to defer addressing client authentication and back-end-server
authentication for a 2nd phase - after Juno.
This means that from looking on
https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7 , under the "SSL/TLS
Termination capabilities", not addressing 2.2 and 3.
I t
13 matches
Mail list logo
