The problem is that IORs are not self securing. A security name (which I guess is the certificate name in SSL?) is included as a hint in the IOR (true?), but the system doesn't guarantee that the IOR hasn't been tampered with. So an attacker can tweak an object reference to use the security name of his own principal - something that he has the keys for - and then clients using that object reference think they are operating securely (which in a sense they are!), but are actually talking to the wrong object. All the ORB guarantees is that you are talking securely to the security name in the IOR, not that the name in the IOR is the one you want to talk to.
I understand how this works with the Kerberos and CSI-ECMA mechanisms, but I'm not sure how/if it's different with SSL. I see the problem as fundamental (there's no provable link between an object reference and the security name), so there must be an equivalent weakness in SSL based CORBA systems, true?
As E.6.2 [ed: D.6.2 in the current version of the spec] says, the onus is on the client to check the security name(s) of any target it intends to use, unless it has a trusted source of object references.
The addition of this check [ed: by client of the security name(s) of any target it intends to use] is pretty straight forward though and the ORB could do it for you. If a communicating party presents something like a wallet that not only contains credentials, but contains trustpoints (i.e. trusted certificates that aren't necessarily roots), the ORB can reject the connection if the target identity does not contain a trustpoint.
I believe that a security unaware application CAN operate in an environment where the source of object references is not necessarily trusted IF a wallet can be administered that contains trustpoints. Basically the wallet notion moves the source of trust to the wallet rather than relying on the source of object references.