Summary: What criteria does does client use when choosing to use SSL?Was intent for AssociationOption, target_requires to be only determining factor for client decision to use SSL?

Close issue 714: SSL/CORBA-How does client chose to use SSL

Summary: Currently there is now way to examine the credentials of a server.
We would like this capability in order to examine the fact that
we have authenticated who we expected to contact.

Close issue 2440 "Need to get Received Credentials from the Server"

Summary: Severity: Yes
Security 1.5:
Issue: Interoperability. SECIOP needs an internet address designation.

The current specification says that SECIOP goes under GIOP and over IIOP.
This is misguided, as IIOP is really just a term for GIOP over TCP/IP.

SECIOP doesn"t really have to be over TCP/IP, but it might be helpful
to think of it that way. However, like SSL, we need away to separate
SECIOP over TCP/IP and GIOP over TCP/IP. If SECIOP cannot have it"s own
profile, since now ONE profile can represent multiple protocols, then we
need a way specify a different internet address (different port), but also
maybe a different interface card (multihomed hosts).

Close issue 2437 "SECIOP needs an internet address designation"

Summary: As we realized during the RTF 1.5, we have erroneous text for
operations that describe passing nil/NULL for parameters. I"ve
tracked down a few more:

p. 15-96 [495]: For the requested_privileges parameter, the phrase "(A
null attribute set requests default attributes.)" should read "A
zero length attribute list requests the default attributes."

p. 15-130 [666]: For the data_included_in_token parameter, the phrase
"(may be null)" should read "(may be a zero length sequence)".

p. 15-156 [784]: The object_type (which is a repository id) parameter
is allowed to be nil. It should read "If this is the empty string,
all types are implied."

p. 15-157 [787]: Same as above.

p. 15-171 [846]: For the mechanism parameter, the phrase "Normally
NULL" should read "Normally the empty string".

p. 15-171 [846]: For the chain_bindings parameter, the phrase
"Normally NULL (zero length)" should read "Normally a zero length
octet sequence".

Close issue 2344: More nil/NULL argument that need to be removed:

Summary: In ptc/98-12-03 on page 355 paragraph 1689 (second bullet), the
examples given for Integrity Violations include trapdoors and
viruses; however, just below that in paragraph 1691, "Inclusion
of rogue code in the system, which gives access to sensitive
information" is explicitly identified as being outside of the
scope of the specification. Since both trapdoors and viruses
are examples of rogue code, these two paragraphs contradict
each other.

Close issue 2452 "Need OID’s exposed in Vault."

Summary: The channel bindings are described for operations, init_security_context,
and accept_security_context in SecurityReplaceable::Vault, as
Security::Opaque with no specification of what this looks like.

This is a severe problem with the "Replaceability" of vaults, as SecIOP
would like to place the channel bindings to any security context.

Since the Vault, and SecurityContext were modeled after the GSS, I suggest
that we adopt the GSS channel binding structure.

Close issue 2451 "Channel Bindings are underspecified"

Summary: Should Vault::accept_security_context() take a CredentialsList parameter
or a Credentials (not a list) like every other operations in Vault?

Close issue 2260: accept_security_context() creds parameter

Summary: t is possible that in
the final resolutions document we forgot to say that the type of the
"del" parameter of set_delegation should be
Security::DelegationDirective and not SecurityLevel2::DelegationMode.
This change was not specified either for the IDL or for the description
of the set_credentials operation. Also DelegationMode should be removed from SecurityLevel2.

Close issue 2259: del parameter .....