When programming System SSL applications, you should consider the following.

• Will the application need to communicate with other applications using non-blocking I/O? The socket connections used for communication between System SSL applications are, by default, blocking. An application attempting to read or write to a socket is blocked until all expected data is received. This might not be desirable, because no other processing can occur while the application is waiting for a read or write to complete.
• Will the application need to prompt the client user to select a certificate from a list during the client authentication process in the SSL handshake? This behavior, if needed, can be accomplished using a registered callback routine that is invoked from inside the gsk_secure_socket_init() function call.
• Will the application need to override System SSLs default I/O callback routines to specify I/O behavior? This can be accomplished by specifying your own callback routines for receiving and sending data.
• Will application-specific data need to be available to the SSL callback routines? If needed, application-specific data can be made available using the gsk_attribute_set_buffer() and gsk_attribute_get_buffer() function calls.
• Considering both security and performance benefits, how long should SSL sessions be allowed to remain active? Security conscious applications should keep the session timeout values very low to ensure keys are generated frequently to avoid security breaches. Applications that are more performance conscious than security conscious should have longer session timeout values and a larger cache size.
• Will the application need to initiate session renegotiation? If needed, the application can call the gsk_secure_socket_misc API to renegotiate the communications session to establish a new session key or have the session cipher reset. Notification callback routines allow the application to take specific actions during a session renegotiation.
• Will the application need to add functionality to the Transport Layer Security (TLS) protocol? Applications can define a TLS extension to the SSL environment or connection by calling the gsk_attribute_set_tls_extension() function.
• Will a "Suite B Compliant" TLS V1.2 session be required? System SSL allows TLS client and server applications to specify a profile compliant with Suite B Cryptography as defined in RFC 5430: Suite B Profile for Transport Layer Security (TLS). This profile restricts the cryptographic algorithms used for the session to the set of algorithms supported by Suite B Cryptography.