Issue 544: SSL Protocol (sec-rev) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: For interop it is essential that clients connecting to SSL-secure servers know when and how to execute SSL handshake. One submission does not mention when SSL handshake occurs. Resolution: closed issue Revised Text: Actions taken: April 17, 1997: received issue April 17, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Date: Wed, 16 Apr 1997 14:32:57 -0700 (PDT) From: Christopher Flake Subject: SSL protocol X-Sun-Charset: US-ASCII Cc: sec-wg@omg.org Errors-To: owner-issues Sender: owner-issues X-OMG: issues To: issues According to section 5.1.11 of the SSL Security RFP, proposals shall allow independent implementations that are substitutable and interoperable. The SSL submission, 97-02-04.ps, does not mention when the SSL handshake occurs. For interoperability, it is essential that clients connecting to SSL-secure servers know when and how to execute the SSL handshake. This is especially important to clarify in regards to ORB daemon processes which activate server processes based on incoming IIOP. In other words, does the client handshake with the ORB daemon before sending the Request Header, and if so, will it then be required to do a second handshake with the object server before the Request Body is sent? Is it acceptable to send the header unprotected, followed with only a handshake with the object server? Or is the SSL context intended to be shared between the ORB daemon and the object server? Also, although we can assume that once a connection is established with an object server, subsequent invocations with that server will continue without additional handshakes, this should be stated specifically. ========================================================================== Christopher Flake __| | | flake@fsc.fujitsu.com Fujitsu Software Corporation _| | _` | | / -_) (408) 456-7119 ============================== _|= _|\__,_|_\_\___|=======================