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