Bug 394

SSLIOP TODO list compiled from various e-mail correspondences:

        1) Add support for the DomainManager in TAO, this means:
           - Creating concrete implementations of the DomainManager
             interface, possibly as a separate service (ala ImplRepo)
           - Add support in the CORBA::Servant class to hold the list
             of DomainManagers and return them when the right
             operation is invoked.
           - Add support in the ORB core to configure the default
             DomainManager
           - Add support in the POA to set the DomainManager or create
             a new one if the policy so requires
        2) Implement the Policy objects for security.
        3) Use the DomainManager to query the policy objects and
           control SSL using that (this is dynamic btw).

        We also have to make the *whole* thing configurable, because
certain applications do not require a DomainManager and in fact, it is
too much of a nuisance to have one around....

        * We need to use BIOs to implement timeouts in CORBA requests.

        * We need to refactor the code in SSLIOP_Transport::send() and
          ACE::send() somehow, this is a real challenge, because ACE
          uses the file descriptors directly, and that is unacceptable
          for SSL.

 > > I suppose one thing we will need is a ACE_X509 class to handle the certs
 > > and things like that.
 >
 > Indeed.  That would be nice to have.  Right now we have an
 > ACE_SSL_Context class that handles all certificate related
 > operations.  Carlos, do you think it is a good idea to create an X509
 > class as Rick suggests?

        I think Rick's proposal is better than the ACE_SSL_Context
class, yet, i'm not sure if we need the ACE_X509 wrapper, IMHO we need
a use case for that.  My objective was never to wrap the complete
OpenSSL interface (after all, it is ugly "C", but it is portable and
works), my goal was to provide enough wrappers as to make it easy to
leverage other ACE components, such as Acceptor, Connector and
Reactor.

Rick H Wesson writes:
 > I am only proposing wrapping enough X509 methods to have access to the
 > certificates so that I can make a decision on weither or not I want the
 > operation to procede based on the X509_NAME which contains many attributes
 > that I could make the decision upon.

        Makes perfect sense now.  This ties to another TODO entry that
we never had the time to deal with:

        * Provide a CORBA interface to wrap the verification upcalls
          from SSL, for example:

        CORBA::Object_var tmp =
          orb->resolve_initial_reference ("SSLCurrent");
        TAO_SSL::SSLCurrent_var current =
          TAO_SSL::SSLCurrent::_narrow (tmp.in ());

        // Implement the TAO_SSL::VerificationCallback interface...
        MyCallback_i verification callback;
        current->set_verification_mode (callback._this ()); // leak..
        // TAO_SSL::VerificationCallback defines operations to check
        // if the X509 certificates are acceptable....

        // The SSLCurrent interface can be used to set other things,
        // such as, new "trusted" CA, or CRL directories...