[chef] Re: Re: Re: New Authentication in Chef 0.8

[dreamcat four < >]

If i remember correctly, ssl uses the handshake in order to establish
a secret session key for the entirety of the HTTP session. Session key
encrypts the network traffic at the level of the TCP connection.

I think Adam is right not to copy verbatim the ssl system, because its
used for a different purpose. The way the hash is passed (unencrypted)
within an http x-header is clearly a different mechanism to the way
SSL encrypts its information. For example you might choose to encrypt
all chef traffic over SSL in addition to the chef authentication
mechanism. (if i've understood it right?)

Most importantly, the chef authentication mechanism identifies the
originator of the api call by its client ID and allows chef to
determine the level of client privileges allowed. If the client ID
isn't registered in couchdb and known to the chef-server, then the api
request is rejected.

The explanation given in the wiki seems clear enough. If you also have
existing knowledge about SSL Certificates side of things, then it can
be more confusing to explain things in terms of SSL / referring back
to SSL. Saying that chef calls out to the openssl library is fair
enough though. Because, well. Its good to be familiar with the openssl
library.

:)

On Wed, Feb 10, 2010 at 9:59 PM, Miguel Cabeça 
<
 >
 wrote:
> It seems to me that you've implemented something already offered for free 
> with the traditional SSL handshake. And the validation key is a 
> substitution of the CA-siging-the-certificate-to-be-presented-by-the-client 
> stuff.
>
> What am I seeing wrong here?
>
> Best Regards
>
> Miguel Cabeça