Minor full_desc: The 2.2 spec states: "The hexadecimal strings are generated by first turning an object reference into
an IOR, and then encapsulating the IOR using the encoding rules of CDR." but it does not state which codeset is used in that
CDR encoding, since IIOP profiles contain strings (the hostname) the choice of codeset is crucial for interoperability Though most
implementors will probably use ASCII (UTF8) for that encoding a clarification seems to be required.

to Close with agreed change

Summary: Section 15.5.4[2], 15.5.3[3], 15.5.7[12]: what was meant is that Credential cannot be exported to non-security service object, can only be imported to client.

resolved close issue

Summary: Need to flow Security context information and would like to have a service context ID assigned. We need flow security contexts over IIOP.

resolved, close issue

Summary: CORBA spec sec 10.6.6 Object Service Context. We need to flow service context information for propietary services. IDs should be assigned by OMG. Prevents conflicts with future OMGassignments

resolved, close issue

Summary: In a SecurityLevel2 compliant ORB, can any object be narrowed to a SecurityLevel2:Object in order to access the additional operations?

Closed issue, same as issue # 381

Summary: Is the Current object intended to be a pseudo-object or a real object? If it"s a pseudo-object, how does the programmer narrow a CORBA::Current returned by ORB::get_current()?

Closed issue, same as issue 370

Summary: Where is the parameter of type Message defined, other than the PIDL?

closed issue, same as issue 282

Summary: Several Capule specific attributes and operations are residing on Security
Current, such as own_credentials, and principal_authenticator. This
maligns the thread model of a Current object. In convention with other
specifications there should be a seperate capusle specific interface for
these objects.

Close issue 2704 "Current contains thread specific information".

Summary: How is a SecAttribute"s value field encoded? How is the
defining_authority field encoded and what does it represent?

The specification is unclear about this in the data module chapter,
Appendix A. However, it is clear from the interoperability specification
that the defining_authority if it exists, it is an OID.

Close issue 2703 "How is a SecAttribute’s value field encoded"

Summary: also - both the spec and the idl text have a typo in the very first
> line of the Security module spec... where is says:
>
> typedef string security_name;
>
> it should say:
>
> typedef string SecurityName;

Summary: In the RFP submission, SSL/CORBA Security (orbos/97-02-04), the mechanism TAG, TAG_SSL_SEC_TRANS, was not given a tag value. It"s not defined in CORBA V2.1 either

resolved, close issue

Summary: There is a typo on page six of the SSL spec (orbos/97-02-04). Both occurences of "traget" should be changed to "target"

resolved, close issue

Summary: Security spec uses CORBA::Current, while our (transactions?) spec says CORBA::ORB::Current. Anybody involved in all 3 (CosTx, CosSec,Core)to make sure inconsistency gets cleared-up?

resolved, close issue

Summary: IDL on p225 [15-205] doesn"t inherit from AccessPolicy (disagrees with p150 [15-132] description)

already fixed, close issue

Summary: What does "" mean in "corba:g"? If it means "doesn"t have s" then why isn"t there a "-" for m?

resolved, close issue

Summary: p 145: "initiator" is undefined. It could mean the immediate parent in the call chain, or the top of the call chain

resolved, close issue

Summary: What may be missing from text is that if reply or reply fgragment is available to be sent whe complete_establish_context message is returned to client mesaage must be sent with MessageInContext.

resolved, close issue

Summary: The get_domain_policy returns a Policy yet the comment says "get policies for objects...". It"s just a little bit confusing to read plural where the singular is intended.

resolved, close issue

Summary: If it is not intended to be a complete list, then the normal way to do this is to have a value with "const" for the known values, reserving range, having range for applications

resolved, close issue

Summary: The const"s for AssociationOption are powers of two, but the only use of AssociationOption are in the sequence AssociationOptions. Presence of sequence AssociationOptions was a bug. Was removed.

resolved, close issue

Summary: "Identity domains: these are domains where objects can share a security identity as objects in the same identity domain." HUH??

resolved, close issue

Summary: Improve description of secure invocation policy rationalization

resolved, close issue

Summary: IOP and TimeBase modules are onle referenced in OMG CORBASEC, Security::SelectorSequence not defined in Security module IDL file, synyax error

closed issue, resolved

Summary: Ran across an ambiguity in definition of MessageInContext that needs to be cleared up. Is length of this "higher level" message included? It should be.

resolved, close issue

Summary: In interface SecurityLevel2::AuditChannel operation audit_write, which has CredentialsList parameter. If problem is fixed, it appears in SecurityAdmin::AuditPolicy operation set_audit_channel

This issue was fixed in revision 1.2

Summary: A.9.3 specifies series of System audit events. Should these have declarations in Security.idl or can these be assigned any values. For consistency I am leaning toward the former

resolved, close issue

Summary: Was intent for the AssociationOption, target_requires, to be the only determining factor for the client to use when making the decision to use SSL? (orbos/97-02-04 1st sentence, last para, p.6)

same as issue 714---closed

Summary: DomainAccessPolicy operation revoke_rights doesn"t specify exceptions to be thrown in case "no rights granted for that attribute"and in to-be-revoked RightsList for some/all rights

resolved, close issue

Summary: I am confused about semantics of the side-effecting override_default_* operations on CORBA::Objects. Are these overrides attached to the reference or to the destination?

resolved, close issue

Summary: In interface SecurityAdmin::AccessPolicy, operation get_effective_rights which passes in an argument of type CredentialsList

resolved, close issue

Summary: We are not clear on meaning of rights_family argument to operations grant_rights, revoke_rights, replace_rights. How is the additional argument used?

same as issue 373--closed

Summary: Shouldn"t this just operate on a single event type? I could return all selector values for all event types. but how would caller distinguish which ones were set for which event?

issue closed

Summary: Mapping Attributes to rights: what should happen if a given right in the Credentials doesn"t have a mapped right? Eithe fail the get_effective_rights or ignore it. The latter sounds better..

Just ignore it

Summary: make_domain_manager forces the default to be making a new domain manager for every new instance of this interface. There is no inverse operation. Adding a boolean for enable/disable?

resolved, close issue

Summary: Discussion on top of page is inconsistent with terms used on p.44 NoDelegation is used to select which credentials. This is either reusing same term differently (wrong) or inconsistent with use p44

resolved, close issue

Summary: Is current object intended to be pseudo object or real object? If pseude object, how does programmer narrow a CORBA::Current returned by ORB::get_current()to SecurityLevel::current?

resolved, close issue

Summary: "as at the client". I find the mixing up of what the client sees as current obscures the meaning of this.Last para of the section mixes up clients and servers.

resolved, close issue

Summary: There is only a single set_required_rights method on the RR interface in contrast to rich grant/revoke/replace set on DomAccPolicy and AuditPolicy. Should set add entries?

Close issue 375: How do add/delete RequiredRights interface entries.

Summary: Lifecycle of Credentials object isn"t clearly specified in CORBAsecurity spec rev 1.1 , e.g when can they be safely destroyed, who is responsible for such an act?

resolved, close issue

Summary: How about SecurityLevel2::Object? Can any object be narrowed to be a SecurityLevel2:Object in order to access additional operations in a SecurityLevel2 compliant ORB?

resolved, close issue

Summary: capabilities is under defined. This term is used in various ways so it should be crisply defined. Text in section 3.5.3 could be expanded.

resolved, close issue

Summary: DetectMisordering: What does this mean for a multithreaded process calling another multithreaded process? Is it meaningful?

issue closed

Summary: I recommend that the User Sponsor section be rewritten. It does not adequqtely define the User Sponsor. It talks about the User Sponsor.

resolved, close issue

Summary: In CORBASEC the two methods in MessageInterceptor interface are shown as taking an parameter of type Message. Where is this type defined?

resolved, close issue

Summary: AuditPolicy audit_needed only returns OK if selector values passed in match All. the values set in policy. Doesn"t have ANY/ALL combinator flexibility of RequiredRights. Too rigid?

resolved, close issue

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: Section 6.6.1: Object selector type isn"t something that would be stored in policy. It would be better to have Object as a seperate argument rather than to call it a selector type.

same as issue 360, close

Summary: get_required_rights takes target objref as argument. The set_required_rights takes no such argument. Does spec address the correlation of required_rights to actual targets?

same as issue359, close

Summary: Constant values for ServiceOptions defined pertain to Security Service, have nothing to do with core ORB. Move them from CORBA module to the Security module.

resolved, close issue

Summary: For interop it is essential that clients connecting to SSL-secure servers know when and how to execute SSL handshake. One submission does not mention when SSL handshake occurs.

closed issue

Summary: GIven a Policy object there is no way of telling what PolicyType it is of. Add " readonly attribute PolicyType policy_type; " to the Policy Interface.

resolved, close issue

Summary: Is there a problem in moving the const declarations out of CORBA module and into Security module?

resolved, close issue

Summary: IDL presented within the text contains unqualified names of types and interfaces..makes it hard to read and place within overall context of various modules constituting Sec spec IDL specification

resolved, close issue

Summary: How does user application get hold of object references to AccessDecision and the AuditDecision object? Spec does not provide any means for poor application to get access

resolved, close issue

Summary: Explanations associated with many operations allude to fact that they raise standard exceptions without elicidating on circumstances under which such exceptions are raised.

resolved, issue closed

Summary: PolicyType is declared as enum thus making it not easy to extend. Define it as "unsigned long", and then define the various PolicyTypes as const values

resolved, close issue

Summary: In many places in the security specification that word interface is used to refer to things that OMA would call operations. This should be fixed

resolved, close issue

Summary: IDL for the accept_security_context () method in the Vault interface is missing the Security Context output, as described in section 15.7.4.

resolved, close issue

Summary: The issue of absence of a specification of life cycle of Policy object is going to be addressed and resolved by RTF

resolved, close issue

Summary: Binding stuff is still a problem.Current object, or something in it will be used during a call to select binding. There may be several bindings that are concurrently available for an object

resolved, close issue

Summary: For delegation, it is assumed that the "intermediate object" is in fact a single object. What we want is to be able to construct an object that uses other objects in its implementation

resolved, close issue

Summary: What does the "as specified object" mean in "The construction policy controls whether a new domain is needed as well as the specified object."?

resolved, close issue

Summary: When I asked how to write a portable application, I was pointed at page 91. I don"t see how it works. What Security Policy Domain is associated with new object during BOA::create?

close issue, resolved

Summary: The SECIOP protocol definition is ambiguous about the meaning of a DiscardContext message received by a client. not specified whether server lost context before/after processing message

resolved, close issue

Summary: SECIOP servers cannot contact SECIOP clients in order to send DiscardContext messages since clients are not listening on TCP ports to receive such messages

resolved, close issue

Summary: Application object calls BOA::create to create new object reference. ORB gets construction policy associated with the creating object. There is no application or creating object>

resolved, close issue

Summary: set_privileges says "restricted to ones this principal is permitted to have." Is this adequate? Principals have several identities and privilege attributes Weren"t they restricted?

resolved, close issue

Summary: Clarify language on Non-Repudiation delivery authority. What is supported by the specification?

resolved, close issue

Summary: Section deals with the BOA. Is it the intent of the spec to only have secure BOA objects or may other OAs have secure objects? There should be some words about non-BOA OAs either hereor App: G

resolved, close issue

Summary: Provide a "day_of week" audit event selector

issue resolved, close

Summary: A SECIOP conformant server whose context has timed out may send a DiscardContext message in response to a client"s IIOP CancelRequest or MessageError message in unpredictable way

resolved, close issue

Summary: [Provide message identification information sufficient to determine which security context was used to protect MessageInContext

Close issue 339: Provide message identification information

Summary: I do not think inheritance has been acounted for properly in the audit operation parameters.

resolved, close issue

Summary: Clarify which interface the RequiredRights apply to in a chain of derived interfaces. I missed that RequiredRights can be changed dynamically

clarify specification

Summary: SecurityContext::reclaim_message uses length of supplied token as IMPLICIT parameterindicating QOP which was applied to the supplied message. Carried differently in SECIOP protocol.

Security RTF 1.5 action 9 in ptc/98-11-02

Summary: get_security_names should be able to return the mutually authenticated "identity" (??) of an object. It should have option indicating whether caller wants all supported security names.

Security RTF 1.5 action 1 in ptc/98-11-02

Summary: Set methods of DAP have ExtensibleFamily and Rightslist arguments. Rights datacontains family values already? Description on p150/151 doesn"t mention rights_family arguments.

resolved, close issue

Summary: Internally in DAPs get_effective_rights [15-131] when turning Cred attributes int0 rights using policy, I need delegation state for each attribute.They don"t contain their delegation state.

Summary: 1. There is a"request" It starts talking about partners What are partners? 2. input_buffer_complete and token_buffer_complete are flags. There is bno wat to link a series of calls together

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

Summary: The Public attribute is said to exist for the mere purpose of having at
least one credentials object with at least one attribute, if no user has
authenticated. (It is entirely debateable of whether a credentials object
should exist at all if a prinicpal does not authenticate). It appears the
only purpose for this public attribute, which is said to exist in every
Credentials instance regardless of authentication, is to be able to
"grant" rights to EVERY principal in a Domain Access Policy.

Access Policies (AP), as opposed to Domain Access Policies(DAP) (is an
extension of AP) do not have to follow the "grant/revoke/replace" scheme
of DAP.

Therefore, the Public attribute permiates the entire system just to
support an optional Domain Access Policy. In fact that most access
decisions will ignore the Public attribute if access is based on other
attributes. This situation reveals unecessary copying of data and checking
for it. Therefore the public attribute is extraneous and causes
inefficiences.

A better solution would be to confine the problem of "granting" rights
(which is in DAP only) to every principal in a "domain" to the Domain
Access Policy interface itself, such as an operation of "void
set_base_rights(RightsList rights);" and not permiate the entire system
with a useless attribute. And of course, eliminate the Public Security
Attribute all together, and all refernces to it.

Close Issue 2800 _Public

Summary: This is an issue vs the Security specification.

The reference to SSL,

ftp://ierf.cnsi.reston.va.us/internet-drafts/draft-freier-ssl-version3-
01.txt

is not valid even if you correct the domain from "ierf" to "ietf". In
fact, the Internet Draft (which was only valid for six months) has been
withdrawn and I was unable to find a copy anywhere on the web.

Possible solutions:

If someone has a copy, and copyright permissions allow, we can post it
on the OMG server and reference it even though it"s not a valid IETF
specification.

Otherwise, the spec should be updated to conform to TLS 1.0 and the
reference updated to this spec instead of the SSL draft.

In the future, IETF drafts (which have limited lifetime) should not be
normative refereces in any OMG specifications.

close issue 2789

Summary: The documentation states that the force_commit parameter given the value
of false will cause the privileges to be set at a later time. If so,
what does the out parameter "actual_privileges" return?
Is this valid only if force_commit was true and successful?

Also, boolean states a return value. I believe this should be
void, and state that exceptions will be raised with reasons for
failure.

Close Issue 1765: set_privileges

Summary: In trying to understand some problems we"re having on
our reference implementation development, I"ve run
across an inconsistency in the CORBAsec V1.2 spec.

On page 15-191, Section, 15.9.1, there is a figure
15-59 that shows the SECIOP protocol underneath the
IIOP protocol. This is contrary to my understanding
of the SECIOP architecture, which corresponds to
Figure 15-57 - where the SECIOP protocol is located
between the GIOP and IIOP protocols.

Hopefully, the problem is simply that Figure 15-59
should have "IIOP" replaced by "GIOP".

Close issue 1723: SecIOP Architecture

Summary: e have a SecurityMechandNameList get_security_names(in Object objref);
on SecurityLevel2::Current.

Since we have this capability, we should have a similar way of getting the
mechanisms and options.

Unfortunately, Security::MechandOptions struct only contains options
supported and does not have options required. The only place it is used is
for Vault::get_supported_mechs();

We should probably have another structure to handle the mechs on the
object reference. We will call this the mechanism data as not to confuse
it with MechandOptions struct.

:Current.

Summary: I have a problem discovering the semantics of using
Current.set_credentials(SecInvocationCredentials) as opposed to using an
InvocationCredentials Policy object on Current, or the target object
reference.

I believe we should deprecate set_credentials and get_credentials infavor
of InvocationCredentials and NonRepudiationCredentials Policy Objects.
This mechanism seems more in line with the the way we seem to be
traveling. So it will be consistent with the client invocation policy
model.

Or. we should put an explicit statement ordering the retrieval of
credentials at object reference creation.

1. InvocationCredentailsPolicy object off of Target object reference.
2. InvocationCredentialsPolicy object from the Current.
3. Current.get_credentials()

Close issue 2027: Principal Authenticator and Current

Summary: enum DelegationMode is defined in Security.idl and in SecurityLevel2.idl.
Both definitions are rather different:

Summary: Security 1.3 Service pages 15-87 5 Jan 1998

continue_authentication has the wrong in/out designations on
three of its four parameters. I have in, in, out, out.

It shoud be

continue_authentication(
in Opapue response_data,
inout Credentials creds,
inout Opaque continuation_data,
inout Opaque auth_specific_data
);

No Data Available

CORBA Security SECIOP.

In SECIOP, one RTF changed a field in the SECIOP Message Header
from

struct ulonglong

;

// This should be changed to unsigned long long
typedef ulonglong ContextId;

to

typedef unsigned long long ContextId;

because of the introduction of the long long type into CORBA.

This modification changes the specification the CDR encoding of the
structure, because what was compact 8 byte sequence aligned on a 4 byte
boundary. now became an 8 byte sequence aligned on an 8 byte boundary.

Each SECIOP message is preceded with a GIOP Message header, which is 12
bytes. Each SECIOP message, which is specified by a struct, starts with
the ContextId. Strict interpretation of the encoding rules makes the
SECIOP messages incompatiable, as the space between the header and the
message must now contain 4 bytes padding.

Proposed Resolution: revert back to the struct ulonglong definition.

2. The other problem I could see was related to adding firewall info to the
IOR. If a client makes a call to a server thru a firewall(s) and the server
returns (1.0) IOR's then those IOR's should have the firewall information
added to them. The other problem is that if the client calls the server and
passes an IOR with firewall info in it then there are other issues, for
example

• The IOR passed has the same firewall info as the IOR of the
  objects being called. In this case the server should strip off the firewall
  information in order to use the IOR.
• The IOR passed has different firewall info than the IOR of the
  objects being called. In this case the server should keep the firewall info.

This implies that the marshalling and unmarshalling code should add/remove
firewall info to IOR depending on the firewall information of the objects
IOR.

Subject: There is no way to find out how Tagged Components are
generated for replaceable security mechanisms. This
should be a function of the Vault, as it is the
center piece of security mechanism replaceablablity.

The Security Replaceablity interfaces are deficient in the aspect of
creating the correct components for the IIOP profile of the IOR for the
specified credentials.

The Vault::init_security_context, takes a parameter, mech_data, which is
the data component of the tagged component that was selected by the ORB
from the IOR for which the mechanism that was used in starting the secure
association.

However, analogously on the accepting side, there is no way to create a
tagged component for use in the IOR! Adding functionality to the vault
will complete the security replaceablity and fill this hole.

I suggest to add the following definitions to Security Replaceable.

#include <IOP.idl>

typedef sequence<IOP:TaggedComponent> TaggedComponentList;

interface Vault

;

The Vault produces the correct IOP tagged components for the set of
credentials specified that will be placed in the IIOP profile.

There is no definite 1 to 1 correlation between the credentials in the
given list and the tagged components generated. The vault may determine
that some credentials are redundant, irrelevant, or take precedence over
other credentials.

Summary: I believe the SecurityContext interface needs to be extended to properly
support the SECIOP::DiscardContext message.

:DiscardContext message.

Summary: Paragraph 19 of section 15.8.4.2 says:

"In this example if mechanism “mech 1” is used the target security name is “MBn1”
while the association must use integrity replay and misordering options. If mechanism
“mech 2” is used no mechanism specific security name has been specified and so
“Manchester branch” is used as the security name. The association options are
EstablishTrustInClient and Integrity."

The last sentence seems to imply that if "mech 2" is used the top-level
association options, and not the association options for "mech 2" are used.
If this is always the case, then it would seem pointless to bother
specifying association options for "mech 2" because they will never be
used. If this is the case (which would also be very strange) only when
a tag_sec_name is not present for "mech 2" this should be explained
more clearly.

Close issue 1633: Paragraph 19, section 15.8.4.2

I wanted to raise some issues with the firewall report (Firewall RTF)
related to SOCKS and IOR's.

1. If information is required for authentication with the socks server then
there is no direction given on how to get this. The solution should not be
pop up a dialog because server programs would hang. It would be nice to have
some kind of callback to the orb clients that could request password. Then
the client could decide to throw an error or pop up a dialog box.

There is a requirement to pass a sequence of IOP::TaggedComponents between
interfaces of different modules, namely SecurityReplaceable and Portable
Interceptors.

We would like to see a typedef in module IOP of:

module IOP

;

Due to different language mappings and the way they handle typdefs, a
definition in a common place is needed instead of having each module
define their own typedef for a sequence<IOP::TaggedComponent> as this
approach would provide for a difficult hand-off for the type.

The RequiredRights are confusing. (Issue raised within the RTF itself).

The Rights combinators SecAllRights and SecAnyRights are underspecified.
The notes on the implemenations of Required Rights are confusing.

Certain parameters of locality constrained interfaces were using
"sequence octet" due to the inherent fear of CORBA any's. This should not
be a problem. Also it is a serious bug as this might requires unnecessary
marshalling of data to pass into the operations of locality constrained
objects.

The interfaces, their operations and parameters that are affected follow:

PrincipalAuthenticator
authenticate
auth_data,continuation_data,auth_specific_data
continue_authentication
response_data,continuation_data,auth_specific_data
AuditDecision
audit_write
event_specific_data
Vault
acquire_credentials
auth_data,continuation_data,auth_specific_data
continue_acquisition
response_data,continuation_data,auth_specific_data

These parameters should have the type "any".

References 19, Simple GSS Negoiation
Reference 20, Simple Public Key Mechanism

are web pointers, non-existant and need to be updated.
RFC numbers exist for these, specifically RFC2478, and RFC2025
respectively.

Subject: Need MechanismType identifier for TAG_GENERIC_SEC_MECH
components.
Discussion:

Mechanism Type identifier is said to be constructed by the IOR's tagged
component identifier. However, under the current specification, all
mechanisms represented by the TAG_GENERIC_SEC_MECH still need to be
further distinguished by their security_mechanism_type identifier.

The SECIOP State machine has a problem with Discard context. The
specification currently specifies that if either side sends a Discard
Context, the context is discarded on both sides immediately. Therefore, a
client must wait to send a Discard context considering all messages sent
until it can figure out if all expected messages are received.

This situation causes too much coordination between the upper ORB layers
and the lower transport layers in SECIOP. The SECIOP state machine must be
knowledgeable about requests and whether they expect a repose. Then the
SECIOP message layer must know about GIOP message structures.

The proposed way to do this is when a Discard context is sent, it says
that no more data will be sent in that direction. The peer must respond in
kind with a Discard Context message when all data is sent back. Then the
context shall be closed.

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

Summary: I think its a formatting problem rather than a type-o. The "Privilege
Attribute (family = 1)" heading looks like it was automagically copied
to the first row of the table when the table cross a page break.

Close issue 2199. Table 15-25 Attribute Values lists family

Summary: On p. 15-140 of security/98-10-01, the description of grant_rights
says the first parameter is Attribute. The first parameter should be
SecAttribute.

Close issue 2170.

Summary: Table 15-7 has the title "Domain Access Policy (with Required Rights
Mapping)". The "(with Required Rights Mapping)" part should be
removed since it doesn"t include the required rights.

Close issue 2169. Table description incorrect

Summary:
The Policy factory operations in SecurityLevel2::Current should be
deprecated and the ORB::create_policy operation should be used for
creating QOPPolicy, MechanismsPolicy, InvocationCredentialsPolicy
instead.

:Current should be