> > > Perhaps you should ask for a better definition of "session based" first.
> > >
> > > > I believe that I would have to
> > > > disable key caching on the server, correct?
> > >
> > > You have to disable *session* caching on the server. Thus for every new
> > > connect a full SSL handshake is excercised and new key material for this
> > > connection is generated.
> >
> > Unless they meant (as I suspect they did) that you should _enable_
> > session caching!
>
> This indeed depends on what they really mean. As I said:
> Ask what this "session based" key is.
Tthey do not want to cache the session key, they want us to generate a new session
key on each connect. This is one of the lesser items on their requirements. They
don't even know what they mean by a session based key. They used "bites" instead
of "bits" in the official specification. The specs were written by some high level
administrator, not a techie. I am trying to comply with the intent of their
requirements as well as the letter of it. Holger, your initial response stating
that a key is generated on each connection was enough of an answer to satisfy the
demands. I will turn of the session caching and that will force it to generate a
new key on the connection. We have other means of identifying the client, we don't
need to use a specific key to identify them. We just need to be sure that the data
in transit is "secure".
Thanks for the help. Now I have to write the code for the server. Shouldn't take
me long at all. I already have a socket based server written, I just need to add
the SSL portion.
Sean Walker
Dingbat Designs
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
