Issues for Security 1.8 and 1.9 Revision Task Forces discussion list

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

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

Issue 138: Message Level Interceptors
Issue 151: Current object question
Issue 152: SecurityLevel2::Object
Issue 180: CORBASEC IDL files in Appendix A
Issue 282: Message Level interceptors
Issue 307: Service Context ID Assignment (scenario 1)
Issue 308: Service Context ID Assignment (scenario 2)
Issue 337: Provide a "day_of_week" audit event selector
Issue 338: Clarify language on Non-Repudiation delivery authority
Issue 339: Provide message identification information
Issue 340: Improve description of secure invocation policy rationalization
Issue 341: get_security_names issue
Issue 342: SECIOP servers cannot contact SECIOP clients
Issue 343: SECIOP protocol definition
Issue 344: SECIOP conformant server timed out
Issue 345: Definition of MessageInContext needs to be cleared
Issue 346: Missing explanation of the use of MessageInContext message
Issue 347: QOP discovered in SecurityContext
Issue 348: Intermediate objects
Issue 349: How do I get to a specific binding while making an invokation?
Issue 350: set_privileges adequate?
Issue 351: Clarify what creating object is
Issue 352: What Security policy Domain during BOA::create?
Issue 353: Meaning of "as specified object"
Issue 354: Is it intent of specification to only secure BOAs?
Issue 355: Use of NoDelegation is inconsistent with terms used on p 44
Issue 356: Is enum EvidenceType intended to be a complete list?
Issue 358: make_domain_manager issue
Issue 359: Which interface apply RequiredRights to
Issue 360: Inheritance not properly accounted in audit operation parameters
Issue 361: What does DetectMisordering mean for a multithreaded process?
Issue 362: Capabilities is under defined
Issue 363: Definition of identity domains confusing
Issue 364: User Sponsor section should be rewritten
Issue 365: Editorial change
Issue 366: AssociationOption
Issue 367: get_domain_policy
Issue 368: What does "-" mean in "corba::-g"?
Issue 369: Initiator is undefined on pg 145
Issue 370: Current object needs further specification
Issue 372: DomainAccessPolicy incorrectly inherits from CORBA
Issue 373: Why do DomainAccessPolicy set methods have family arguments?
Issue 375: How do add/delete RequiredRights interface entries?
Issue 376: What if there are no attribute mappings in a policy?
Issue 377: What does get_audit_selectors return?
Issue 378: Does AuditPolicy use an implicit ALL combinator?
Issue 379: When is the "ObjectRef" selector type used?
Issue 381: SecurityLevel2::Object needs further specification
Issue 475: Credentials object underspecified
Issue 487: Missing IDL in Appendix A
Issue 534: Life cycle of Policy object is not specified
Issue 536: Current and get_current()
Issue 537: Insufficient specification of Exceptions
Issue 538: Inappropriate use of the word interface
Issue 539: IDL in text needs fully qualified names
Issue 544: SSL Protocol
Issue 552: Constant values for ServiceOptions (Section B.9.1)
Issue 553: PolicyType declared as enum (section B.9.2)
Issue 554: Policy types defined in B.9.2 pertain to Security
Issue 555: Policy Object
Issue 630: Access to AccessDecision and AuditDecision objects?
Issue 634: Credentials in Security rev 1.2 are inconsistent
Issue 635: Const declarations missing for audit event types?
Issue 649: Problems related to "locally constrained" of Credentials (1)
Issue 650: Problems related to "local constrainedness" of Cresentials (2)
Issue 661: Typo on page 6 of SSL spec (orbos/97-02-04)
Issue 712: DomainAccessPolicy operation question
Issue 713: Tag value of TAG_SSL_SEC_TRANS
Issue 714: SSL/CORBA-How does client choose to use SSL?
Issue 716: RequiredRights
Issue 717: Exceptions to be thrown by (administrative) operations
Issue 718: SSL/CORBA-How does client choose to use SSL?
Issue 720: Object side-effect semantics
Issue 972: Typo in spec and IDL text
Issue 1633: Paragraph 19, section 15.8.4.2
Issue 1661: Extension to SecurityContext to support SECIOP::DiscardContext
Issue 1723: SecIOP Architecture
Issue 1765: Credentails.set_privileges()
Issue 1847: Principal Authenticator
Issue 1930: DelegationMode
Issue 2027: PrincipalAuthenticator and Current
Issue 2094: get_security_names
Issue 2122: Typo in 15.7.1.1, p.15-145, very last bullet:
Issue 2161: SecurityLevel2::Current policy factory operation
Issue 2169: Table description incorrect in Security Service
Issue 2170: SecurityAdmin::DomainAccessPolicy::grant_rights takes SecAttribute
Issue 2199: Table 15-25 Attribute Values lists family 0 attributes as family 1
Issue 2259: del parameter of set_delegation should be Security::DelegationDirective
Issue 2260: accept_security_contect() creds parameter
Issue 2344: More nil/NULL arguments that need to be removed
Issue 2437: Security: SECIOP
Issue 2440: Need to get Received Credentials from the Server
Issue 2451: Channel Bindings are underspecified
Issue 2452: Inappropriate examples of Integrity Violations
Issue 2703: How is a SecAttribute"s value field encoded
Issue 2704: Capule Specific items residing on thread specific Current
Issue 2708: Which codeset is used in CDR encoding (interop)
Issue 2789: Security: SSL reference no longer valid
Issue 2800: Public Attribute extraneous and inefficient
Issue 3262: Regarding Principal Authenticator in security/99-12-02
Issue 3272: SECIOP Sequencing Layer is superfluous and redundant
Issue 3442: editorial revisions to address issue #1765 were not completed correctly
Issue 3571: AuditChannel::audit_write has Opaque
Issue 3572: SecurityContext::process_context_token
Issue 3577: No Standard Authentication Mechanism Specification for Kerberos
Issue 3591: URL format for IIOP-SSL
Issue 3620: Differ by case IDL error in "Right" structure Security module
Issue 3629: SecurityReplaceable module errors in Security spec 1.7
Issue 3630: CCM spec and Security Service 1.7 do not agree
Issue 3638: Fix description of parameters to Credentials::set_attributes
Issue 3765: Inconsistency in security service spec

Issue 138: Message Level Interceptors (sec-rev)

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

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

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

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

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

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

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

Summary: Provide a "day_of week" audit event selector

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

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

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.

Summary: Improve description of secure invocation policy rationalization

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.

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

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

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

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.

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.

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.

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

 closed issue

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

 closed issue

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

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>

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?

 closed issue

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

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

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

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

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?

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

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

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

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.

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

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

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.

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.

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.

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

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

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?

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

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.

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?

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.

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

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?

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?

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.

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?

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?

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.

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

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?

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

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

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

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.

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.

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

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

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.

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

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.

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

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

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

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"

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?

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

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?

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

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?

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

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)

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?

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

Summary: Paragraph 19 of section 15.8.4.2 says:
 
 "In this example if mechanism “mech 1” is used the target security name is “MBn1”
 while the association must use integrity replay and misordering options. If mechanism
 “mech 2” is used no mechanism specific security name has been specified and so
 “Manchester branch” is used as the security name. The association options are
 EstablishTrustInClient and Integrity."
 
 The last sentence seems to imply that if "mech 2" is used the top-level 
 association options, and not the association options for "mech 2" are used.
 If this is always the case, then it would seem pointless to bother 
 specifying association options for "mech 2" because they will never be 
 used.  If this is the case (which would also be very strange) only when 
 a tag_sec_name is not present for "mech 2" this should be explained 
 more clearly.
 

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

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

 received issue

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

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.
 
 
 

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

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

 received issue

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

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.
 

:MechandOptions struct only contains options

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

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.
 

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

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.
 

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.
 
 

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.
 

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.
 
 

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

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

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

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.
 

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.
 

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.
 

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.
 

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

 close issue 2704: Current contains thread specific information

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.

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.

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.
 

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.
 

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.

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.

The Security Replaceable Vault may call the PrincpalAuthentciator.

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.

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.

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

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

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.

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.

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.

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

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.

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.

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

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

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.

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.

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?