In the X509TrustManager Interface section,

    ...is defined, then the TrustManagerFactory attempts to find a file
    using the filename specified by that system property, and uses
    that file for the KeyStore. If the javax.net.ssl.keyStorePassword
    system property is also defined

This should say javax.net.ssl.trustStorePassword, not keyStorePassword.

Just above this:

    Note: If no KeyStore parameter is passed to the SunJSSE default
    "SunX509" TrustManagerFactory,

This should say "If a null KeyStore parameter is passed..."

###@###.### 2002-04-10

Also, we should document two system properties in
the Release Notes. I don't think these should go in the JSSE documentation
yet, as these are very specific to our implementation, and
may not be around for very long.


===============================================================

A bug in Sun's JSSE v1.0, v1.0.1, and v1.0.2 was causing SSL_DHE_DSS_*
cipher suites to encode DSA signatures incorrectly when those
signatures were used as part of a DSA server key exchange message.
 
There was a interoperability system property introduced in Sun's JSSE 1.0.2
that controls which behavior is active.
                                                  
    com.sun.net.ssl.dhKeyExchangeFix
     
        true: Use the correct behavior.
        false: Use the broken behavior. (Interoperable with
                JSSE 1.0, 1.0.1, and 1.0.2)
 
The SunJSSE provider in J2SDK 1.4 and above also has this property for
backwards compatibility with earlier JSSE's, and its default value is
true.
 
        Release Default Behavior Switch
        ======= ================ ======
        J2SDK 1.4.0/above correct true
         
        JSSE 1.0.3 correct true
        JSSE 1.0.2 broken false
        JSSE 1.0.1 broken N/A
        JSSE 1.0 broken N/A
         
===============================================================
 
When exchanging an RSA-based PreMasterSecret, RFC 2246-TLSv1 specifies
that the PreMasterSecret message is to contain the latest (newest)
version supported by the client. Some SSL implementations send the
current session's version number (incorrect), other send the correct
message. Most servers accept messages of either type.
 
This is only an issue if the client requests a particular protocol
version that the server doesn't support, and as a result the server
requests a lower version number and then only accepts
one message type (either correct or incorrect).
 
Servers using the SunJSSE in J2SDK 1.4.1 accepts messages of
either type.
 
Servers using the SunJSSE in J2SDK 1.4.0's JDK accepts the incorrect message
type only. (Most popular web browsers currently send the incorrect message.)
 
Clients using the SunJSSE in J2SDK 1.4.1 can control which message type
is active by using a system property.
 
    com.sun.net.ssl.rsaPreMasterSecretFix
     
        true: Use the correct RFC 2246 behavior
        false: Use the incorrect behavior

Given that most servers accept either message type, for
interoperability with servers using SunJSSE in J2SDK 1.4.0 the current
default is false.
         
        Release Default Behaviour Switch
        ======= ================= ======
        J2SDK 1.4.1 incorrect false
        J2SDK 1.4.0 incorrect N/A


###@###.### 2002-04-25