${taskforce.name} Avatar
  1. OMG Task Force

Security RTF — All Issues

  • Key: SEC17
  • Issues Count: 5
Open Closed All
All Issues

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

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

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