Hi Alan,

yes this is possible.
The object returned by the NS can have a different set of security
policies in force to the NS itself.

That said if the client that  is making the request of the NS also
needs to communicate with the secure target object then the client orb
concerned needs to support a mixture of secure and insecure
communications.
However there are a number of security related caveats here that you
should be aware of:

a) The client orb should allow you to specify that you only want to use
insecure comms when talking explicitly to the naming service, and
secure comms everywhere else (assuming that your client actually has
some security requirements itself).

b) While it is theoretically possible to get a secure ior insecurely
and then invoke on the secure ior and thus establish a secure
connection - this does NOT give you exactly the same security as
getting a secure ior via secure comms in the first place.
While an appropriately configured SSL client will perform
authentication of the target object you may say "who cares?". But it is
possible that a different object may have been inserted by a malicious
3rd party that also satisfied the SSL endpoint validation that the
client had applied to it. So in a sense a malicious 3rd party could
exercise control over which element of a set  of potential targets
might be used by the client - this would be undesirable.

c) Following on from the above, the security of the NS itself is also
relevant in the same way. The act of retrieving an SSL enabled ior via
SSL from the NS is not in itself sufficient for an "operationally
secure" retrieval. For this the NS itself must have applied appropriate
security policies to enforce authentication/authorization to only allow
desired updates to the NS itself - so that the NS contents could not
have been tampered with by unauthorized clients.

As an aside : The above line of reasoning also applies to the use of
insecure corbaloc references to boot up secure object references, again
secure corbalocs should be used if your orb vendor supports them.

The problem with security is that just a little bit of security, is
also a lot of insecurity :-)

Hope this was of some help.

Regards,
   Donal Arundel

initialContext.resolve(initialContext.to_name("security/001/BasicStatelessHome"));