As I recall, two operations from Principal Authenticator were added to
the Vault interface at one point a year or so ago, with the idea that the
Principal Authenticator would simply pass those calls through to Vault,
rather than implementing them directly. But paragraph [971] still says
that Principal Authenticator may be used by Vault. It's now the other way
round: P.A. uses Vault.

In fact, is Principal Authenticator still one of the replaceable
objects? Since P.A. uses Vault to do its work, it should be enough to
make Vault replaceable. It still says in paragraphs [874], [974] and
[1704] that P.A. is replaceable.

close with revised text

Security RTF 1.2 introduced (incorrectly) a data link seqencing protocol
into SECIOP. Since SECIOP is a transport protocol, meaning that it is
required to be handled over a reliable transport. The Sequencing layer was
introduced because of a missunderstaning of GIOP fragmentation, message
ordering, and the GIOP connection.

Solution: Propose to remove the SECIOP sequencing layer and references to
it.

closed with revised text

Summary:
The audit_write operation on AuditChannel still has an Opaque
type for event_specific_data. RTF 1.7 changed a bunch of these
Opaques to "any", and this one got missed. Its type needs to be
changed to "any".

close with revised text

The editorial revisions which were to address issue #1765 were not completed correctly. In section 15.5.4, the text for the parameter section of the newly added set_attributes operation still contains references to the parameters of the previous set_privileges operation. Text for the 1st, 2nd and 3rd parameters (force_commit, requested_priveleges and actual_privileges) should be removed. Also, the last parameter (actual_priveleges) should be renamed actual_attributes.

closed with revised text

The CCM spec changed some of the interfaces in the Security Service to
local ones. However, apparenlty some interfaces were not made local
that should be made local, if understand things correctly. Here are
suggested changes:

1. The SecurityLevel2::TargetCredentials interface is derived
from the Credentials object, which the CCM spec made
local. This means that the TargetCredentials interface
must also be declared local.

2. The SecurityLevel2::SecurityManager interface is apparently
locality constrained (please improve/add comment), but the
CCM spec does not change its interface to be local. This
is a problem since the
SecurityManager::remove_own_credentials() method takes a
"in Credentials creds" parameter, i.e.:

void remove_own_credentials(
in Credentials creds
);

but the CCM spec changes the Credentials interface to be
local. As such, the SecurityLevel2::SecurityManager
interface should also be local in the CCM spec in order for
the above method to be valid.

No Data Available

There are a few errors in the IDL listed in the Security Service 1.7
spec in the SecurityReplaceable module. They are:

1. In the Vault interface:

Security::AuthenticationMethodList
get_supported_authen_methods(
in Security::MechanismType mechanism;
);

There is an extraneous semi-colon after the MechanismType
parameter. This should be:

Security::AuthenticationMethodList
get_supported_authen_methods(
in Security::MechanismType mechanism
);

2. In the SecurityContext interface:

boolean process_discard_token (
in Security::OpaqueBuffer discard_token,
);

There is an extraneous comma after the OpaqueBuffer parameter. This
should be:

boolean process_discard_token (
in Security::OpaqueBuffer discard_token
);

close with revised text

The Security Service 1.7 specification:

http://www.omg.org/cgi-bin/doc?security/1999-12-02.pdf

has a "differ by case" error in the Security module IDL:

// Declarations related to Rights

struct Right

;

The name of the structure "Right" and one of it members "right" only
differ by case which of course isn't allowed in CORBA IDL.

I also checked the RTF Final Report for the 1.7 spec, and didn't
notice any resolution to this problem.

Apply revision and close issue.

I've found an inconsistency in an OMG spec. We've implemented a part of
CORBAsecurity and are now switching to a new version of Visibroker (4.0). This
version supports new OMG standards, among those some changes to IDL syntax
(e.g., case-insensitivity and keywords).

Now, there's a conflict between the CORBA 2.3 spec (3.2.3 Identifiers):

> "When comparing two identifiers to see if they collide:
> - Upper- and lower-case letters are treated as the same letter.

and the CORBAsecurity spec, even the newest version 1.5 (00-06-25):

> module Security {
> struct Right

;
> }

It is not possible to compile this spec because of "right" in
"::Security::Right" !!!!!!!
I assume this is a general conflict between old and new specifications.

What should we do in order to keep compatible? Will the Security Service spec be
changed?

Same as issue 3620. Classify as duplicate.

The definition of the syntax for IIOP over SSL is missing in the
corbaloc URL definition.

I would propose to name the protocol 'iiops'.
The protocol token would then be the same as for 'iiop'.
Is there a need to extend it with fields for 'target_supports' and
'target_requires'?

close without action

There is no standard specification for the process of authenticating a
Kerberos principal in the PrincipalAuthenticator::authenticate call. We
need specifications of authentication method constants, and a
specification for the combined authetication_method, security_name,
authentication_data, and continuation_data parameters of the authenticate
call.

No Change and close issue.

The GSS-API calls for a process_context_token function to process
context tokens. There is no such operation on the SecurityContext
interface.

Apply revisions and close issue.

On p.98 of 99-12-02, in the change to Credentials::set_privileges, the
text of the parameter descriptions did not get updated. It still
contains force_commit, requested_privileges, actual_privileges, etc.

close, same as Issue 3442