For SSL we need a more elaborate configuration scheme. These requirements are driven directly off the J2EE CSIv2 interop specifications. In essence, we need to be able to specify these things on a per-bean level; which is probably best to do by a level of indirection, by having "named server socket configuration"s that can be referenced symbolically from the container-specific deployment descriptors.
For an SSL ServerSocket we need
protocols=(SSL),(TLS)
ciphers=<ALGORITHM,...>
hashes=<ALGORITHM,...>
keyexchanges=<ALGORITHM,...>
requireTrustClient=REQUIRE|SUPPORT|NONE
requireTrustServer=REQUIRE|SUPPORT|NONE
For both cipers, hashes and keyexchangees, the list can include the
NULL algorithm.
These properties are used to select which cipher suites should be enabled for a given socket (the idea is to simply subset the "available cipher suites" on the active SSL provider). Cipher suites are named like this:
(TLS|SSL)_<KEYEXCHANGE>_WITH_<CIPHER>_<HASH>
If there is a key exchange mechanism (other than anonymous Diffie-
Hellman "DH_anon"), then the SSL context also needs access to a key
store with a key corresponding to the key exchange mechanism, and
also a trust store used to validate the other parties. These two are
represented by
javax.net.ssl.X509TrustManager
javax.net.ssl.X509KeyManager
Both of these essentially represent a "keystore that has been opened
(password unlocked)" as well as some policies for trust and key
validation. It would make sense to simply expose instances of these
as GBeans directly in the geronimo infrastructure, and then name
these objects so they can be referenced from the SSL configuration.
The require-trust parameters determines if client/server side trust is required or just supported. In the former case, client hand-shake should be completed successfully before the socket is passed back. If either of these is REQUIRE then only cipher suites with a non-null key exchange mechanism can be allowed.
For client sockets, things are slightly more complicated because we need to support that the user is authenticated with an X509 certificate. In this case, the credentials of the user (which would typically be sitting inside the current Subject) needs to be passed along to the socket creation so that the SSL logic can create an X509KeyManager that can service this information to the server if he needs it to establish the clients credentials.
Kresten Krab Thorup [EMAIL PROTECTED]"We do not inherit the Earth from our parents, we borrow it from our children." Saint Exupery
smime.p7s
Description: S/MIME cryptographic signature
