Issues for Security 1.8 and 1.9 Revision Task Forces discussion list

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 138: Message Level Interceptors (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: closed issue, same as issue 282
Revised Text:
Actions taken:
September 27, 1996: received issue
December 4, 1996: closed issue, same as issue 282
December 4, 1996: closed issue; Duplicate or Merged

Discussion:

Issue 151: Current object question (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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()?

Resolution: Closed issue, same as issue 370
Revised Text:
Actions taken:
October 3, 1996: received issue
December 13, 1996: Closed issue, same as issue 370
December 13, 1996: closed issue; Duplicate or Merged

Discussion:

Issue 152: SecurityLevel2::Object (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: Closed issue, same as issue # 381
Revised Text:
Actions taken:
October 3, 1996: received issue
December 13, 1996: Closed issue, same as issue # 381
December 13, 1996: closed issue; Duplicate or Merged

Discussion:

Issue 180: CORBASEC IDL files in Appendix A (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: closed issue, resolved
Revised Text: 1. Timebase module is defined in Time Service, IOP module is defined in IIOP spec. 2. Could not find this problem in Chapter 15 so presumably has been fixed in Revision 1.1
Actions taken:
October 11, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 282: Message Level interceptors (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
October 21, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 307: Service Context ID Assignment (scenario 1) (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 13, 1996: received issue
December 4, 1996: closed issue (doc# omg/96-11-03 takes care of it)
December 4, 1996: closed issue; Duplicate or Merged

Discussion:

Issue 308: Service Context ID Assignment (scenario 2) (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Issue 337: Provide a "day_of_week" audit event selector (sec-rev)

Click here for this issue's archive.
Nature: ENHANCEMENT
Severity: MEDIUM
Summary:

Summary: Provide a "day_of week" audit event selector

Resolution: issue resolved, close
Revised Text: Appendix A IDL will also have to be updated if this change is made. Bob"s recommendation: implement1. In Table 15-9 add a new row with:
Actions taken:
November 18, 1996: received issue
March 2, 1999: closed issue

Discussion:

Issue 338: Clarify language on Non-Repudiation delivery authority (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: MEDIUM
Summary:

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

Resolution: resolved, close issue
Revised Text: I couldn"t find a reference to "NR delivery authority". Anne, can you give a page reference? Bob"s recommendation: not sure yet.
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 339: Provide message identification information (sec-rev)

Click here for this issue's archive.
Nature: ENHANCEMENT
Severity: Serious
Summary:

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

Resolution: Close issue 339: Provide message identification information
Revised Text:
Actions taken:
November 18, 1996: received issue
April 20, 1999:
May 4, 2000: closed issue

Discussion:

We agreed to just close this issue since protection information  is not quite tied to the message, but the transport of the  message, i.e. SECIOP, SSL, etc.

Issue 340: Improve description of secure invocation policy rationalization (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Serious
Summary:

Summary: Improve description of secure invocation policy rationalization

Resolution: resolved, close issue
Revised Text: Fixed in Rev 1.1
Actions taken:
November 18, 1996: received issue
December 13, 1996: closed issue

Discussion:

Issue 341: get_security_names issue (sec-rev)

Click here for this issue's archive.
Nature: INTERPRETATION
Severity: Serious
Summary:

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.

Resolution: Security RTF 1.5 action 1 in ptc/98-11-02
Revised Text:
Actions taken:
November 18, 1996: received issue
November 13, 1998: closed issue

Discussion:

Issue 342: SECIOP servers cannot contact SECIOP clients (sec-rev)

Click here for this issue's archive.
Nature: ENHANCEMENT
Severity: Critical
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 343: SECIOP protocol definition (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Critical
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 344: SECIOP conformant server timed out (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Critical
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 345: Definition of MessageInContext needs to be cleared (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Critical
Summary:

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.

Resolution: resolved, close issue
Revised Text: Fixed in Security Revision 1.1
Actions taken:
November 18, 1996: received issue
April 23, 1997: closed issue

Discussion:

Issue 346: Missing explanation of the use of MessageInContext message (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity: CRITICAL
Summary:

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.

Resolution: resolved, close issue
Revised Text: Fixed in Security Revision 1.1
Actions taken:
November 18, 1996: received issue
April 23, 1997: closed issue

Discussion:

Issue 347: QOP discovered in SecurityContext (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Serious
Summary:

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.

Resolution: Security RTF 1.5 action 9 in ptc/98-11-02
Revised Text: Bob"s recommendation: discuss
Actions taken:
November 18, 1996: received issue
November 13, 1998: closed issue

Discussion:

Issue 348: Intermediate objects (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Medium
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
January 21, 1997: downgraded from crical to medium
March 26, 1998: closed issue

Discussion:

 closed issue

Issue 349: How do I get to a specific binding while making an invokation? (sec-rev)

Click here for this issue's archive.
Nature: CLARIFICATION
Severity: Serious
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
January 21, 1997: downgraded to "Serious"
March 26, 1998: closed issue

Discussion:

 closed issue

Issue 350: set_privileges adequate? (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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?

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 351: Clarify what creating object is (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Critical
Summary:

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>

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 352: What Security policy Domain during BOA::create? (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Medium
Summary:

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?

Resolution: close issue, resolved
Revised Text:
Actions taken:
November 18, 1996: received issue
January 21, 1997: downgraded from critical to medium
March 26, 1998: closed issue

Discussion:

 closed issue

Issue 353: Meaning of "as specified object" (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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."?

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 354: Is it intent of specification to only secure BOAs? (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 355: Use of NoDelegation is inconsistent with terms used on p 44 (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 356: Is enum EvidenceType intended to be a complete list? (sec-rev)

Click here for this issue's archive.
Nature: Interpretation
Severity: medium
Summary:

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

Resolution: resolved, close issue
Revised Text: EvidenceType is supposed to be a complete list hence it is OK to use enum for it.
Actions taken:
November 18, 1996: received issue
December 13, 1996: closed issue

Discussion:

Issue 357: The generate_token and verify_evidence methods have problems (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Medium
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 18, 1996: received issue
January 21, 1997: downgraded from critical to medium

Discussion:

Issue 358: make_domain_manager issue (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Serious
Summary:

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?

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 359: Which interface apply RequiredRights to (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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

Resolution: clarify specification
Revised Text: Clarify specification. Pg. 15-134 [683] end of paragraph on get_required_rights, interface_name parameter, add text:
Actions taken:
November 18, 1996: received issue
January 21, 1997: downgraded from critical to serious
March 2, 1999: closed issue

Discussion:

Issue 360: Inheritance not properly accounted in audit operation parameters (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Medium
Summary:

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

Resolution: resolved, close issue
Revised Text: Clarify specification. Pg. 15-134 [683] end of paragraph on get_required_rights, interface_name parameter, add text:
Actions taken:
November 18, 1996: received issue
January 21, 1997: downgraded from critical to medium
March 2, 1999: closed issue

Discussion:

Issue 361: What does DetectMisordering mean for a multithreaded process? (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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

Resolution: issue closed
Revised Text:
Actions taken:
November 18, 1996: received issue
April 17, 1998: closed issue

Discussion:

Issue 362: Capabilities is under defined (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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.

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 363: Definition of identity domains confusing (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Medium
Summary:

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

Resolution: resolved, close issue
Revised Text: Clarified in Rev 1.1
Actions taken:
November 18, 1996: received issue
December 13, 1996: closed issue

Discussion:

Issue 364: User Sponsor section should be rewritten (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 365: Editorial change (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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.

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 366: AssociationOption (sec-rev)

Click here for this issue's archive.
Nature: NoProblemFound
Severity: LOW
Summary:

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.

Resolution: resolved, close issue
Revised Text: No problem found as per explanation in file
Actions taken:
November 18, 1996: received issue
December 13, 1996: closed issue

Discussion:

Issue 367: get_domain_policy (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Medium
Summary:

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.

Resolution: resolved, close issue
Revised Text: on page 15-74 change "policies" to "policy" on line 2 of the first paragraph in "Finding the Policies" subsection.
Actions taken:
November 18, 1996: received issue
December 13, 1996: closed issue

Discussion:

Issue 368: What does "-" mean in "corba::-g"? (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Serious
Summary:

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

Resolution: resolved, close issue
Revised Text: Fixed in Rev 1.1
Actions taken:
November 18, 1996: received issue
December 13, 1996: closed issue

Discussion:

Issue 369: Initiator is undefined on pg 145 (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Medium
Summary:

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

Resolution: resolved, close issue
Revised Text: Initiator means the top of the call chain. Add a sentence to this effect immediately preceding table 15-1 on page 15-132
Actions taken:
November 18, 1996: received issue
February 25, 1997: closed issue

Discussion:

Issue 370: Current object needs further specification (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Critical
Summary:

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?

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 371: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
November 18, 1996: received issue
December 17, 1996: closed issue same as issue 282

Discussion:

Issue 372: DomainAccessPolicy incorrectly inherits from CORBA (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity: Critical
Summary:

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

Resolution: already fixed, close issue
Revised Text: Already fixed in Chapter 15 in Rev 1.1
Actions taken:
November 18, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 373: Why do DomainAccessPolicy set methods have family arguments? (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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.

Resolution: resolved, close issue
Revised Text: Pg 15-140 [713], [716], [719], Pg 15-295, grant/revoke/replace/get_rights, remove rights_family parameter IDL and corresponding explanatory text.
Actions taken:
November 18, 1996: received issue
March 2, 1999: closed issue

Discussion:

Issue 374: How does get_effective_rights get the delegation state? (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 18, 1996: received issue
March 2, 2001: Deferred:CSIv2 RFP
March 22, 2001: moved back to Security RTF

Discussion:

Issue 375: How do add/delete RequiredRights interface entries? (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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?

Resolution: Close issue 375: How do add/delete RequiredRights interface entries.
Revised Text:
Actions taken:
November 18, 1996: received issue
April 20, 1999: closed issue

Discussion:

We agreed to close this issue because the get/set methods  are sufficient. The functionality being looked for in this issue  is more suited to a value-added library use of the get/set  functions.

Issue 376: What if there are no attribute mappings in a policy? (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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..

Resolution: Just ignore it
Revised Text: Pg. 15-135 [689] and Pg. 15-142 [723], end of paragraph on get_effective_rights and get_rights, description of Return Value, add text:
Actions taken:
November 18, 1996: received issue
April 17, 1998: closed issue

Discussion:

Issue 377: What does get_audit_selectors return? (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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?

Resolution: issue closed
Revised Text:
Actions taken:
November 18, 1996: received issue
April 17, 1998: closed issue

Discussion:

Issue 378: Does AuditPolicy use an implicit ALL combinator? (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Serious
Summary:

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?

Resolution: resolved, close issue
Revised Text: Pg. 15-117 [611], Pg. 15-293, replace "in CORBA::Identifier target_interface_name" with "in CORBA::RepositoryId target_interface_name"
Actions taken:
November 18, 1996: received issue
March 2, 1999: closed issue

Discussion:

Issue 379: When is the "ObjectRef" selector type used? (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Medium
Summary:

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.

Resolution: same as issue 360, close
Revised Text:
Actions taken:
November 18, 1996: received issue
March 2, 1999: closed issue

Discussion:

Issue 381: SecurityLevel2::Object needs further specification (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Critical
Summary:

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?

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 18, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 475: Credentials object underspecified (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Critical
Summary:

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?

Resolution: resolved, close issue
Revised Text:
Actions taken:
January 21, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 487: Missing IDL in Appendix A (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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.

Resolution: resolved, close issue
Revised Text:
Actions taken:
February 3, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 534: Life cycle of Policy object is not specified (sec-rev)

Click here for this issue's archive.
Nature: Bug
Severity: Critical
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
March 25, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 536: Current and get_current() (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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?

Resolution: resolved, close issue
Revised Text: Fix is entirely editorial. IDL in Transaction spec is invalid since you cannot define interface within an interface.The correction is to replace all occurences of string CORBA::ORB::Current by the string in CORBA::Current in the revised transactions spec
Actions taken:
March 19, 1997: received issue
April 4, 1997: closed issue

Discussion:

Issue 537: Insufficient specification of Exceptions (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: resolved, issue closed
Revised Text:
Actions taken:
April 10, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 538: Inappropriate use of the word interface (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
April 10, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 539: IDL in text needs fully qualified names (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
April 10, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 544: SSL Protocol (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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.

Resolution: closed issue
Revised Text:
Actions taken:
April 17, 1997: received issue
April 17, 1998: closed issue

Discussion:

Issue 552: Constant values for ServiceOptions (Section B.9.1) (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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.

Resolution: resolved, close issue
Revised Text:
Actions taken:
April 24, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 553: PolicyType declared as enum (section B.9.2) (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
April 24, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 554: Policy types defined in B.9.2 pertain to Security (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
April 24, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 555: Policy Object (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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.

Resolution: resolved, close issue
Revised Text:
Actions taken:
April 24, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 630: Access to AccessDecision and AuditDecision objects? (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
July 16, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 634: Credentials in Security rev 1.2 are inconsistent (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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.

Resolution: resolved close issue
Revised Text: Since Credentials are locality constrained objects, it stands to reason that any other object that has an operation that has a Credentials or CredentialsList type parameter or return value must also be a locality constrained object. issue superseded by i
Actions taken:
July 29, 1997: received issue
August 5, 1997: closed issue, superseded by issues649/650
August 5, 1997: closed issue; Duplicate or Merged

Discussion:

Issue 635: Const declarations missing for audit event types? (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
July 29, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 649: Problems related to "locally constrained" of Credentials (1) (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
August 1, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 650: Problems related to "local constrainedness" of Cresentials (2) (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: This issue was fixed in revision 1.2
Revised Text:
Actions taken:
August 1, 1997: received issue
April 17, 1998: closed issue

Discussion:

Issue 661: Typo on page 6 of SSL spec (orbos/97-02-04) (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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"

Resolution: resolved, close issue
Revised Text: Typo has been fixed in Security Revision 1.2 Draft 03, which is due out in mid September 1997
Actions taken:
August 8, 1997: received issue
August 20, 1997: closed issue

Discussion:

Issue 712: DomainAccessPolicy operation question (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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?

Resolution: same as issue 373--closed
Revised Text:
Actions taken:
August 26, 1997: received issue
April 17, 1998: closed issue

Discussion:

Issue 713: Tag value of TAG_SSL_SEC_TRANS (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: resolved, close issue
Revised Text: The assigned TAG value for TAG_SSL_SEC_TRANS is 20
Actions taken:
August 27, 1997: received issue
September 17, 1997: closed issue

Discussion:

Issue 714: SSL/CORBA-How does client choose to use SSL? (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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?

Resolution: Close issue 714: SSL/CORBA-How does client chose to use SSL
Revised Text:
Actions taken:
August 27, 1997: received issue
April 20, 1999: closed issue

Discussion:

We agreed to close this issue because the current state  of the specification (RTF 1.5) allows for this capability.

Issue 716: RequiredRights (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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?

Resolution: same as issue359, close
Revised Text:
Actions taken:
August 28, 1997: received issue
March 2, 1999: closed issue

Discussion:

Issue 717: Exceptions to be thrown by (administrative) operations (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
August 28, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 718: SSL/CORBA-How does client choose to use SSL? (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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)

Resolution: same as issue 714---closed
Revised Text:
Actions taken:
August 27, 1997: received issue
April 17, 1998: closed issue

Discussion:

Issue 720: Object side-effect semantics (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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?

Resolution: resolved, close issue
Revised Text:
Actions taken:
September 12, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 972: Typo in spec and IDL text (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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;

Resolution:
Revised Text:
Actions taken:
February 16, 1998: received issue
March 4, 1998: closed issue

Discussion:

Issue 998: AccessPolicy can"t distinguish intiator and delegates (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Summary: Locality constraint on credentials makes it technically impossible to pass them across this interface in cases where the recipient AccessPolicy object takes delegation explicitly into account. A possible partial fix wouldbe to change the interface (see corresponding issue file..)

Resolution:
Revised Text:
Actions taken:
March 11, 1998: received issue
March 2, 2001: Deferred:CSIv2 RFP
March 22, 2001: moved back to Security RTF

Discussion:

Issue 1404: Typo in 98-01-02 (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: I believe there is a typo in 98-01-02 p.15-277. The line   	const AssociationOptions DetectReply = 8;   should read:          const AssociationOptions DetectReplay = 8;

Resolution:
Revised Text:
Actions taken:
June 1, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 1633: Paragraph 19, section 15.8.4.2 (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: Close issue 1633: Paragraph 19, section 15.8.4.2
Revised Text:
Actions taken:
July 2, 1998: received issue
April 20, 1999: closed issue

Discussion:

Close issue 1633: Paragraph 19, section 15.8.4.2  Reason: We agreed to close this issue because it is the same issue  as issue 714.

Issue 1661: Extension to SecurityContext to support SECIOP::DiscardContext (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: :DiscardContext message.
Revised Text:
Actions taken:
July 10, 1998: received issue
November 13, 1998: closed issue

Discussion:

 received issue

Issue 1723: SecIOP Architecture (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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".

Resolution: Close issue 1723: SecIOP Architecture
Revised Text: Close issue 1723: SecIOP Architecture with the following modifications: Change figure (now 15-58 on page 15-222) to be: -------------------------- -------------------------- | GIOP | | GIOP | | - - - -- - - - - - - | | - - - -- - - - - - - | | fragmentation | | fragmentation | -------------------------- -------------------------- | IIOP | SECIOP | SSLIOP | | IIOP | SECIOP | SSLIOP | ------------------------------------------------------------- | Transport | ------------------------------------------------------------- and Change the "IIOP" in figure 15-60 on page 15-223 to "GIOP". Reason: We agreed to the new picture because describes more acurately the positioning of the protocols, and we agreed to close the issue.
Actions taken:
July 22, 1998: received issue
April 20, 1999: closed issue

Discussion:

Issue 1756: Semantics of the Mechanism Policy is not defined wel (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Summary: Semantics of the Mechanism Policy is not defined well.   There are different semantics if it is applied to a    client object reference than to a server object reference.      On the server side, the mechanism list stipulates which   mechanisms can be used to handle the requests. This may   stipulate which mechanisms are advertised in the IOR.      However, since there is an order, and order preference should   be specified. If a client wishes to invoke on said object and   two mechanisms support the requested features, the first one   that does so in the IOR should be said to be selected.       To support multiple mechanisms on the client side, one would    have to inquire which one was used and in which order to   use them. This can also be implied by the order of the list.      However, the semantics of such should be specified.

Resolution:
Revised Text:
Actions taken:
July 30, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 1757: Operations regarding Security Features (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

Summary: Operations regarding Security Features are too vague, unclear,   can be inconsistent, and most likely, not fully implementable.

Resolution:
Revised Text:
Actions taken:
July 30, 1998: received issue
November 13, 1998: closed issue

Discussion:

 received issue

Issue 1758: Inconsistent Spelling between Security and SecurityLevel2 (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Summary: Inconsistent Spelling between Security  and SecurityLevel2

Resolution:
Revised Text: Security RTF 1.5 action 2 in ptc/98-11-02
Actions taken:
July 30, 1998: received issue
November 13, 1998: closed issue

Discussion:

 closed issue

Issue 1759: Misspelling (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary: const EventType AuditObectjCreation = 7;      should be      const EventType AuditObjectCreation = 7;

Resolution:
Revised Text:
Actions taken:
July 30, 1998: received issue
November 13, 1998: closed issue

Discussion:

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

Issue 1760: Duplicate DelegationMode(s) in Security and SecurityLevel2 (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Summary: Duplicate DelegationMode(s) in Security and SecurityLevel2

Resolution:
Revised Text: Security RTF 1.5 action 6 in ptc/98-11-02
Actions taken:
July 30, 1998: received issue
November 13, 1998: closed issue

Discussion:

 closed issue

Issue 1761: DelegationDirectivePolicy Needed (sec-rev)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Summary: We need a delegation directive policy in order to convey on an   object reference, and elsewhere, that whether the credentials   beign used are to be delegated or not.

Resolution:
Revised Text:
Actions taken:
July 30, 1998: received issue
November 13, 1998: closed issue

Discussion:

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

Issue 1763: Credentials issue (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

Summary: Credentials do not have a mechanism specification, a delegation mode,   specification, and an origin specification.      I believe the credentials object may be used to hold the means   necessary to support a security mechansim. It would be much less   confusing, and easier to specify, if there is one credentials    object per mechanism.      We should state that one credential object supports one   mechanism type.

Resolution:
Revised Text:
Actions taken:
July 30, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 1764: Security Context does not reveal client/server orientation. (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Summary:       Each security context, at least at the SECIOP/GIOP levels each   have a client and target orientation. This is not reflected   in the SecurityContext interface.      Also, using the same context for both, is misleading, in the   sense that "received_credentials" does not make sense for   a context on the client side:

Resolution:
Revised Text:
Actions taken:
August 2, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 1765: Credentails.set_privileges() (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

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.

Resolution: Close Issue 1765: set_privileges
Revised Text: Close Issue 1765: set_privileges with the following modifications: Figure 15-32 on Page 15-61: Change "set_privileges" to "set_attributes". Eliminate Paragarph 328 and its bullet as no longer can we "set a wider range of attributes" on a credentials object. Para 345 on page 15-65: Change "set_privileges" to "set_attributes". Para 347 and 348 on page 15-66: Change "set_privileges" to "set_attributes". (Editorial: Change "Credential" to "Credentials" while we are at it). Page 15-95 to Page 15-96 Replace entire section on set_privileges [para. 495] including the NOTE with the following section [ Thank you Andre! ]: set_attributes This operation is used to set all the attributes for a Credentials object. The operation set_attributes is used with get_attributes to constrain the attributes associated with a Credentials object.Some attributes may be tightly bound to the Credentials object based on the underlying mechanism. If the mechanism supports it, setting those attributes may cause mechanism specific communication with a credentialing party. If the operation fails because the mechanism underlying the Credentials object does not support modifying the attributes, CORBA::BAD_OPERATION is raised. Page 15-96: Remove the note Page 15-96: Add: boolean set_attributes ( in Security::AttributeList requested_attributes, out Security::AttributeList actual_attributes ); Parameters requested_attributes The complete attribute list to be associated with the Credentials object. Only attributes in the requested_attributes parameter will be associated with the Credentials object upon successful completion of the operation. Passing an empty list means that all attributes that can be removed will be removed. actual_attributes The list of attributes actually associated with the Credentials object after attempting to set the requested attributes. This list is equivalent to the result obtained if get_attributes were called with an empty list as its parameter immediately after calling set_attributes. Return Value TRUE Indicates that requested_attributes and actual_attributes are the same length and have the same values (all requested attributes were accepted). FALSE Indicates that one or more of the requested_attributes could not removed. Page 15-102 [522]: Change Credentials::set_privileges to Credentials::set_attributes Appendix A: In IDL replace set_privileges definition with: boolean set_attributes ( in Security::AttributeList requested_attributes, out Security::AttributeList actual_attributes ); Page 15-385 [1832]: Change "(see the set_privileges..." to "(see the set_attributes..."
Actions taken:
August 2, 1998: received issue
April 20, 1999: closed issue

Discussion:

Issue 1766: Credentials not in SecurityReplaceable. (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:

Summary: It would appear since the SecurityContext must hold onto the   Credentials object, that the Credentials object must appear   in SecurityReplaceable as well, since there is no factory   for generation of credentials in an independant way.      Perhaps a "Server Context should have a list of   security attributes instead of a list of credentials.   That way an orb using a replacable module can create a local   credentials object and put the security attributes in it.

Resolution:
Revised Text:
Actions taken:
August 2, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 1767: Credentials and PrincipalAuthenticator should be in SecurityReplaceable (sec-rev)

Click here for this issue's archive.
Nature: Enhancement
Severity: Critical
Summary:

Summary: As I lamented before. I fear that to make much implemenation   sense out of the "replaceability of the module I believe    SecurityReplaceable should have Credentials and PrincipalAuthenticator   as well.      Note: This does not proclude security level 2 from having   Credentials and PrincpalAuthenticator, just that SecurityReplaceable   should have them as well.   .

Resolution:
Revised Text:
Actions taken:
August 2, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 1768: SecurityFeatures still confusing! (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Summary: Okay, I"ll give you there is a need for security features   provided they are only looked at for supported features of   credentials and contexts. Not for setting.   These should be done via setting assoication options and setting the    delegation mode;      To simplfy the semantics of SecurityFeatures and using them,   the spec should specify a good programing model. Otherwise,   examining them and manipulating them becomes ineffcient.

Resolution:
Revised Text:
Actions taken:
August 2, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 1786: Using SecurityOpaque causes needless buffer copying (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

Summary: Using SecurityOpaque causes needless buffer copying. I suggest   a buffer interface.   Using a sequence<octet> for tokens going in and out of    SecurityReplaceable::Vault and SecurityContext imply   (at least in the Java) maps it to an array of fixed length.      This causes the implementations to constantly recopy entire    arrays just to get the length attribute set correctly.

Resolution:
Revised Text:
Actions taken:
August 7, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 1787: Current:get_policy() is semanitically insconsitent with curr. object mode (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Summary: The model currently specifies that _set_policy_overrides(), and    get_policy() apply to the particular object reference.      That would mean that the policies applied to accessing Current.   I suggest that we aliviate this discrepancy by putting a   CORBA::PolicyManager get_policy_manager() on the Current interface.   The PolicyManager is currently part of the new Async Messaging Specification   and would be a good interface to do this with.

Resolution:
Revised Text:
Actions taken:
August 10, 1998: received issue
June 18, 1999: closed issue

Discussion:

Issue 1847: Principal Authenticator (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

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   );

Resolution:
Revised Text:
Actions taken:
August 21, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 1930: DelegationMode (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 2, 1998: received issue
November 13, 1998: closed issue

Discussion:

 received issue

Issue 2027: PrincipalAuthenticator and Current (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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()

Resolution: Close issue 2027: Principal Authenticator and Current
Revised Text: We agreed to Remove get/set_credential operations on Current in favor of the new policy oriented way of setting thread specific policies. Page 15-60 Change picture "set_credentials(invocation credentials)" to �InvocationCredentialsPolicy". Replace paragraph 323 on page 15-60 with: When all required changes have been made the credentials may be specified as the credentials for all subsequent invocations by the setting of an InvocationCredentialsPolicy on PolicyCurrent. Para 345 on page 15-65: Change entire end of paragraph starting with "Finally it can call Current::set_credentials..." with:Finally, the intermediate object can place the received credentials in an InvocationCredentialsPolicy for use in making subsequent invocations. Para 347. Remove entire end of paragraph starting with "After doing this, ...." (It�s objective has been stated before, and is overly stated). Remove paragraph 349 as we have no idea how this works. Remove last two bullets of paragraph 568 (set_credentials and get_credentials). Remove paragraph 570 talking about set* and get* operations as they have no significance any more. Change the initial wording of paragraph 571 by removing the word "further". Remove paragraph 579 on page 15-113 through 583 on page 15-114. (Definintions of get_credentials, set_credentials.) Appendix A.1: Remove the definition of "enum CredentialType". beginning with comment "// Credential types which ....." Appendix A.4: Remove definition of "enum DelegationMode". Remove the definitions of get/set_credentials on Current.
Actions taken:
October 2, 1998: received issue
April 20, 1999: closed issue

Discussion:

Issue 2028: own-cedentials model (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: I"m having real problems trying to interpret the specification on the   own_credentials list.   I"m working from the Security Spec 1.2, 5 Jan 1998    It seems to be implied by paragraph 4 of 15.5.4.1 Description of   Facilities on page 15-87, which says:      Credential objects are created as a result of:      o Authentication (see Section 15.5.3,  "Authentication of Principals", on     page 15-85.   o Copying an existing Credentials Object   o Asking for a Credentials object via Current (see Section 15.5.6,      "Security Operations on Current" on page 15-97).      and, by paragraph 7 of section 15.5.6.3 SecurityLevel2::Current   Interface:      own_credentials      Any application owns a set of credentials which it obtains through the   process of authentication of the principal that initiates the execution of   the program, and further from other credentials that such a principal   might bestow upon the application. This attribute returns this set of   credentials.          Okay, so the problem is that these statements imply, but do not explicitly   stipulate that the PrincipalAuthenticator puts Credentials objects on the   "own_credentials" list.

Resolution:
Revised Text:
Actions taken:
October 2, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 2030: Inconsistency between IDL and spec (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Summary: Inconsistent definitions of whether own_credentials is thread            specific, object specific (?), or application/process/capsule            specific.

Resolution:
Revised Text:
Actions taken:
October 2, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 2033: Construction Policy (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Need specific way to associated credentials with            the target object reference on the target side.

Resolution:
Revised Text:
Actions taken:
October 5, 1998: received issue

Discussion:

:Opaque because the C++ mapping causes a new object to

Issue 2069: CORBA::PolicyManager (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: SecurityCurrent should probably inherit from PolicyCurrent to marry this   functionality of dealing with policies. However, the messaging   specification I don"t think is "adopted", although it has an RTF. I don"t   know what is the proper procedure about RTFing things on not-yet adopted   technology.   The PolicyManager has a serious, or at least I   think it"s serious flaw. The PolicyManager has "get_policy_overrides" and   "set_policy_overrides" functions. So does CORBA::Object.  However, the   problem is. Not only do these operations on PolicyManager have different   semantics than the corresponding ones on CORBA::Object,   "set_policy_overrides" has a different signature!

Resolution:
Revised Text:
Actions taken:
October 9, 1998: received issue
June 18, 1999: closed issue

Discussion:

Issue 2086: SecurityAdmin Policies (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Policies in SecurityAdmin are unclear in their interpretations. It is   clear from discussions we have had in the group, that too many different   interpretations can ensue.          This is a problem with trying to define security policy in IDL. There   should be a minimum interface that may be supported that will allow a   language description to be taken as an argument, that will define the   policy for the policy object. The query interfaces may be the same.

Resolution:
Revised Text:
Actions taken:
October 15, 1998: received issue

Discussion:

Issue 2094: get_security_names (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: :Current.
Revised Text:
Actions taken:
October 16, 1998: received issue
November 13, 1998: closed issue

Discussion:

:MechandOptions struct only contains options

Issue 2122: Typo in 15.7.1.1, p.15-145, very last bullet: (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In 15.7.1.1, p.15-145, very last bullet:   SecureInvocationPolicy::get_delegation_mode should be   DelegationPolicy::get_delegation_mode.

Resolution: :get_delegation_mode should be
Revised Text: :get_delegation_mode.
Actions taken:
October 27, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 2161: SecurityLevel2::Current policy factory operation (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: :Current should be
Revised Text: :create_policy operation should be used for
Actions taken:
November 3, 1998: received issue
November 13, 1998: closed issue

Discussion:

 Security RTF 1.5 action 7 in ptc/98-11-0

Issue 2169: Table description incorrect in Security Service (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Close issue 2169. Table description incorrect
Revised Text: with the modification of removing "with RequiredRightsMapping". from the title of Table 15-8 Reason: We agrreed this is an editorial change.
Actions taken:
November 5, 1998: received issue
April 20, 1999: closed issue

Discussion:

Issue 2170: SecurityAdmin::DomainAccessPolicy::grant_rights takes SecAttribute (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Close issue 2170.
Revised Text: Action: Close issue 2170. SecurityAdmin::DomainAccessPolicy::grant_rights takes SecAttribute with the following editorial modifications: Change all occurances in parameters of "Attribute" on pages 15-146 to 15-149 with "SecAttribute".
Actions taken:
November 5, 1998: received issue
April 20, 1999: closed issue

Discussion:

Issue 2199: Table 15-25 Attribute Values lists family 0 attributes as family 1 (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Close issue 2199. Table 15-25 Attribute Values lists family
Revised Text: Close issue 2199. Table 15-25 Attribute Values lists family 0 ... with the editorial modifications of fixing the FrameMaker headers to do the right thing. Reason: We agrreed this is an editorial change.
Actions taken:
November 6, 1998: received issue
April 20, 1999: closed issue

Discussion:

Issue 2201: Interfaces are specified using wrong datatype in CORBASEC (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The CORBASecurity spec. uses three different datatypes for interfaces:       InterfaceDef    RepositoryID    Identifier      InterfaceDef should definitely NOT be used, as it can"t be resolved without   reference to the   Interface Repository, which would be a big performance penalty for cases where   the interface"s   name is simply being matched or used as a lookup key in a local table.      Identifier is also the wrong type; it"s a generic string type and hence not   type-safe with respect   to interface names.

Resolution:
Revised Text:
Actions taken:
November 10, 1998: received issue
November 13, 1998: closed issue

Discussion:

Issue 2259: del parameter of set_delegation should be Security::DelegationDirective (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Close issue 2259: del parameter .....
Revised Text: We agreed to Remove get/set_credential operations on Current in favor of the new policy oriented way of setting thread specific policies. Page 15-60 Change picture "set_credentials(invocation credentials)" to �InvocationCredentialsPolicy". Replace paragraph 323 on page 15-60 with: When all required changes have been made the credentials may be specified as the credentials for all subsequent invocations by the setting of an InvocationCredentialsPolicy on PolicyCurrent. Para 345 on page 15-65: Change entire end of paragraph starting with "Finally it can call Current::set_credentials..." with:Finally, the intermediate object can place the received credentials in an InvocationCredentialsPolicy for use in making subsequent invocations. Para 347. Remove entire end of paragraph starting with "After doing this, ...." (It�s objective has been stated before, and is overly stated). Remove paragraph 349 as we have no idea how this works. Remove last two bullets of paragraph 568 (set_credentials and get_credentials). Remove paragraph 570 talking about set* and get* operations as they have no significance any more. Change the initial wording of paragraph 571 by removing the word "further". Remove paragraph 579 on page 15-113 through 583 on page 15-114. (Definintions of get_credentials, set_credentials.) Appendix A.1: Remove the definition of "enum CredentialType". beginning with comment "// Credential types which ....." Appendix A.4: Remove definition of "enum DelegationMode". Remove the definitions of get/set_credentials on Current.
Actions taken:
December 16, 1998: received issue
April 20, 1999: closed issue

Discussion:

Issue 2260: accept_security_contect() creds parameter (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Close issue 2260: accept_security_context() creds parameter
Revised Text: Reason: We agreed to close this issue because it the list of credentials is needed. This issue is a question that was answered on secsig.
Actions taken:
December 16, 1998: received issue
April 20, 1999: closed issue

Discussion:

Issue 2344: More nil/NULL arguments that need to be removed (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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".

Resolution: Close issue 2344: More nil/NULL argument that need to be removed:
Revised Text: Close issue 2344: More nil/NULL argument that need to be removed: with the following modifications: [ Thank you Andre! ]. 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." [Fixed in Resolution 6] 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". Reason: We agreed these changes are editorial. Resolution 14: Action: Close issues 1787 and 2069 "Current:get_policy() is semantically inconsistent with curr. object model" Reason: We agreed that all thread related security policies will be handled by the ORB�s PolicyCurrent object.
Actions taken:
January 25, 1999: received issue
April 20, 1999: closed issue

Discussion:

Issue 2437: Security: SECIOP (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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).

Resolution: Close issue 2437 "SECIOP needs an internet address designation"
Revised Text: Section 15.10 Add following after paragraph 1189 on page 15.24 (modeled after the SSLIOP). The IIOP TAG identifying the SECIOP security transport is TAG_SECIOP_INET_SEC_TRANS. The tagged component data described below must be encapsulated using CDR encoding. The data structure association with this tag is as follows: struct SECIOP_INET_SEC_TRANS { unsigned short port; }; The port field contains the port number to be used instead of the port defined the accompanying IIOP profile body, if SECIOP is selected by the client. It contains the TCP/IP port number (at the specified host) where the target agent is listening for connection requests for the SECIOP protocol. Appendix A.8, page 15-327 Add the following definitions to the module SECIOP: const IOP::ComponentId TAG_SECIOP_INET_SEC_TRANS = 123; struct SECIOP_INET_SEC_TRANS { unsigned short port; };
Actions taken:
February 4, 1999: received issue
June 18, 1999: closed issue

Discussion:

Issue 2440: Need to get Received Credentials from the Server (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Close issue 2440 "Need to get Received Credentials from the Server"
Revised Text: Add the following section before 15.5.6 "Operations on Object Reference". The TargetCredentials Object A Target Credentials object is the dual of the ReceivedCredentials object as it represents a remote principal�s authentication information for the client�s secure association with a target. The TargetCredentials object may not be used for invocations. The TargetCredentials object represents the secure association to the application. Therefore, the TargetCredentials object contains the properties of that association, such as the Credentials local to the capsule used to initiate the association and the association options in effect. The TargetCredentials object is a locality constrained object, and it contains a credentials_type value of SecTargetCredentials. The SecurityLevel2::TargetCredentials Interface The TargetCredentials interface is defined as follows: interface TargetCredentials : Credentials { readonly attribute Credentials initiating_credentials; readonly attribute Security::AssociationOptions association_options_used; }; initiating_credentials This readonly attribute contains the reference to the credentials object that is used on the initiating side of the negotiation of the secure association with the remote principal. association_options_used This readonly attribute contains the association options in effect for the secure association with the remote principal. Add to page 15-183 Section on attribute to ClientSecurityContext after section on "client_credentials". target_credentials The target_credentials readonly attribute returns the credentials object that represents the secure association with the target. readonly attribute TargetCredentials target_credentials; Return Value The credentials representing authentication of the principal of the target. Remove definition of get_security_mechansims on page 15-111 and 15-116. Appendix A.1, Page 15-308 Remove definition of SecurityMechanismData and SecurityMechanismDataList. Appendix A.4, Remove definition of operation get_security_mechanisms from Current, Page 15-316
Actions taken:
February 5, 1999: received issue
June 18, 1999: closed issue

Discussion:

Issue 2451: Channel Bindings are underspecified (sec-rev)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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.

Resolution: Close issue 2451 "Channel Bindings are underspecified"
Revised Text: "chan_bindings" parameter to "Security::ChannelBindings": AssociationStatus init_security_context( in Credentials creds, in SecurityName target_security_name, in Object target, in DelegationMode delegation_mode, in OptionsDirectionPairList association_options, in MechanismType mechanism, in Opaque mech_data, //from IOR in ChannelBindings chan_bindings, out OpaqueBuffer security_token, out ClientSecurityContext security_context ); Change the definition of chan_binding parameter to: chan_bindings The channel bindings for the security context. They are the channel bindings defined for the GSS-API. Modify the IDL on page 15-172 changing the type of the "chan_bindings" parameter to "Security::ChannelBindings": AssociationStatus accept_security_context( in CredentialsList creds_list, in ChannelBindings chan_bindings, in Opaque in_token, out OpaqueBuffer out_token, out ServerSecurityContext security_context ); Change the definition of chan_binding parameter to: chan_bindings The channel bindings for the security context. They are the channel bindings defined for the GSS-API. Appendix A.2: Add definition of ChannelBindings: // GSS-API Channel Bindings struct ChannelBindings { unsigned long initiator_addrtype; sequence<octet> initiator_address; unsigned long acceptor_addrtype; sequence<octet> acceptor_address; sequence<octet> application_data; };
Actions taken:
February 12, 1999: received issue
June 18, 1999: closed issue

Discussion:

Issue 2452: Inappropriate examples of Integrity Violations (sec-rev)

Click here for this issue's archive.
Nature:
Severity: Minor
Summary:

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.

Resolution: Close issue 2452 "Need OID�s exposed in Vault."
Revised Text: Page 15-173: Add section after paragraph 853 that starts with "The list of authentication methods supported by this Vault ...". supported_mech_oids This readonly attribute contains a sequence of OIDs each of which identifies a particular GSS mechanism that the Vault supports. Appdendix A.3, Page 15-324: Add the attribute definition to the Vault interface after "get_supported_mechs": readonly attribute Security::OIDList supported_mech_oids;
Actions taken:
February 12, 1999: received issue
June 18, 1999: closed issue

Discussion:

Issue 2558: ReceivedCredentials. (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: I think we have a further problem representing the received   credentials from the server.      We have more than just two attributes on received credentials   which are more suited to the nature of a client, as opposed   to a server/target.  We have      readonly attribute Credentials     accepting_credentials;   readonly Security::DelegationState delegation_state;   readonly attribute Security::DelegationMode delegation_mode;   readonly attribute Security::AssociationOptions   				association_options_used;      What do we do about delegation_state or delegation_mode   for received credentials from the server?

Resolution:
Revised Text:
Actions taken:
March 29, 1999: received issue
March 31, 1999: issue closed, same as 2440

Discussion:

Issue 2703: How is a SecAttribute"s value field encoded (sec-rev)

Click here for this issue's archive.
Nature: Clarification
Severity:
Summary:

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.

Resolution: Close issue 2703 "How is a SecAttribute�s value field encoded"
Revised Text: Add the definition: typedef sequence<octet> OID; typedef sequence<OID> OIDList; Modify the definition of SecAttribute to: struct SecAttribute { AttributeType attribute_type; OID defining_authority; Opaque value; // The value of this attribute can be decoded // only with the knowledge of the defining_authority }; Note: This is a backwards compatible revision. Change Header of A.11.1 from "Attribute Types" to "Security Attributes" Replace the 3 bullet of paragraph 1586 with: A defining authority. The field indicates the authority responsible for defining the encoding of the value field of the attribute. The defining authority is defined as an octet sequence that is an ASN.1 encoding of an OID. The entity referenced by the OID defines the value�s encoding to/from a sequence of octets. If the defining authority field is empty (i.e. octet sequence of length 0), the defining authority is the OMG. The OMG defines all attribute values to be a UTF-8 byte encoding of a string value. Replace the 4th bullet of paragraph 1586 with: An attribute value. The attribute value is encoded as an octet sequence. The encoding is specified by the defining authority field. Add the following after paragraph 1586: Attributes used in the CORBA realm or CORBA based security mechanisms have values of UTF-8 encoded strings, which is stipulated by an empty sequence of octets for the defining authority field. A defining authority field stipulating different encodings for values is meant for the representation of security attributes from security mechanisms other than CORBA such that the values of these attributes *cannot* be represented as the standard OMG defined UTF-8 encoding of a string, or if such a mapping to and from a string is not defined. Equality for attributes is defined as structural equality based on structural equality on the attribute type, octet sequence equality on the defining authority, and octet sequence equality of the value.
Actions taken:
June 4, 1999: received issue
June 18, 1999: closed issue

Discussion:

Issue 2704: Capule Specific items residing on thread specific Current (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

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.

Resolution: Close issue 2704 "Current contains thread specific information".
Revised Text: Create a new section before section 15.5.7 "Security Operations on Current". (This is shifting some paragraphs from 15.5.7). Operations on Security Manager Description The Security Manager object represents capsule specific security information. The attributes and operation of the SecurityManager object are relevant to the capsule regardless of the thread of execution. A reference to the SecurityManager object is retrieved using the ORB::resolve_initial_reference("SecurityManager") operation. The attributes and operations on the SecurityManager object are described in this section and provide access to the following information: o principal_authenticator: A reference to the PrincipalAuthenticator object, which is used to authenticate principals and thus obtain Credentials objects for them. o own_credentials: The list of credentials associated with the active application (capsule). A capsule�s own credentials are set up as the result of the application being initialized or explicitly by calling on the PrincipalAuthenticator object. The operations provided are the following: o remove_own_credentials: This operation allows the application to perform Credentials management of the own_credentials list. o get_target_credentials: This operation allows the application to discover the authenticated principal of a target object. The SecurityLevel2::SecurityManager Interface The following attributes and operations are available on the SecurityLevel2::SecurityManager Interface. principal_authenticator This readonly attribute is a reference to the PrincipalAuthenticator that can be used by the application to authenticate principals and obtain Credentials. readonly attribute PrincipalAuthenticator principal_authenticator; Return Value The object reference to a PrincipalAuthenticator object. The operation in the interface of this object are defined in Section 15.3.2 "Principals and Their Security Attributes," on page .... own_credentials Any application owns a set of credentials which it obtains through the process of authentication of the principal that initiates the execution of the program, and further from other credentials that such a principal might bestow upon the application. This attribute returns this set of credentials. readonly attribute CredentialsList own_credentials; Return Value A sequence of Credentials object references owned by the application. remove_own_credentials This operation is used by applications that wish to remove credentials that were put on the own_credentials list by virtue of the PrincipalAuthenticator. This operation does not manipulate or destroy the objects in any way. The give Credentials object (as opposed to the one produced by a copy operation) must reside on the list, otherwise a CORBA::BAD_PARAM exception is raised. void remove_own_credentials( in Credentials creds ); Parameters creds The Credentials object to be removed from the list. Return Value None. get_target_credentials This operation is used by the applications that wish to authenticate a principal "behind" the object reference. TargetCredentials get_target_credentials( in Object target ); Parameters target The object reference in question. Return Value The TargetCredentials object that represents the secure association established with the remote principal. Modify Section on "Security Operations on Current" Paragraph 567: Remove "own_credentials" bullet; Remove paragraph 569 and its bullets. Remove sections from "own_credentials" paragraph 587 on page 15-114, through end of section, paragraph 601 on page 15-117 Remove the first sentence of paragraph 695 on page 15-139 "A Required Rights object is available as an attribute of Current in ....".
Actions taken:
June 4, 1999: received issue
June 18, 1999: closed issue

Discussion:

 close issue 2704: Current contains thread specific information

Issue 2707: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 9, 1999: received issue

Discussion:

Issue 2708: Which codeset is used in CDR encoding (interop) (sec-rev)

Click here for this issue's archive.
Source: University of California, Irvine (Mr. Carlos O'Ryan, nobody)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: to Close with agreed change
Revised Text: add the following text to the definition of encapsulation in 15.3.3 " Whenever the use of an ecapsulation is specified, the GIOP version to use for encoding the encapsulation, if different than GIOP version 1.0, must be explcitly defined (i.e., the default is GIOP 1.0). If a parameter with IDL char or string type is defined to be carried in an encapsulation using GIOP version greater than 1.0, the transmission Code Set for characters (TCS-C), to be used when encoding the encapsulation, shall also be explcitly defined.
Actions taken:
June 8, 1999: received issue
October 4, 2000: Approved by Vote 1 issue closed
October 4, 2000: closed issue

Discussion:

This is closely related to issues 2784 (which  describes the same problems pertaining to Wide Strings in IDL  encapsulations) and superceded Issue 2457 (which was also concerned with the encoding of strings in GIOP headers and  TypeCodes)     Since GIOP headers and Type codes may only include Latin-1 strings (Type code names originate from IDL indentifiers, and no  Giop header strings have beed defined to carry anything beyond Latin-1) issue 2457 was closed, with its remaining issue already  encompassed in this issue 2708.     There have been no standard IOR components or Service contexts defined to use any GIOP version other than 1.0.  Thus the only  way internationalized strings can appear in IORs is through non-standard IOR components or service contexts.     The only way to guarantee interoperability for such encapsulations is to declare a default codeSet for use with strings in  encapsulations, when the use of that encapsulation is defined.     Whenever the use of an Encapsulations is defined for placement in an Octet Sequence (e.g., IOR component or service context  definition) , Giop version 1.0 is assumed for the encoding, unless the definition explicitly states otherwise.     If the syntax for an encapsulation is defined to be encoded using GIOP versions 1.1 or higher and includes parameters of type  string (or wstring), that definition is required     During the vote it was clarified that this pertains to char or string types.

Issue 2709: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 8, 1999: received issue

Discussion:

Issue 2710: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 9, 1999: received issue

Discussion:

Issue 2711: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 9, 1999: received issue

Discussion:

Issue 2715: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 8, 1999: received issue

Discussion:

Issue 2716: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 9, 1999: received issue

Discussion:

Issue 2717: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 9, 1999: received issue

Discussion:

Issue 2718: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 10, 1999: received issue

Discussion:

Issue 2719: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 9, 1999: received issue

Discussion:

Issue 2720: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 10, 1999: received issue

Discussion:

Issue 2722: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 10, 1999: received issue

Discussion:

Issue 2723: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 10, 1999: received issue

Discussion:

Issue 2724: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 10, 1999: received issue

Discussion:

Issue 2732: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 14, 1999: received issue

Discussion:

Issue 2733: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 14, 1999: received issue

Discussion:

Issue 2734: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 14, 1999: received issue

Discussion:

Issue 2735: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 14, 1999: received issue

Discussion:

Issue 2736: (sec-rev)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
June 14, 1999: received issue

Discussion:

Issue 2789: Security: SSL reference no longer valid (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: close issue 2789
Revised Text: ++Add Required Rights, Access Decision, Audit Decision definintions and attributes (from Current), and get_security_policy (from Current:get_policy) to Security Manager. ++Install the following paragraphs (taken from the previous Operations on Security Current section) into the Security Manager section: required_rights_object This readonly attribute is the RequiredRights object available in the environment. This object is rarely used by applications directly. It could be used directly by applications if the application wishes to do all its own access control based on rights. readonly attribute RequiredRights required_rights_object; Return Value An object reference to RequiredRights. The operation in the interface of this object are defined in Section 15.6.4, "Access Policies", on page 15-???. access_decision This read only attribute is the AccessDecision object available in the environment. It can be used by the application to obtain decisions regarding accessibility of specific objects from this environment. readonly attribute AccessDecision access_decision; Return Value An object reference to an AccessDecision object. The operations in the interface of this object are defined in Section 15.5.10, "Access Control", on page 15-??? audit_decision This read only attribute is the AuditDecision object available in the environment. It can be used by the application to obtain information about what needs to be audited for the specified object/interface in this environment. readonly attribute AuditDecision audit_decision; Return Value An object reference to an AuditDecision object. The operation in the interface of this object are defined in Section 15.5.8, "Security Audit", on page 15-??? get_security_policy This operation gets the security policy of the specified policy_type that is relevant to the ORB instance and security service. CORBA::Policy get_security_policy( in CORBA::PolicyType policy_type ); Parameters policy_type The type of policy requested. Return Value The policy in effect for the ORB instance. If no policy of that type is in effect, a CORBA::INV_POLICY exception is raised. ++Fix all references to Current::get_policy to PolicyCurrent::get_policy_overrides or SecurityManager::get_security_policy where appropriate. ++Change the paragraph [632], starting with "The SecurityLevel2::AccessDecision Interface" and change the corresponding definition of AccessDecision in appendix A.4. The SecurityLevel2::AccessDecision Interface The Access Decision object is a locality constrained object. This object has the following interface: interface AccessDecision { boolean access_allowed( in ReceivedCredentials creds, in Object target, in CORBA::Identifier operation_name, in CORBA::RepositoryId target_interface_name ); }; Parameters creds The Credentials representing principal of a client. target The reference of the target object. operation_name The name of the operation on the target object for which access is being requested. target_interface_name The repository identifier which must name the most derived interface of the target object. Return Value boolean A return value of TRUE indicates that access to the particular operation is allowed. A return value of FALSE indicates that access to the particular operation is denied. ++Remove the paragraph [695], starting with "A RequiredRights object is available as an attribute of Current...." which stipulates that RequiredRights is an attribute off of Current and also eliminating the part about "every" required rights object in every execution context as this is confusing: ++Remove paragraph [840] starting with "While man of these objects have interfaces...." ++Replace paragraph 910, "The Access Decision Object" on page 15-186 with the following, and add the interface definition to Appendix A.7. The Access Decision Object The Access Decision object is responsible for determining whether the specified credentials allow an operation to be performed on a target object. The target uses its access_allowed operation to determine whether a client principal�s privileges, which are obtained from the SecurityCurrent, are sufficient to meet the access criteria for the requested operation for a target object of the specified interface. The SecurityReplaceable::AccessDecision Interface The SecurityReplaceable::AccessDecision object is a locality constrained object. This object has the following interface: interface AccessDecision { boolean access_allowed( in ReceivedCredentials creds, in Object target, in CORBA::Identifier operation_name, in CORBA::RepositoryId target_interface_name ); }; Parameters creds The Credentials representing principal of a client. target The reference of the target object. operation_name The name of the operation on a target object for which access is being requested. target_interface_name The CORBA repository identifier which represents the most derived interface name of a target object. Return Value boolean A return value of TRUE indicates that access to the particular operation is allowed. A return value of FALSE indicates that access to the particular operation is denied. ++Add paragraphs after paragraph 909 and add the interface definition to Appendix A.7 The Required Rights Object The Required Rights object has operations for retrieving and setting the rights required for operations on interfaces. It is replaceable since the replaceable Access Decision depends upon its implementation, if the Access Decision object uses RequiredRights. Note that the following behaviors of systems conforming to CORBA Security are unspecified and therefore may be implementation-dependent. o Assignment of initial required rights to newly created interfaces. o Inheritance of required rights by newly created derived interfaces. The SecurityReplaceable::RequiredRights Interface The SecurityReplaceable::RequiredRights Interface has the following operations: get_required_rights This operation retrieves the rights required for access to the operation specified by operation_name from the interface specified by interface_name. The returned values are a list of rights and a combinator that describes the the interpretation of multiple rights. void get_required_rights( in CORBA::Identifier operation_name, in CORBA::RepositoryId interface_name, out RightsList rights, out RightsCombinator rights_combinator ); Parameters operation_name The name of the operation for which required rights are to be returned. interface_name The CORBA Repository identifier which names the interface to which the operation belongs. rights The returned list of rights. rights_combinator The returned rights combinator. Return Value None. set_required_rights This operation updates the rights required to execute the operation specified by the operation_name of the interface specified by interface_name. The caller must provide a list of rights and a combinator describing the interpretation of multiple rights. void set_required_rights( in CORBA::Identifier operation_name, in CORBA::RepositoryId interface_name, in RightsList rights, in RightsCombinator rights_combinator ); Parameters operation_name The name of the operation for which requires rights are to be updated. interface_name The CORBA Repository identifier which names the interface to which the operation belongs. rights The list of rights. rights_combinator The rights combinator. Return Value None. ++Change paragraph [911] and [912] with the following and add the interface definitions to Appendix A.7. The Audit Decision Object The Audit Decision object is used to determine if an event needs to be audited. The SecurityReplaceable::AuditDecision Interface The AuditDecision object has the following attributes and operations: audit_needed This operation is used to determine if an audit record is to be written to the audit channel. The caller specifies and event type and values for the selectors. It has the following definition: boolean audit_needed( in AuditEventType event_type, in SelectorValueList value_list ); Parameters event_type The event type. value_list A list of zero or more selector value pairs. Return Value TRUE If an audit record should be created and sent to the audit channel FALSE If an audit record is not needed. audit_channel This attribute provides the audit channel associated with the audit decision object. readonly attribute AuditChannel audit_channel; Return Value The AuditChannel object associated with the AuditDecision object. The AuditChannel Object An AuditChannel Object contains the operations necessary to generate audit records. audit_channel_id The readonly attribute contains an identifier with which to identify the particular audit channel object. readonly attribute AuditChannelId audit_channel_id; Return Value The audit channel identifier. audit_write This operation writes an audit record on the audit channel. void audit_write( in AuditEventType event_type, in CredentialsList creds_list, in UtcT time, in SelectorValueList descriptors, in any event_specific_data ); Parameters event_type The type of event. creds_list The list of credentials of the principal responsible for the event. time The time the event occurred. descriptors The set of values to be recorded that are associated with the event. event_specific_data Data specific to a particular type of event. Return Value None.
Actions taken:
July 7, 1999: received issue
May 4, 2000: closed issue

Discussion:

Issue 2800: Public Attribute extraneous and inefficient (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

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.

Resolution: Close Issue 2800 _Public
Revised Text:
Actions taken:
July 12, 1999: received issue
May 4, 2000: closed issue

Discussion:

Discussion:  Specifying the value of the _Public attribute to have a  defining_authority and value as an empty  sequence<octet>, and also to stipulate that every Credentials  object must have one and only one _Public Attribute.  ++Add after paragraph [484], starting with "A Credentials object represents  a particular principal�s credentials....."  Each Credentials object is mandated to carry at least one and only one  attribute of type Public. The Public attribute has a defining authority of  OMG, its value is empty, and it serves only to mark the credentials with an  attribute stipulating that the principal, authenticated or not, is a member  of the "general public". This requirement allows access policies to be  specified for the general public in much the same way as policies based on  other attributes are specified.  ++Change paragraph [574], removing the last two sentences of the first  bullet, "If the principal was ... meaningful value", leaving the following:  o Privilege attributes for use in access control decisions.  o Other attributes, such as authid or charging identities, if available.  ++Remove last two sentences of paragraph [1088], starting with  "This specification allows unauthenticated...", leaving the following:  This specification allows unauthenticated and authenticated users.

Issue 2927: Parameters of locality constrained interfaces were using "sequence octet" (sec-rev)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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".

Resolution:
Revised Text: Action: Close issue 2927 Opaques used where any�s should be used for locality constrained interfaces. ++Change the interface of the authenticate method after paragraph 479 and its corresponding interface definition in Appendix A.4. AuthenticationStatus authenticate( in AuthenticationMethod method, in MechanismType mechanism, in SecurityName security_name, in any auth_data, in AttributeList privileges, out Credentials creds, out any continuation_data, out any auth_specific_data ); ++ Change the interface of the continue_authentication method after paragraph 481 and its corresponding interface definition in Appendix A.4. AuthenticationStatus continue_authentication( in any response_data in Credentials creds, out any continuation_data, out any auth_specific_data ); ++ Change the interface of the audit_write operation after paragraph 615 and its corresponding interface definitions in Appendix A.4. void audit_write( in AuditEventType event_type, in CredentialsList creds, in UtcT time, in SelectorValueList descriptors, in any event_specific_data ); ++ Change the interface of the acquire_credentials method after paragraph 843 and its corresponding interface definition in Appendix A.7. AuthenticationStatus acquire_credentials( in AuthenticationMethod method, in MechanismType mechanism, in SecurityName security_name, in any auth_data, in AttributeList privileges, out Credentials creds, out any continuation_data, out any auth_specific_data ); ++ Change the interface of the continue_acquisition method after paragraph 845 and its corresponding interface definition in Appendix A.7. AuthenticationStatus continue_acquisition( in any response_data in Credentials creds, out any continuation_data, out any auth_specific_data );
Actions taken:
October 4, 1999: received issue
March 10, 2000: closed issue

Discussion:

  "sequence<octet>"

Issue 2928: The RequiredRights are confusing (sec-rev)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text: Action: Close issue 2928 Rights Combinators Any and All are underspecified and Required Rights are confusing. ++Replace paragraph 700 with: The value returned for a particular operation in a RequiredRights object is a list of rights and a Rights Combinator. The Rights Combinator specifies the interpretation of multiple rights in conjunction with a list of granted rights. This specification specifies two Rights Combinators, SecAllRights and SecAnyRights. Each combinator defines a predicate on a list of required rights and a list of granted rights. Given a list of granted rights, G, and a list of required rights, R, the definition of the SecAllRights combinator forms the following predicate: V r . r in R => r in G The definition of the SecAnyRights combinator forms the following predicate: E r . r in R & r in G These definitions have important ramifications when an empty list of required rights is specified with each combinator. Regardless of the granted rights, if the required rights, R, is empty then the predicate formed with the SecAllRights combinator results in true, and the predicate formed with the SecAnyRights combinator results in false. ++ Replace the parameter definition for interface_name in paragraph 702: interface_name The CORBA RepositoryId of the interface implemented by the object, which is used as a default only if the ORB cannot determine the name of the most derived interface implemented by the object in the obj parameter. ++ Replace paragraph [704] set_required_rights This operation updates the rights required to execute the operation specified by the operation_name of the interface specified by interface_name. The caller must provide a list of rights and a combinator describing the interpretation of multiple rights.
Actions taken:
October 4, 1999: received issue
March 10, 2000: closed issue

Issue 2958: Security: Need to complete SecurityReplaceable (sec-rev)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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 {      TaggedComponentList create_iiop_components(  	in SecurityLevel2::CredentialsList     creds_list      );    };    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.

Resolution:
Revised Text: Action: Close Issue 2958 3044 3047 About not being able to get IOR components for supported security mechanisms: [Add the following end of the Vault section. Add on page 15-173 before the "The Security Context Object" header.] create_ior_components This operation is called to create a set of security related TaggedComponents that indicate the security mechanisms supported by the Vault and the given set of Credentials objects. IOP::TaggedComponentList create_ior_components( in SecurityLevel2::CredentialsList creds_list ); Parameters creds_list This argument lists the credentials that are to be considered in creating the Tagged Components. Return Value This operation returns the Tagged Components. Add the following to the Consolidate IDL Appendix A.7. Security Replaceable Service Interfaces, add: #include <IOP.idl> and in the definition of the Vault, add: IOP::TaggedComponentList create_ior_components( in SecurityLevel2::CredentialsList creds_list );
Actions taken:
October 26, 1999: received issue
March 10, 2000: closed issue

Issue 3044: Section: 15.7 Security Implementers Interfaces. (sec-rev)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text: Close Issue 2958 3044 3047 About not being able to get IOR components for supported security mechanisms: [Add the following end of the Vault section. Add on page 15-173 before the "The Security Context Object" header.] create_ior_components This operation is called to create a set of security related TaggedComponents that indicate the security mechanisms supported by the Vault and the given set of Credentials objects. IOP::TaggedComponentList create_ior_components( in SecurityLevel2::CredentialsList creds_list ); Parameters creds_list This argument lists the credentials that are to be considered in creating the Tagged Components. Return Value This operation returns the Tagged Components. Add the following to the Consolidate IDL Appendix A.7. Security Replaceable Service Interfaces, add: #include <IOP.idl> and in the definition of the Vault, add: IOP::TaggedComponentList create_ior_components( in SecurityLevel2::CredentialsList creds_list );
Actions taken:
November 22, 1999: received issue
March 10, 2000: closed issue

Issue 3045: Section: 15.8.14 CORBA Interface (sec-rev)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text: Close issue 3045 on not being able to distinguish generic security mechanisms in the current mechanism identifier framework. Move paragraph on page 15-219 "Mechanism tags in the IOR and mechanism type Object Identifiers...." To page 15-218 before paragraph "MechanismType is used for...." and add paragraph, such that the following exists: Cryptographic profiles are identified by a "stringified" form of the CryptographicProfile value as used in the IOR. Mechanism tags in the IOR and mechanism type Object Identifiers (as in GSS-API) in SECIOP messages are also used as appropriate. A MechanismType identfier for a generic security mechanism is the stringified value of SECIOP::TAG_GENERIC_SEC_MECH concatenated with a colon ":" concatenated with the stringified hexadecimal encoding of the octet sequence in the security_mechanism_type field of the components associated SECIOP:GenericMechanismInfo structure.
Actions taken:
November 22, 1999: received issue
March 10, 2000: closed issue

Issue 3046: Section: Appendix I: Dangeling References (sec-rev)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text: Action: Close Issue 3046 on dangling references. Change references 19 and 20 to: [19] IETF RFC 2478, The Simple and Protected GSS-API Negotiation Mechanism, December 1998. [20] IETF RFC 2025, The Simple Public-Key GSS-API Mechanism (SPKM), October 1996.
Actions taken:
November 22, 1999: received issue
March 10, 2000: closed issue

Issue 3047: Need TaggedComponentList typedef. (sec-rev)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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 {      typedef sequence<TaggedComponent> TaggedComponentList;  };    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.

Resolution:
Revised Text: Close Issue 2958 3044 3047 About not being able to get IOR components for supported security mechanisms: [Add the following end of the Vault section. Add on page 15-173 before the "The Security Context Object" header.] create_ior_components This operation is called to create a set of security related TaggedComponents that indicate the security mechanisms supported by the Vault and the given set of Credentials objects. IOP::TaggedComponentList create_ior_components( in SecurityLevel2::CredentialsList creds_list ); Parameters creds_list This argument lists the credentials that are to be considered in creating the Tagged Components. Return Value This operation returns the Tagged Components. Add the following to the Consolidate IDL Appendix A.7. Security Replaceable Service Interfaces, add: #include <IOP.idl> and in the definition of the Vault, add: IOP::TaggedComponentList create_ior_components( in SecurityLevel2::CredentialsList creds_list );
Actions taken:
November 24, 1999: received issue
March 10, 2000: closed issue

Issue 3262: Regarding Principal Authenticator in security/99-12-02 (sec-rev)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jan Pachl, pachl(at)acm.org)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: close with revised text
Revised Text: Paragraph 940 on page 15-190 starting with "Replacement of the authentication," with: Replacement of the authentication and message protection services underlying secure ORB implementation is accomplished by changing the Vault, which creates Credentials and Security Context objects. Remove Paragraphs 941 starting with "Note that if the Vault uses GSS-API to link" This paragraph doesn�t say much that is particularly useful as far as the spec goes. Remove Paragraph 942 starting with "The Vault is replaced by changing the version" This paragraph is confusing and doesn�t really define the "environment". It�s better off just taken out.
Actions taken:
January 27, 2000: received issue
August 3, 2001: closed issue

Discussion:

The Security Replaceable Vault may call the PrincpalAuthentciator.

Issue 3272: SECIOP Sequencing Layer is superfluous and redundant (sec-rev)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: closed with revised text
Revised Text: Paragraph 1160: Remove "(or message fragments)". Paragraph 1161: Remove "(e.g., to support request fragmentation)". Eliminate Paragraph 1162 and Figure 15-59 on page 12-225 Eliminate Paragraph 1163 on page 12-226 Change Paragraph 1164 to: The SECIOP Context Management Layer encapsulates GSS based tokens in SECIOP messages. It is driven by the finite state machines defined in Table15-13 on page15-239 and Table15-14 on page15-242. Paragraph 1166: Remove Bullet 3 starting with "SECIOP ensures that fragments are sent over transport connections in their sequence number order." Replace Bullet 4 starting with "When a transport connection is closed," with: A secure association is viewed by the GIOP layer as if it were a transport connection. Therefore, GIOP operates in the same manner as a connection closure when a secure association is discarded. When a transport underneath SECIOP is closed, all SECIOP secure associations are effectively discarded. Remove bullet 5 starting with "There is always a listener at the" Remove Bullet 6 starting with "Both the client and server may initiate"Remove bullet 7 starting with "SECIOP sequence numbers should never wrap" Remove bullet 8 starting with "There is Data Protection protocol information" Remove Section 15.9.2 "SECIOP Sequencing Layer" page 15-227 to 15-233 Section 15.9.4 "SECIOP Context Management Finite State Machine Tables" Replace all the bullets paragraph 1210 with: � Each TCP connection may be associated with multiple FSMs. � Each ContextId is associated with one and only one FSM. Appendix A.8: Secure Inter-ORB Protocol (SECIOP) Remove definition of "struct SequencingHeader" on page 15-335
Actions taken:
February 4, 2000: received issue
August 3, 2001: closed issue

Issue 3406: Firewall issue regarding SOCKS (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
March 3, 2000: received issue
March 24, 2000: moved from Firewall RTF to Security RTF

Issue 3407: Adding firewall info to the IOR (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
March 3, 2000: received issue
March 24, 2000: moved from Firewall RTF to Security RTF

Issue 3442: editorial revisions to address issue #1765 were not completed correctly (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: closed with revised text
Revised Text: Editorial Change: Page 15-96 Change header of "actual_privileges" to "actual_attributes". Paragraph 495 on page 15-96 Change text to the following to make a real sentence: This operation is used to get attributes from the Credentials. It may be used to get the following:
Actions taken:
March 22, 2000: received issue
August 3, 2001: closed issue

Issue 3571: AuditChannel::audit_write has Opaque (sec-rev)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Revision
Severity: Significant
Summary:

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".

Resolution: close with revised text
Revised Text: Change Paragraph 617 of RTF 1.7 so that the type of event_specific_data is an "any". Change Appendix A.4 page 15-318, Consolidated IDL, so that the type of event_specific_datais "any".
Actions taken:
April 19, 2000: received issue
August 3, 2001: closed issue

Issue 3572: SecurityContext::process_context_token (sec-rev)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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

Resolution: Apply revisions and close issue.
Revised Text: Remove portion of "Figure 15-55 Security Context State Transition Diagram" that applies to refresh. Remove paragraph 870 "supports_refresh" Remove paragraph 881 "refresh_security_context" Remove Paragraph 882 "process_refresh_token" Remove "supports_refresh", "refresh_security_context", and and "process_refresh_token" from Appendix A.7
Actions taken:
April 19, 2000: received issue
August 3, 2001: closed issue

Discussion:

There is a process_refresh_token that was added in one of the last RTF's.    I believe this should be changed to process_context_token.There is a process_refresh_token that was added in one of the last RTF�s. I believe this  should be changed to process_context_token.  ----  Since the GSS-API does not support dynamic context refresh, and SECIOP has  eliminated that capability, the refresh_security_context and process_refresh_token  operations must be removed.  A context token in the GSS-API is only delivered as a result of the server processing the  security context establishment via Accept_sec_context, and producing a token that the  client must process. In the GSS-API the operation of Process_context_token is provided  for this purpose because the client cannot call GSS-API Init_sec_context operation  because the state has already transistioned to GSS_S_COMPLETE. However, in SECIOP a CompleteEstablishment message MUST always be returned by  the server, and therefore context token will be contained in the final_context_token field.  A SecurityReplaceable security context processes this token with  complete_security_context. If the security context is  discarded the operation will return a failure status.

Issue 3577: No Standard Authentication Mechanism Specification for Kerberos (sec-rev)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: No Change and close issue.
Revised Text:
Actions taken:
April 25, 2000: received issue
August 3, 2001: closed issue

Discussion:

It is generally considered that with the new CSIv2 protocol that working on this subject  will not benefit the workablity of security service. It is better left to a new RFP.

Issue 3591: URL format for IIOP-SSL (sec-rev)

Click here for this issue's archive.
Source: AdNovum Informatik (Mr. Stefan Wengi, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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'?

Resolution: close without action
Revised Text:
Actions taken:
May 2, 2000: received issue
August 3, 2001: closed issue

Discussion:

This issue belongs to Interoperable Naming. And in any case, this  argument has  been debated in interoperable naming and rejected. INS is only meant  to bootstrap ORBs, not generally to create arbitrary IORs from human  readable  text strings. The form IOR:..... is sufficient for general IORs with  security  information.

Issue 3620: Differ by case IDL error in "Right" structure Security module (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The Security Service 1.7 specification:    	https://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 {          ExtensibleFamily        rights_family;          string                  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.

Resolution: Apply revision and close issue.
Revised Text: Change the "right" field to "the_right" in Applendix A.2
Actions taken:
May 19, 2000: received issue
August 3, 2001: closed issue

Discussion:

This change will only affect implemenations that were broken in the first place.  Interoperability will not be affected.

Issue 3629: SecurityReplaceable module errors in Security spec 1.7 (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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          );

Resolution: close with revised text
Revised Text: Editorial Changes: Section 15.7.2 Implementation-Level Security Object Interfaces Remove extraneous comma from "process_refresh_token" on Page 15-180 Remove extraneous comma from "process_discard_token" on Page 15-181 Appendix A.7: Security Replaceable Service Interfaces Remove extraneous semi-colon from "get_supported_authen_methods". Remove extraneous comma from "process_discard_token" page 15-330.
Actions taken:
May 19, 2000: received issue
August 3, 2001: closed issue

Issue 3630: CCM spec and Security Service 1.7 do not agree (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text: The Components specification made the necessary changes for all relevant interfaces of the Security specifications that were then existent, and these changes can be found in document ptc/99-10-08. They are itemized below as editing instructions in group A. A few new local interfaces were added by the Security RTF since then like TargetCredentials and SecurityManager, and the changes relevant to those are enumerated in editing instructions in group B below. In general the changes involve identifying all locality constrained interface as "local interface" in IDL, and making corresponding changes in the supporting text. Apply Revisions and close issue. Revised Text: All changes are relative to security/00-11-03. Group A: From adopted component specification. Group B: New interfaces added by Security RTF. Group C: Bugs introduced by editor of security/00-11-03. 1. [A] Replace para 261 on page 15-48 by: "Certain interfaces are declared to be local. The locality properties required of them are described in CORBA Core 2.4 Chapter 3 IDL Syntax and Semantics." 2. [A] In para 423 on page 15-81 replace "locality constrained" by "local". 3. [A] In para 472 on page 15-90 replace "locality constrained" by "local". 4. [A] In the specification for parameter "creds immediately following para 476 on page 15-92 replace the phrase "the locality constrained" by "a local". 5. [A] In para 483 on page 15-94 replace "locality constrained" by "local". 6. [B] In para 515 on page 15-100 replace "locality constrained" by "local". 7. [B] In IDL for ReceivedCredentials immediately following para 516 on page 15-101 replace interface ReceivedCredentials : Credentials { // Locality Constrained by local interface ReceivedCredentials : Credentials { 8. [B] In para 524 on page 15-102 replace "locality constrained" by "local". 9. [B] In IDL for TargetCredentials immediately following para 524 on page 15-102 replace interface TargetCredentials : Credentials { // Locality Constrained by local interface TargetCredentials : Credentials { 10.[A] In para 610 on page 15-116 replace "locality constrained" by "local". Also remove para 611 since it merely repeats what is already said in para 610 regarding locality constraint/local. 11.[A] In para 616 on page 15-117 replace "locality constrained" by "local". 12.[A] In para 619 on page 15-118 replace two instances of "locality constrained" by "local". Replace "needs to be not thus constrained" to "need not be local". 13. [A] In para 630 on page 15-120 replace "locality constrained" by "local". 14. [A] In para 634 on page 15-121 replace "locality constrained" by "local". 15. [A] In para 842 on page 15-166 replace "locality constrained" by "local". 16.[A] In para 844 on page 15-166 replace "locality constrained" by "local". 17.[A] In the specification for parameter "creds immediately following para 846 on page 15-167 replace the phrase "the locality constrained" by "a local". 18.[A] In para 860 on page 15-171 replace "locality constrained" by "local". 19.[A] In para 882 on page 15-180 replace "locality constrained" by "local". 20.[A] In para 900 on page 15-183 replace "locality constrained" by "local". 21.[A] In para 916 on page 15-185 replace "locality constrained" by "local". 22.[A] In IDL immediately following para 916 on page 15-185 replace the first line by: local interface AccessDecision { 23.22. [C] In IDL for SecurityLevel1 on page 15-306 Section A.3 change local Current : CORBA::Current { to local interface Current : CORBA::Current { 24.[C] In section A.4 and A.7 make the following changes: 1. Remove all occurrences of the string "// Locality Constrained" 2. replace all occurrences of the string "local" by the string "local interface". 25.[C] In section A.7 replace the string "interface" by the string "local interface" in the lines of IDL that introduce the definition of the interfaces AuditChannel, AuditDecision and AccessDecision. All these appear on page 15-323 immediately preceding section A.8. 26.[A] In para 1751 on page 15-368 replace "locality constrained" by "local". 27.Remove para 1921 on page 395 which defines locality constrained. Since we have removed all occurrences of "locality constrained" from the document, this definition is not needed any more.
Actions taken:
May 19, 2000: received issue
August 3, 2001: closed issue

Issue 3638: Fix description of parameters to Credentials::set_attributes (sec-rev)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mr. Edward J. Barkmeyer, ebarkmeyer(at)thematix.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: close, same as Issue 3442
Revised Text:
Actions taken:
May 22, 2000: received issue
August 3, 2001: closed issue

Issue 3765: Inconsistency in security service spec (sec-rev)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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 {  >         ExtensibleFamily rights_family;  >         string 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?

Resolution: Same as issue 3620. Classify as duplicate.
Revised Text:
Actions taken:
July 21, 2000: received issue
August 3, 2001: closed issue

Issue 5526: SECIOP ContextId (sec-rev)

Click here for this issue's archive.
Source: Adiron, LLC (Mr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA Security SECIOP.      In SECIOP, one RTF changed a field in the SECIOP Message Header  from          struct ulonglong {              unsigned long low;              unsigned long high;      };          // 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.

Resolution:
Revised Text:
Actions taken:
July 19, 2002: received issue

Issue 5527: SECIOP State Machine Discard (sec-rev)

Click here for this issue's archive.
Source: Adiron, LLC (Mr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
July 19, 2002: received issue