Re: SSL authentication requirements(?)

There are a number of things to achieve with the SSL encoding.  
Authentication (both client and server) are (is?) one of them.  Privacy is 
another, and doesn't require cert verification on either side.  I think it 
makes sense to have 3 levels:  privacy only (server doesn't demand client 
cert and client doesn't verify server cert, so server can use a self-signed 
cert), server authentication (client verifies server cert, so server cert 
must be from a trust chain known to the client), and client authentication 
(server verifies client cert, so client cert must be from a trust chain 
known to the server).  Each of these is useful independently, I think.

Bill

On Thursday, June 23, 2016 at 12:03:53 PM UTC-7, Jim Fulton wrote:
>
> (Meta comment, My statements should be read as questions, and my 
> questions shouldn't be read as arguments. I'm trying to work out the 
> use cases here.) 
>
> I conclude(/propose) from this discussion (and thinking about it :)) 
> that it only makes sense to use SSL with ZEO if **both** the client 
> and server are authenticated. 
>
> Initially 
> ======== 
>
> - The client can authenticate the server in 2 ways: 
>
>   - By having the server(s) ca/cert(s). 
>
>   - By checking a signed server cert and checking for a host name match. 
>
> - The server can only authenticate the client using given CAs. 
> Therefore, initially, the server will require that CAs be provided. 
>
> Later 
> ======= 
>
>  We might come up with other schemes, like: 
>
> - allowing clients to authenticate via user names and passwords over 
> the SSL connection. 
>
> - Checking cert data (e.g. subject/organizationName) of signed client 
> certs. 
>
> Thoughts? 
>
> Jim 
>
> -- 
> Jim Fulton 
> http://jimfulton.info 
>

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.