Security Service Avatar
  1. OMG Specification

Security Service — All Issues

  • Acronym: SEC
  • Issues Count: 111
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SEC17-5 Which codeset is used in CDR encoding (interop) SEC 1.6 SEC 1.7 Resolved closed
SEC12-64 Credentials in Security rev 1.2 are inconsistent SEC 1.1 SEC 1.2 Duplicate or Merged closed
SEC12-63 Service Context ID Assignment (scenario 2) SEC 1.1 SEC 1.2 Duplicate or Merged closed
SEC12-62 Service Context ID Assignment (scenario 1) SEC 1.1 SEC 1.2 Duplicate or Merged closed
SEC12-61 SecurityLevel2::Object SEC 1.1 SEC 1.2 Duplicate or Merged closed
SEC12-60 Current object question SEC 1.1 SEC 1.2 Duplicate or Merged closed
SEC12-59 Message Level Interceptors SEC 1.1 SEC 1.2 Duplicate or Merged closed
SEC17-4 Capule Specific items residing on thread specific Current SEC 1.6 SEC 1.7 Resolved closed
SEC17-3 How is a SecAttribute"s value field encoded SEC 1.6 SEC 1.7 Resolved closed
SEC13-1 Typo in spec and IDL text SEC 1.2 SEC 1.3 Resolved closed
SEC12-58 Tag value of TAG_SSL_SEC_TRANS SEC 1.1 SEC 1.2 Resolved closed
SEC12-57 Typo on page 6 of SSL spec (orbos/97-02-04) SEC 1.1 SEC 1.2 Resolved closed
SEC12-56 Current and get_current() SEC 1.1 SEC 1.2 Resolved closed
SEC12-55 DomainAccessPolicy incorrectly inherits from CORBA SEC 1.1 SEC 1.2 Resolved closed
SEC12-53 What does "-" mean in "corba::-g"? SEC 1.1 SEC 1.2 Resolved closed
SEC12-54 Initiator is undefined on pg 145 SEC 1.1 SEC 1.2 Resolved closed
SEC12-48 Missing explanation of the use of MessageInContext message SEC 1.1 SEC 1.2 Resolved closed
SEC12-52 get_domain_policy SEC 1.1 SEC 1.2 Resolved closed
SEC12-49 Is enum EvidenceType intended to be a complete list? SEC 1.1 SEC 1.2 Resolved closed
SEC12-51 AssociationOption SEC 1.1 SEC 1.2 Resolved closed
SEC12-50 Definition of identity domains confusing SEC 1.1 SEC 1.2 Resolved closed
SEC12-46 Improve description of secure invocation policy rationalization SEC 1.1 SEC 1.2 Resolved closed
SEC12-45 CORBASEC IDL files in Appendix A SEC 1.1 SEC 1.2 Resolved closed
SEC12-47 Definition of MessageInContext needs to be cleared SEC 1.1 SEC 1.2 Resolved closed
SEC12-40 Problems related to "local constrainedness" of Cresentials (2) SEC 1.1 SEC 1.2 Resolved closed
SEC12-38 Const declarations missing for audit event types? SEC 1.1 SEC 1.2 Resolved closed
SEC12-43 SSL/CORBA-How does client choose to use SSL? SEC 1.1 SEC 1.2 Resolved closed
SEC12-42 Exceptions to be thrown by (administrative) operations SEC 1.1 SEC 1.2 Resolved closed
SEC12-44 Object side-effect semantics SEC 1.1 SEC 1.2 Resolved closed
SEC12-39 Problems related to "locally constrained" of Credentials (1) SEC 1.1 SEC 1.2 Resolved closed
SEC12-41 DomainAccessPolicy operation question SEC 1.1 SEC 1.2 Resolved closed
SEC12-24 What does get_audit_selectors return? SEC 1.1 SEC 1.2 Resolved closed
SEC12-23 What if there are no attribute mappings in a policy? SEC 1.1 SEC 1.2 Resolved closed
SEC12-16 make_domain_manager issue SEC 1.1 SEC 1.2 Resolved closed
SEC12-15 Use of NoDelegation is inconsistent with terms used on p 44 SEC 1.1 SEC 1.2 Resolved closed
SEC12-21 Current object needs further specification SEC 1.1 SEC 1.2 Resolved closed
SEC12-20 Editorial change SEC 1.1 SEC 1.2 Resolved closed
SEC12-22 How do add/delete RequiredRights interface entries? SEC 1.1 SEC 1.2 Resolved closed
SEC12-26 Credentials object underspecified SEC 1.1 SEC 1.2 Resolved closed
SEC12-25 SecurityLevel2::Object needs further specification SEC 1.1 SEC 1.2 Resolved closed
SEC12-18 Capabilities is under defined SEC 1.1 SEC 1.2 Resolved closed
SEC12-17 What does DetectMisordering mean for a multithreaded process? SEC 1.1 SEC 1.2 Resolved closed
SEC12-19 User Sponsor section should be rewritten SEC 1.1 SEC 1.2 Resolved closed
SEC12-1 Message Level interceptors SEC 1.1 SEC 1.2 Resolved closed
SEC15-13 Does AuditPolicy use an implicit ALL combinator? SEC 1.1 SEC 1.5 Resolved closed
SEC16-8 SSL/CORBA-How does client choose to use SSL? SEC 1.1 SEC 1.6 Resolved closed
SEC15-14 When is the "ObjectRef" selector type used? SEC 1.1 SEC 1.5 Resolved closed
SEC15-15 RequiredRights SEC 1.1 SEC 1.5 Resolved closed
SEC12-33 Constant values for ServiceOptions (Section B.9.1) SEC 1.1 SEC 1.2 Resolved closed
SEC12-32 SSL Protocol SEC 1.1 SEC 1.2 Resolved closed
SEC12-36 Policy Object SEC 1.1 SEC 1.2 Resolved closed
SEC12-35 Policy types defined in B.9.2 pertain to Security SEC 1.1 SEC 1.2 Resolved closed
SEC12-31 IDL in text needs fully qualified names SEC 1.1 SEC 1.2 Resolved closed
SEC12-37 Access to AccessDecision and AuditDecision objects? SEC 1.1 SEC 1.2 Resolved closed
SEC12-29 Insufficient specification of Exceptions SEC 1.1 SEC 1.2 Resolved closed
SEC12-34 PolicyType declared as enum (section B.9.2) SEC 1.1 SEC 1.2 Resolved closed
SEC12-30 Inappropriate use of the word interface SEC 1.1 SEC 1.2 Resolved closed
SEC12-27 Missing IDL in Appendix A SEC 1.1 SEC 1.2 Resolved closed
SEC12-28 Life cycle of Policy object is not specified SEC 1.1 SEC 1.2 Resolved closed
SEC12-9 How do I get to a specific binding while making an invokation? SEC 1.1 SEC 1.2 Resolved closed
SEC12-8 Intermediate objects SEC 1.1 SEC 1.2 Resolved closed
SEC12-13 Meaning of "as specified object" SEC 1.1 SEC 1.2 Resolved closed
SEC12-12 What Security policy Domain during BOA::create? SEC 1.1 SEC 1.2 Resolved closed
SEC12-6 SECIOP protocol definition SEC 1.1 SEC 1.2 Resolved closed
SEC12-5 SECIOP servers cannot contact SECIOP clients SEC 1.1 SEC 1.2 Resolved closed
SEC12-11 Clarify what creating object is SEC 1.1 SEC 1.2 Resolved closed
SEC12-10 set_privileges adequate? SEC 1.1 SEC 1.2 Resolved closed
SEC12-3 Clarify language on Non-Repudiation delivery authority SEC 1.1 SEC 1.2 Resolved closed
SEC12-14 Is it intent of specification to only secure BOAs? SEC 1.1 SEC 1.2 Resolved closed
SEC12-2 Provide a "day_of_week" audit event selector SEC 1.1 SEC 1.2 Resolved closed
SEC12-7 SECIOP conformant server timed out SEC 1.1 SEC 1.2 Resolved closed
SEC12-4 Provide message identification information SEC 1.1 SEC 1.2 Resolved closed
SEC15-11 Inheritance not properly accounted in audit operation parameters SEC 1.1 SEC 1.5 Resolved closed
SEC15-10 Which interface apply RequiredRights to SEC 1.1 SEC 1.5 Resolved closed
SEC15-9 QOP discovered in SecurityContext SEC 1.1 SEC 1.5 Resolved closed
SEC15-8 get_security_names issue SEC 1.1 SEC 1.5 Resolved closed
SEC15-12 Why do DomainAccessPolicy set methods have family arguments? SEC 1.1 SEC 1.5 Resolved closed
SEC18-1 Regarding Principal Authenticator in security/99-12-02 SEC 1.7 SEC 1.8 Resolved closed
SEC18-2 SECIOP Sequencing Layer is superfluous and redundant SEC 1.7 SEC 1.8 Resolved closed
SEC18-4 AuditChannel::audit_write has Opaque SEC 1.7 SEC 1.8 Resolved closed
SEC18-3 editorial revisions to address issue #1765 were not completed correctly SEC 1.7 SEC 1.8 Resolved closed
SEC17-2 Public Attribute extraneous and inefficient SEC 1.6 SEC 1.7 Resolved closed
SEC17-1 Security: SSL reference no longer valid SEC 1.6 SEC 1.7 Resolved closed
SEC14-55 Credentails.set_privileges() SEC 1.3 SEC 1.4 Resolved closed
SEC14-54 SecIOP Architecture SEC 1.3 SEC 1.4 Resolved closed
SEC15-2 get_security_names SEC 1.4 SEC 1.5 Resolved closed
SEC15-1 PrincipalAuthenticator and Current SEC 1.4 SEC 1.5 Resolved closed
SEC14-57 DelegationMode SEC 1.3 SEC 1.4 Resolved closed
SEC14-56 Principal Authenticator SEC 1.3 SEC 1.4 Resolved closed
SEC14-53 Extension to SecurityContext to support SECIOP::DiscardContext SEC 1.3 SEC 1.4 Resolved closed
SEC14-52 Paragraph 19, section 15.8.4.2 SEC 1.3 SEC 1.4 Resolved closed
SEC18-10 CCM spec and Security Service 1.7 do not agree SEC 1.7 SEC 1.8 Resolved closed
SEC18-9 SecurityReplaceable module errors in Security spec 1.7 SEC 1.7 SEC 1.8 Resolved closed
SEC18-8 Differ by case IDL error in "Right" structure Security module SEC 1.7 SEC 1.8 Resolved closed
SEC18-12 Inconsistency in security service spec SEC 1.7 SEC 1.8 Resolved closed
SEC18-7 URL format for IIOP-SSL SEC 1.7 SEC 1.8 Resolved closed
SEC18-6 No Standard Authentication Mechanism Specification for Kerberos SEC 1.7 SEC 1.8 Resolved closed
SEC18-5 SecurityContext::process_context_token SEC 1.7 SEC 1.8 Resolved closed
SEC18-11 Fix description of parameters to Credentials::set_attributes SEC 1.7 SEC 1.8 Resolved closed
SEC15-7 Table 15-25 Attribute Values lists family 0 attributes as family 1 SEC 1.4 SEC 1.5 Resolved closed
SEC15-6 SecurityAdmin::DomainAccessPolicy::grant_rights takes SecAttribute SEC 1.4 SEC 1.5 Resolved closed
SEC15-5 Table description incorrect in Security Service SEC 1.4 SEC 1.5 Resolved closed
SEC15-4 SecurityLevel2::Current policy factory operation SEC 1.4 SEC 1.5 Resolved closed
SEC15-3 Typo in 15.7.1.1, p.15-145, very last bullet: SEC 1.4 SEC 1.5 Resolved closed
SEC16-5 Need to get Received Credentials from the Server SEC 1.5 SEC 1.6 Resolved closed
SEC16-4 Security: SECIOP SEC 1.5 SEC 1.6 Resolved closed
SEC16-3 More nil/NULL arguments that need to be removed SEC 1.5 SEC 1.6 Resolved closed
SEC16-7 Inappropriate examples of Integrity Violations SEC 1.5 SEC 1.6 Resolved closed
SEC16-6 Channel Bindings are underspecified SEC 1.5 SEC 1.6 Resolved closed
SEC16-2 accept_security_contect() creds parameter SEC 1.5 SEC 1.6 Resolved closed
SEC16-1 del parameter of set_delegation should be Security::DelegationDirective SEC 1.5 SEC 1.6 Resolved closed

Issues Descriptions

Which codeset is used in CDR encoding (interop)

  • Key: SEC17-5
  • Legacy Issue Number: 2708
  • Status: closed  
  • Source: University of California, Irvine ( Carlos O'Ryan)
  • 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.

  • Reported: SEC 1.6 — Tue, 8 Jun 1999 04:00 GMT
  • Disposition: Resolved — SEC 1.7
  • Disposition Summary:

    to Close with agreed change

  • Updated: Sat, 7 Mar 2015 09:03 GMT

Credentials in Security rev 1.2 are inconsistent

  • Key: SEC12-64
  • Legacy Issue Number: 634
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Tue, 29 Jul 1997 04:00 GMT
  • Disposition: Duplicate or Merged — SEC 1.2
  • Disposition Summary:

    resolved close issue

  • Updated: Sat, 7 Mar 2015 09:03 GMT

Service Context ID Assignment (scenario 2)

  • Key: SEC12-63
  • Legacy Issue Number: 308
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Wed, 13 Nov 1996 05:00 GMT
  • Disposition: Duplicate or Merged — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Sat, 7 Mar 2015 09:03 GMT

Service Context ID Assignment (scenario 1)

  • Key: SEC12-62
  • Legacy Issue Number: 307
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Wed, 13 Nov 1996 05:00 GMT
  • Disposition: Duplicate or Merged — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Sat, 7 Mar 2015 09:03 GMT

SecurityLevel2::Object

  • Key: SEC12-61
  • Legacy Issue Number: 152
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Thu, 3 Oct 1996 04:00 GMT
  • Disposition: Duplicate or Merged — SEC 1.2
  • Disposition Summary:

    Closed issue, same as issue # 381

  • Updated: Sat, 7 Mar 2015 09:03 GMT

Current object question

  • Key: SEC12-60
  • Legacy Issue Number: 151
  • Status: closed  
  • Source: Anonymous
  • 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()?

  • Reported: SEC 1.1 — Thu, 3 Oct 1996 04:00 GMT
  • Disposition: Duplicate or Merged — SEC 1.2
  • Disposition Summary:

    Closed issue, same as issue 370

  • Updated: Sat, 7 Mar 2015 09:03 GMT

Message Level Interceptors

  • Key: SEC12-59
  • Legacy Issue Number: 138
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Fri, 27 Sep 1996 04:00 GMT
  • Disposition: Duplicate or Merged — SEC 1.2
  • Disposition Summary:

    closed issue, same as issue 282

  • Updated: Sat, 7 Mar 2015 09:03 GMT

Capule Specific items residing on thread specific Current

  • Key: SEC17-4
  • Legacy Issue Number: 2704
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.6 — Fri, 4 Jun 1999 04:00 GMT
  • Disposition: Resolved — SEC 1.7
  • Disposition Summary:

    Close issue 2704 "Current contains thread specific information".

  • Updated: Fri, 6 Mar 2015 21:37 GMT

How is a SecAttribute"s value field encoded

  • Key: SEC17-3
  • Legacy Issue Number: 2703
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.6 — Fri, 4 Jun 1999 04:00 GMT
  • Disposition: Resolved — SEC 1.7
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Typo in spec and IDL text

  • Key: SEC13-1
  • Legacy Issue Number: 972
  • Status: closed  
  • Source: Anonymous
  • 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;

  • Reported: SEC 1.2 — Mon, 16 Feb 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.3
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 21:34 GMT

Tag value of TAG_SSL_SEC_TRANS

  • Key: SEC12-58
  • Legacy Issue Number: 713
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Wed, 27 Aug 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Typo on page 6 of SSL spec (orbos/97-02-04)

  • Key: SEC12-57
  • Legacy Issue Number: 661
  • Status: closed  
  • Source: Anonymous
  • 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"

  • Reported: SEC 1.1 — Fri, 8 Aug 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Current and get_current()

  • Key: SEC12-56
  • Legacy Issue Number: 536
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Wed, 19 Mar 1997 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

DomainAccessPolicy incorrectly inherits from CORBA

  • Key: SEC12-55
  • Legacy Issue Number: 372
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    already fixed, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

What does "-" mean in "corba::-g"?

  • Key: SEC12-53
  • Legacy Issue Number: 368
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Initiator is undefined on pg 145

  • Key: SEC12-54
  • Legacy Issue Number: 369
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Missing explanation of the use of MessageInContext message

  • Key: SEC12-48
  • Legacy Issue Number: 346
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

get_domain_policy

  • Key: SEC12-52
  • Legacy Issue Number: 367
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Is enum EvidenceType intended to be a complete list?

  • Key: SEC12-49
  • Legacy Issue Number: 356
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

AssociationOption

  • Key: SEC12-51
  • Legacy Issue Number: 366
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Definition of identity domains confusing

  • Key: SEC12-50
  • Legacy Issue Number: 363
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Improve description of secure invocation policy rationalization

  • Key: SEC12-46
  • Legacy Issue Number: 340
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Improve description of secure invocation policy rationalization

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

CORBASEC IDL files in Appendix A

  • Key: SEC12-45
  • Legacy Issue Number: 180
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Fri, 11 Oct 1996 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    closed issue, resolved

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Definition of MessageInContext needs to be cleared

  • Key: SEC12-47
  • Legacy Issue Number: 345
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Problems related to "local constrainedness" of Cresentials (2)

  • Key: SEC12-40
  • Legacy Issue Number: 650
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Fri, 1 Aug 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    This issue was fixed in revision 1.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Const declarations missing for audit event types?

  • Key: SEC12-38
  • Legacy Issue Number: 635
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Tue, 29 Jul 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SSL/CORBA-How does client choose to use SSL?

  • Key: SEC12-43
  • Legacy Issue Number: 718
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: SEC 1.1 — Wed, 27 Aug 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    same as issue 714---closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exceptions to be thrown by (administrative) operations

  • Key: SEC12-42
  • Legacy Issue Number: 717
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Thu, 28 Aug 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Object side-effect semantics

  • Key: SEC12-44
  • Legacy Issue Number: 720
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Fri, 12 Sep 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problems related to "locally constrained" of Credentials (1)

  • Key: SEC12-39
  • Legacy Issue Number: 649
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Fri, 1 Aug 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DomainAccessPolicy operation question

  • Key: SEC12-41
  • Legacy Issue Number: 712
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Tue, 26 Aug 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    same as issue 373--closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What does get_audit_selectors return?

  • Key: SEC12-24
  • Legacy Issue Number: 377
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What if there are no attribute mappings in a policy?

  • Key: SEC12-23
  • Legacy Issue Number: 376
  • Status: closed  
  • Source: Anonymous
  • 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..

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    Just ignore it

  • Updated: Fri, 6 Mar 2015 20:58 GMT

make_domain_manager issue

  • Key: SEC12-16
  • Legacy Issue Number: 358
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of NoDelegation is inconsistent with terms used on p 44

  • Key: SEC12-15
  • Legacy Issue Number: 355
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Current object needs further specification

  • Key: SEC12-21
  • Legacy Issue Number: 370
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial change

  • Key: SEC12-20
  • Legacy Issue Number: 365
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How do add/delete RequiredRights interface entries?

  • Key: SEC12-22
  • Legacy Issue Number: 375
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Credentials object underspecified

  • Key: SEC12-26
  • Legacy Issue Number: 475
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Tue, 21 Jan 1997 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SecurityLevel2::Object needs further specification

  • Key: SEC12-25
  • Legacy Issue Number: 381
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Capabilities is under defined

  • Key: SEC12-18
  • Legacy Issue Number: 362
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What does DetectMisordering mean for a multithreaded process?

  • Key: SEC12-17
  • Legacy Issue Number: 361
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

User Sponsor section should be rewritten

  • Key: SEC12-19
  • Legacy Issue Number: 364
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Message Level interceptors

  • Key: SEC12-1
  • Legacy Issue Number: 282
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Mon, 21 Oct 1996 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Does AuditPolicy use an implicit ALL combinator?

  • Key: SEC15-13
  • Legacy Issue Number: 378
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SSL/CORBA-How does client choose to use SSL?

  • Key: SEC16-8
  • Legacy Issue Number: 714
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Wed, 27 Aug 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.6
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

When is the "ObjectRef" selector type used?

  • Key: SEC15-14
  • Legacy Issue Number: 379
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    same as issue 360, close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RequiredRights

  • Key: SEC15-15
  • Legacy Issue Number: 716
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Thu, 28 Aug 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    same as issue359, close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constant values for ServiceOptions (Section B.9.1)

  • Key: SEC12-33
  • Legacy Issue Number: 552
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Thu, 24 Apr 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SSL Protocol

  • Key: SEC12-32
  • Legacy Issue Number: 544
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Thu, 17 Apr 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Policy Object

  • Key: SEC12-36
  • Legacy Issue Number: 555
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Thu, 24 Apr 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Policy types defined in B.9.2 pertain to Security

  • Key: SEC12-35
  • Legacy Issue Number: 554
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Thu, 24 Apr 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL in text needs fully qualified names

  • Key: SEC12-31
  • Legacy Issue Number: 539
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Thu, 10 Apr 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Access to AccessDecision and AuditDecision objects?

  • Key: SEC12-37
  • Legacy Issue Number: 630
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Wed, 16 Jul 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Insufficient specification of Exceptions

  • Key: SEC12-29
  • Legacy Issue Number: 537
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Thu, 10 Apr 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PolicyType declared as enum (section B.9.2)

  • Key: SEC12-34
  • Legacy Issue Number: 553
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Thu, 24 Apr 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inappropriate use of the word interface

  • Key: SEC12-30
  • Legacy Issue Number: 538
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Thu, 10 Apr 1997 04:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing IDL in Appendix A

  • Key: SEC12-27
  • Legacy Issue Number: 487
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Mon, 3 Feb 1997 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Life cycle of Policy object is not specified

  • Key: SEC12-28
  • Legacy Issue Number: 534
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Tue, 25 Mar 1997 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How do I get to a specific binding while making an invokation?

  • Key: SEC12-9
  • Legacy Issue Number: 349
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Intermediate objects

  • Key: SEC12-8
  • Legacy Issue Number: 348
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaning of "as specified object"

  • Key: SEC12-13
  • Legacy Issue Number: 353
  • Status: closed  
  • Source: Anonymous
  • 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."?

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What Security policy Domain during BOA::create?

  • Key: SEC12-12
  • Legacy Issue Number: 352
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    close issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SECIOP protocol definition

  • Key: SEC12-6
  • Legacy Issue Number: 343
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SECIOP servers cannot contact SECIOP clients

  • Key: SEC12-5
  • Legacy Issue Number: 342
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify what creating object is

  • Key: SEC12-11
  • Legacy Issue Number: 351
  • Status: closed  
  • Source: Anonymous
  • 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>

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

set_privileges adequate?

  • Key: SEC12-10
  • Legacy Issue Number: 350
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify language on Non-Repudiation delivery authority

  • Key: SEC12-3
  • Legacy Issue Number: 338
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Is it intent of specification to only secure BOAs?

  • Key: SEC12-14
  • Legacy Issue Number: 354
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide a "day_of_week" audit event selector

  • Key: SEC12-2
  • Legacy Issue Number: 337
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Provide a "day_of week" audit event selector

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    issue resolved, close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SECIOP conformant server timed out

  • Key: SEC12-7
  • Legacy Issue Number: 344
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide message identification information

  • Key: SEC12-4
  • Legacy Issue Number: 339
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.2
  • Disposition Summary:

    Close issue 339: Provide message identification information

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance not properly accounted in audit operation parameters

  • Key: SEC15-11
  • Legacy Issue Number: 360
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Which interface apply RequiredRights to

  • Key: SEC15-10
  • Legacy Issue Number: 359
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    clarify specification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QOP discovered in SecurityContext

  • Key: SEC15-9
  • Legacy Issue Number: 347
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_security_names issue

  • Key: SEC15-8
  • Legacy Issue Number: 341
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Why do DomainAccessPolicy set methods have family arguments?

  • Key: SEC15-12
  • Legacy Issue Number: 373
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.1 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Regarding Principal Authenticator in security/99-12-02

  • Key: SEC18-1
  • Legacy Issue Number: 3262
  • Status: closed  
  • Source: Hewlett-Packard ( Jan Pachl)
  • 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.

  • Reported: SEC 1.7 — Thu, 27 Jan 2000 05:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    close with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SECIOP Sequencing Layer is superfluous and redundant

  • Key: SEC18-2
  • Legacy Issue Number: 3272
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • 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.

  • Reported: SEC 1.7 — Fri, 4 Feb 2000 05:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    closed with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AuditChannel::audit_write has Opaque

  • Key: SEC18-4
  • Legacy Issue Number: 3571
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • 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".

  • Reported: SEC 1.7 — Wed, 19 Apr 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    close with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

editorial revisions to address issue #1765 were not completed correctly

  • Key: SEC18-3
  • Legacy Issue Number: 3442
  • Status: closed  
  • Source: ( Luis Maldonado)
  • 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.

  • Reported: SEC 1.7 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    closed with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Public Attribute extraneous and inefficient

  • Key: SEC17-2
  • Legacy Issue Number: 2800
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.6 — Mon, 12 Jul 1999 04:00 GMT
  • Disposition: Resolved — SEC 1.7
  • Disposition Summary:

    Close Issue 2800 _Public

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Security: SSL reference no longer valid

  • Key: SEC17-1
  • Legacy Issue Number: 2789
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.6 — Wed, 7 Jul 1999 04:00 GMT
  • Disposition: Resolved — SEC 1.7
  • Disposition Summary:

    close issue 2789

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Credentails.set_privileges()

  • Key: SEC14-55
  • Legacy Issue Number: 1765
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.3 — Sun, 2 Aug 1998 04:00 GMT
  • Disposition: Resolved — SEC 1.4
  • Disposition Summary:

    Close Issue 1765: set_privileges

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SecIOP Architecture

  • Key: SEC14-54
  • Legacy Issue Number: 1723
  • Status: closed  
  • Source: Anonymous
  • 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".

  • Reported: SEC 1.3 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — SEC 1.4
  • Disposition Summary:

    Close issue 1723: SecIOP Architecture

  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_security_names

  • Key: SEC15-2
  • Legacy Issue Number: 2094
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.4 — Fri, 16 Oct 1998 04:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    :Current.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PrincipalAuthenticator and Current

  • Key: SEC15-1
  • Legacy Issue Number: 2027
  • Status: closed  
  • Source: Anonymous
  • 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()

  • Reported: SEC 1.4 — Fri, 2 Oct 1998 04:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    Close issue 2027: Principal Authenticator and Current

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DelegationMode

  • Key: SEC14-57
  • Legacy Issue Number: 1930
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.3 — Wed, 2 Sep 1998 04:00 GMT
  • Disposition: Resolved — SEC 1.4
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Principal Authenticator

  • Key: SEC14-56
  • Legacy Issue Number: 1847
  • Status: closed  
  • Source: Anonymous
  • 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
    );

  • Reported: SEC 1.3 — Fri, 21 Aug 1998 04:00 GMT
  • Disposition: Resolved — SEC 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Extension to SecurityContext to support SECIOP::DiscardContext

  • Key: SEC14-53
  • Legacy Issue Number: 1661
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.3 — Fri, 10 Jul 1998 04:00 GMT
  • Disposition: Resolved — SEC 1.4
  • Disposition Summary:

    :DiscardContext message.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Paragraph 19, section 15.8.4.2

  • Key: SEC14-52
  • Legacy Issue Number: 1633
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.3 — Thu, 2 Jul 1998 04:00 GMT
  • Disposition: Resolved — SEC 1.4
  • Disposition Summary:

    Close issue 1633: Paragraph 19, section 15.8.4.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM spec and Security Service 1.7 do not agree

  • Key: SEC18-10
  • Legacy Issue Number: 3630
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.7 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SecurityReplaceable module errors in Security spec 1.7

  • Key: SEC18-9
  • Legacy Issue Number: 3629
  • Status: closed  
  • Source: Anonymous
  • 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
    );

  • Reported: SEC 1.7 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    close with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Differ by case IDL error in "Right" structure Security module

  • Key: SEC18-8
  • Legacy Issue Number: 3620
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The Security Service 1.7 specification:

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

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

    // Declarations related to Rights

    struct Right

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

  • Reported: SEC 1.7 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    Apply revision and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency in security service spec

  • Key: SEC18-12
  • Legacy Issue Number: 3765
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: SEC 1.7 — Fri, 21 Jul 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    Same as issue 3620. Classify as duplicate.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

URL format for IIOP-SSL

  • Key: SEC18-7
  • Legacy Issue Number: 3591
  • Status: closed  
  • Source: AdNovum Informatik ( Stefan Wengi)
  • 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'?

  • Reported: SEC 1.7 — Tue, 2 May 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    close without action

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No Standard Authentication Mechanism Specification for Kerberos

  • Key: SEC18-6
  • Legacy Issue Number: 3577
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • 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.

  • Reported: SEC 1.7 — Tue, 25 Apr 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    No Change and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SecurityContext::process_context_token

  • Key: SEC18-5
  • Legacy Issue Number: 3572
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.7 — Wed, 19 Apr 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    Apply revisions and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fix description of parameters to Credentials::set_attributes

  • Key: SEC18-11
  • Legacy Issue Number: 3638
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • 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.

  • Reported: SEC 1.7 — Mon, 22 May 2000 04:00 GMT
  • Disposition: Resolved — SEC 1.8
  • Disposition Summary:

    close, same as Issue 3442

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 15-25 Attribute Values lists family 0 attributes as family 1

  • Key: SEC15-7
  • Legacy Issue Number: 2199
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.4 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SecurityAdmin::DomainAccessPolicy::grant_rights takes SecAttribute

  • Key: SEC15-6
  • Legacy Issue Number: 2170
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.4 — Thu, 5 Nov 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    Close issue 2170.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table description incorrect in Security Service

  • Key: SEC15-5
  • Legacy Issue Number: 2169
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.4 — Thu, 5 Nov 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    Close issue 2169. Table description incorrect

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SecurityLevel2::Current policy factory operation

  • Key: SEC15-4
  • Legacy Issue Number: 2161
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.4 — Tue, 3 Nov 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    :Current should be

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in 15.7.1.1, p.15-145, very last bullet:

  • Key: SEC15-3
  • Legacy Issue Number: 2122
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.4 — Tue, 27 Oct 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.5
  • Disposition Summary:

    :get_delegation_mode should be

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need to get Received Credentials from the Server

  • Key: SEC16-5
  • Legacy Issue Number: 2440
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.5 — Fri, 5 Feb 1999 05:00 GMT
  • Disposition: Resolved — SEC 1.6
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Security: SECIOP

  • Key: SEC16-4
  • Legacy Issue Number: 2437
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: SEC 1.5 — Thu, 4 Feb 1999 05:00 GMT
  • Disposition: Resolved — SEC 1.6
  • Disposition Summary:

    Close issue 2437 "SECIOP needs an internet address designation"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

More nil/NULL arguments that need to be removed

  • Key: SEC16-3
  • Legacy Issue Number: 2344
  • Status: closed  
  • Source: Anonymous
  • 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".

  • Reported: SEC 1.5 — Mon, 25 Jan 1999 05:00 GMT
  • Disposition: Resolved — SEC 1.6
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inappropriate examples of Integrity Violations

  • Key: SEC16-7
  • Legacy Issue Number: 2452
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.5 — Fri, 12 Feb 1999 05:00 GMT
  • Disposition: Resolved — SEC 1.6
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Channel Bindings are underspecified

  • Key: SEC16-6
  • Legacy Issue Number: 2451
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.5 — Fri, 12 Feb 1999 05:00 GMT
  • Disposition: Resolved — SEC 1.6
  • Disposition Summary:

    Close issue 2451 "Channel Bindings are underspecified"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

accept_security_contect() creds parameter

  • Key: SEC16-2
  • Legacy Issue Number: 2260
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.5 — Wed, 16 Dec 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.6
  • Disposition Summary:

    Close issue 2260: accept_security_context() creds parameter

  • Updated: Fri, 6 Mar 2015 20:58 GMT

del parameter of set_delegation should be Security::DelegationDirective

  • Key: SEC16-1
  • Legacy Issue Number: 2259
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: SEC 1.5 — Wed, 16 Dec 1998 05:00 GMT
  • Disposition: Resolved — SEC 1.6
  • Disposition Summary:

    Close issue 2259: del parameter .....

  • Updated: Fri, 6 Mar 2015 20:58 GMT