Re: draft agenda for San Jose meeting

David Brownell - JavaSoft writes:
> 
> Minor correction (it's late); sorry ...
> 
> > One more protocol issue ... I've never seen an explanation about why
> > the "change cipher spec" record is necessary.  It seems like all that's
> > needed is the ability to flush the handshake messages which have been
> > queued, since I don't see any cases where the next legal handshake
> > message isn't predictable from the current protocol state.
> 
> More like:  "I don't see any cases where you won't know that the
> next handshake message from the peer must be 'Finished', even without
> this 'change cipher spec' message."

On the client side when setting up a new session (rather than
continuing an existing one) the handshake message before the Finished
could be a ClientKeyExchange, or a CertificateVerify if the
client was asked to authenticate itself.


However the changeCipherSpec message is there, and is an alert
rather than a handshake message, in order to make better seperation
between the record layer (which has to know about the change)
and the handshake layer above it.

Theoretically you could invent a new handshake protocol, and the
underlying record layer wouldn't care (and the code wouldn't have to
be changed) as long as your new handshake included changeCipherSpecs
at the appropriate time.

-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF

Received on Tuesday, 3 December 1996 11:02:58 UTC