Issue 4118: Multiple Privilege Authorities and Supported Naming Types (csiv2-ftf) Source: Syracuse University (Mr. Polar Humenn, polar@adiron.com) Nature: Uncategorized Issue Severity: Summary: Multiple privilege authorities and multiple naming types yield combinatorial problems for the client. Discussion: This issue is sort of in the same regards to Issue 3973 where Ron thinks that having multiple target_name(s) in the AS_ContextSec is a bad idea, of which I agree. The type of the privilege_authorities field in the CSIIOP::SAS_ContextSec structure sequence<ServiceConfiguration>. It suffers the same problem, especially when combined with multiple supported naming types. It is completely hard to determine having multiple privilege authorities and the names that must be used to assert the identity for the privileges. In fact, the client may get back an AuthorizationToken that he doesn't understand, but will need to assert an identity for it's use, quite possibly with endorsement. Having multiple naming types supported per privilege authority is fine, but combine that with multiple ones, and you may get a decision problem for the client. It is better to be able to specify a one-to-one correspondence, locking down the combinations that a server will accept, and the client doesn't have to do any mucking about deciding what will work. Proposed Solution: Singularize the privilege authorities field. Unfortunately IDL has a hard time making a singular field become optional without doing something bizzare, such as: switch(boolean) { true: ServiceConfiguration privilege_authority } which requires a new type, etc. I have two proposals: Proposal 1: We signularize the field in name, i.e. "privilege_authority". Keep the sequence definition. However, stating in the specification at most one must be contained. This can be hinted at as well in IDL. struct SAS_ContextSec{ Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; sequence <ServiceConfiguration,1> privilege_authority; sequence <Security::OID> supported_naming_mechanisms; }; Proposal 2: We specify a ServiceConfigurationSyntax tag for "none", and specify that the sequence of octet associated with it is empty. // Corresponding ServiceName for the SCS_None Syntax should be an empty // sequence octets. const ServiceConfigurationSyntax SCS_None = -1; struct SAS_ContextSec{ Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; ServiceConfiguration privilege_authority; sequence <Security::OID> supported_naming_mechanisms; }; For efficiency I'm in favor of the second approach, because I can just look a the ServiceConfiguration::syntax field and know what to do. The first proposal causes me to look at the length first, index to the first element in the array, and then look at the syntax field. As an aside, I also wouldn't mind changing the sequence<Security::OID> type into a Security::OIDList, but that can be the subject of another issue. Also note, to be specific with the document I am pointing to, I used the "Security" definitions. Hopefully, we will follow one proposal to change the Security::AssociationOptions to CSIIOP::AssociationOptions and Security::OID and Security::OIDList to CSI::OID and CSI::OIDList respectively. Resolution: Close issue with revised text. Revised Text: Base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] Replace Paragraph 148 with the following two paragraphs: The privilege_authorities field contains a sequence of zero or more ServiceConfiguration elements. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. A CSS shall not be required to look beyond the first element of this sequence unless required by the first element. The syntax field within the ServiceConfiguration element identifies the format used to represent the authority. Two alternative formats are currently defined: an ASN.1 encoding of the GeneralNames (as defined in [IETF RFC 2459]) which identify a privilege authority, or a GSS exported name (as defined in [IETF RFC 2743] Section 3.2) encoding of the name of a privilege authority. Actions Taken: Actions taken: January 10, 2001: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 10 Jan 2001 18:46:53 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org cc: issues@omg.org Subject: Issue: Multiple Privilege Authorities and Supported Naming Types Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: l"f!!pQj!!H)#!!R?*e9 Issue Subject : Multiple Privilege Authorities and Supported Naming Types Document: http://cgi.omg.org/pub/csiv2-ftf/draft-adopted-spec.pdf Summary: Multiple privilege authorities and multiple naming types yield combinatorial problems for the client. Discussion: This issue is sort of in the same regards to Issue 3973 where Ron thinks that having multiple target_name(s) in the AS_ContextSec is a bad idea, of which I agree. The type of the privilege_authorities field in the CSIIOP::SAS_ContextSec structure sequence. It suffers the same problem, especially when combined with multiple supported naming types. It is completely hard to determine having multiple privilege authorities and the names that must be used to assert the identity for the privileges. In fact, the client may get back an AuthorizationToken that he doesn't understand, but will need to assert an identity for it's use, quite possibly with endorsement. Having multiple naming types supported per privilege authority is fine, but combine that with multiple ones, and you may get a decision problem for the client. It is better to be able to specify a one-to-one correspondence, locking down the combinations that a server will accept, and the client doesn't have to do any mucking about deciding what will work. Proposed Solution: Singularize the privilege authorities field. Unfortunately IDL has a hard time making a singular field become optional without doing something bizzare, such as: switch(boolean) { true: ServiceConfiguration privilege_authority } which requires a new type, etc. I have two proposals: Proposal 1: We signularize the field in name, i.e. "privilege_authority". Keep the sequence definition. However, stating in the specification at most one must be contained. This can be hinted at as well in IDL. struct SAS_ContextSec{ Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; sequence privilege_authority; sequence supported_naming_mechanisms; }; Proposal 2: We specify a ServiceConfigurationSyntax tag for "none", and specify that the sequence of octet associated with it is empty. // Corresponding ServiceName for the SCS_None Syntax should be an empty // sequence octets. const ServiceConfigurationSyntax SCS_None = -1; struct SAS_ContextSec{ Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; ServiceConfiguration privilege_authority; sequence supported_naming_mechanisms; }; For efficiency I'm in favor of the second approach, because I can just look a the ServiceConfiguration::syntax field and know what to do. The first proposal causes me to look at the length first, index to the first element in the array, and then look at the syntax field. As an aside, I also wouldn't mind changing the sequence type into a Security::OIDList, but that can be the subject of another issue. Also note, to be specific with the document I am pointing to, I used the "Security" definitions. Hopefully, we will follow one proposal to change the Security::AssociationOptions to CSIIOP::AssociationOptions and Security::OID and Security::OIDList to CSI::OID and CSI::OIDList respectively. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 11 Jan 2001 11:03:06 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: csiv2-ftf@omg.org, issues@omg.org Subject: Re: Issue: Multiple Privilege Authorities and Supported Naming Types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;Aj!!)Fpd9Cg7e9G#H!! Polar Humenn wrote: > > Issue > > Subject : Multiple Privilege Authorities and Supported Naming Types > > Document: http://cgi.omg.org/pub/csiv2-ftf/draft-adopted-spec.pdf > > Summary: > > Multiple privilege authorities and multiple naming types yield > combinatorial problems for the client. > > Discussion: > > This issue is sort of in the same regards to Issue 3973 where Ron thinks > that having multiple target_name(s) in the AS_ContextSec is a bad idea, of > which I agree. > > The type of the privilege_authorities field in the CSIIOP::SAS_ContextSec > structure sequence. It suffers the same problem, > especially when combined with multiple supported naming types. > > It is completely hard to determine having multiple privilege authorities > and the names that must be used to assert the identity for the privileges. > In fact, the client may get back an AuthorizationToken that he doesn't > understand, but will need to assert an identity for it's use, quite > possibly with endorsement. Having multiple naming types supported per > privilege authority is fine, but combine that with multiple ones, and you > may get a decision problem for the client. > > It is better to be able to specify a one-to-one correspondence, locking > down the combinations that a server will accept, and the client doesn't > have to do any mucking about deciding what will work. > > Proposed Solution: > > Singularize the privilege authorities field. > > Unfortunately IDL has a hard time making a singular field become optional > without doing something bizzare, such as: > switch(boolean) { > true: ServiceConfiguration privilege_authority > } > which requires a new type, etc. > > I have two proposals: > > Proposal 1: > > We signularize the field in name, i.e. "privilege_authority". Keep the > sequence definition. However, stating in the specification at most one > must be contained. This can be hinted at as well in IDL. > > struct SAS_ContextSec{ > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; > sequence privilege_authority; > sequence supported_naming_mechanisms; > }; > > Proposal 2: > > We specify a ServiceConfigurationSyntax tag for "none", and specify that > the sequence of octet associated with it is empty. > > // Corresponding ServiceName for the SCS_None Syntax should be an empty > // sequence octets. > const ServiceConfigurationSyntax SCS_None = -1; > > struct SAS_ContextSec{ > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; > ServiceConfiguration privilege_authority; > sequence supported_naming_mechanisms; > }; > > For efficiency I'm in favor of the second approach, because I can just > look a the ServiceConfiguration::syntax field and know what to do. The > first proposal causes me to look at the length first, index to the first > element in the array, and then look at the syntax field. The argument for changing target name to singular in a mechanism, is that a target which supports more than one target name, most likely does so because it supports more than 1 authentication mechanim. An alternate way to accomplish the same thing would simply be to add another mechanism definition to its mechanism list. If the issue Polar raises is a problem, and I can see how it could be, then I would suggest we restrict all the privilege authorities within a given mechanism definition to the same type. If we do this, then there is another possibility, which will preserve the ability to name multiple privilege authorities of the same syntax within a single mechanism. That is: struct SAS_ContextSec{ Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; ServiceSpecificName privilege_authority_syntax; sequence privilege_authorities; sequence supported_naming_mechanisms; }; We would discard the ServiceConfiguration type. The existing semantics of the length of the privilege_authorities sequence being used to detect if there are privilege authorities specified would be maintained. When the length of the sequnence is 0, the syntax value would be irrelevant. > > As an aside, I also wouldn't mind changing the > sequence > type into a Security::OIDList, but that can be the subject of > another > issue. Also note, to be specific with the document I am pointing to, > I > used the "Security" definitions. Hopefully, we will follow one > proposal to > change the Security::AssociationOptions to > CSIIOP::AssociationOptions and > Security::OID and Security::OIDList to CSI::OID and CSI::OIDList > respectively. > > Cheers, > -Polar > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Date: Thu, 11 Jan 2001 11:10:20 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo CC: Polar Humenn , csiv2-ftf@omg.org, issues@omg.org Subject: Re: Issue: Multiple Privilege Authorities and Supported Naming Types References: <3A5DD93A.7CF6F949@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: hR*e93@*!!iT;!!7*b!! Ron Monzillo wrote: > see the ----->, where I meant to write the following > That is: > > struct SAS_ContextSec{ > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; -----> ServiceSpecificSyntax > privilege_authority_syntax; > sequence > privilege_authorities; > sequence > supported_naming_mechanisms; > }; > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 11 Jan 2001 11:32:41 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org, issues@omg.org Subject: Re: Issue: Multiple Privilege Authorities and Supported Naming Types In-Reply-To: <3A5DD93A.7CF6F949@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: *6:!!%?Wd9[3N!!Tb8e9 Greetings, I am NOT in favor of Ron's approach on this issue. Comments below. -Polar On Thu, 11 Jan 2001, Ron Monzillo wrote: > > > Polar Humenn wrote: > > > > Issue > > > > Subject : Multiple Privilege Authorities and Supported Naming > Types > > > > Document: http://cgi.omg.org/pub/csiv2-ftf/draft-adopted-spec.pdf > > > > Summary: > > > > Multiple privilege authorities and multiple naming types yield > > combinatorial problems for the client. > > > > Discussion: > > > > This issue is sort of in the same regards to Issue 3973 where Ron > thinks > > that having multiple target_name(s) in the AS_ContextSec is a bad > idea, of > > which I agree. > > > > The type of the privilege_authorities field in the > CSIIOP::SAS_ContextSec > > structure sequence. It suffers the same > problem, > > especially when combined with multiple supported naming types. > > > > It is completely hard to determine having multiple privilege > authorities > > and the names that must be used to assert the identity for the > privileges. > > In fact, the client may get back an AuthorizationToken that he > doesn't > > understand, but will need to assert an identity for it's use, > quite > > possibly with endorsement. Having multiple naming types supported > per > > privilege authority is fine, but combine that with multiple ones, > and you > > may get a decision problem for the client. > > > > It is better to be able to specify a one-to-one correspondence, > locking > > down the combinations that a server will accept, and the client > doesn't > > have to do any mucking about deciding what will work. > > > > Proposed Solution: > > > > Singularize the privilege authorities field. > > > > Unfortunately IDL has a hard time making a singular field become > optional > > without doing something bizzare, such as: > > switch(boolean) { > > true: ServiceConfiguration privilege_authority > > } > > which requires a new type, etc. > > > > I have two proposals: > > > > Proposal 1: > > > > We signularize the field in name, i.e. > "privilege_authority". Keep the > > sequence definition. However, stating in the specification at most > one > > must be contained. This can be hinted at as well in IDL. > > > > struct SAS_ContextSec{ > > Security::AssociationOptions target_supports; > > Security::AssociationOptions target_requires; > > sequence privilege_authority; > > sequence supported_naming_mechanisms; > > }; > > > > Proposal 2: > > > > We specify a ServiceConfigurationSyntax tag for "none", and > specify that > > the sequence of octet associated with it is empty. > > > > // Corresponding ServiceName for the SCS_None Syntax should be an > empty > > // sequence octets. > > const ServiceConfigurationSyntax SCS_None = -1; > > > > struct SAS_ContextSec{ > > Security::AssociationOptions target_supports; > > Security::AssociationOptions target_requires; > > ServiceConfiguration privilege_authority; > > sequence supported_naming_mechanisms; > > }; > > > > For efficiency I'm in favor of the second approach, because I can > just > > look a the ServiceConfiguration::syntax field and know what to > do. The > > first proposal causes me to look at the length first, index to the > first > > element in the array, and then look at the syntax field. > > The argument for changing target name to singular in a mechanism, is > that a target which supports more than one target name, most likely > does > so because it supports more than 1 authentication mechanim. An > alternate > way to accomplish the same thing would simply be to add another > mechanism definition to its mechanism list. > > If the issue Polar raises is a problem, and I can see how it could > be, > then I would suggest we restrict all the privilege authorities > within a > given mechanism definition to the same type. If we do this, then > there > is another possibility, which will preserve the ability to name > multiple > privilege authorities of the same syntax within a single mechanism. > > That is: > > struct SAS_ContextSec{ > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; > ServiceSpecificName > privilege_authority_syntax; > sequence privilege_authorities; > sequence supported_naming_mechanisms; > }; > > We would discard the ServiceConfiguration type. The existing > semantics > of the length of the privilege_authorities sequence being used to > detect > if there are privilege authorities specified would be > maintained. When > the length of the sequnence is 0, the syntax value would be > irrelevant. That approach would imply that the ServiceConfiguration type has more semantics than originally intended, and semantics that are two complex to imply there. I.e. the same type of privilege authority doesn't imply that they have the same naming support. Of course, you can always claim that my comments are contrived, because a server an always be conservative about is mechanism definitions. But for INTEROPERABILITY clients MUST be liberal in what they understand and accept. And this approach of multiplicity for a single mechanism just really complicates matters beyond the task that is necessary. This is the same problem as having several targets in the AS_ContextSec. As Ron points out the solution is just to create a new CSI Mechanism in the list. I say the same consistent approach should be taken here. Singular is much easier to deal with, and you don't have to write alot of text explaining what has to happen. The definition pretty much speaks for itself. I don't know what having multiple privilege authorities in this structure by me except a huge headache in which one I have to choose, prefer, etc. I'd much rather do it with a signular approach. Cheers, -Polar > > As an aside, I also wouldn't mind changing the sequence > > type into a Security::OIDList, but that can be the subject of another > > issue. Also note, to be specific with the document I am pointing to, I > > used the "Security" definitions. Hopefully, we will follow one proposal to > > change the Security::AssociationOptions to CSIIOP::AssociationOptions and > > Security::OID and Security::OIDList to CSI::OID and CSI::OIDList > > respectively. > > > > Cheers, > > -Polar > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 17 Jan 2001 15:58:00 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Subject: Re: Issue: Multiple Privilege Authorities and Supported Naming Types Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: DGZ!!=J#e9$U#!!+4I!! In http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf the relevant (to our discussion) sections which describe the privilege_authorities field are found in paragraphs: [73],[145],[148],[173],[174],[177],[180] the privilege_authorities field of the SAS_ContextSec structure is currently defiend as follows: typedef const short ServiceConfigurationSyntax; const ServiceConfigurationSyntax SCS_GeneralNames = 0; const ServiceConfigurationSyntax SCS_GSSExportedName = 1; typedef sequence ServiceSpecificName; // The name field of the ServiceConfiguration structure identifies a privilege // authority in the format identified in the syntax field. If the syntax is // SCS_GeneralNames, the name field contains an ASN.1 (BER) SEQUENCE // [1..MAX] OF GeneralName, as defined by the type GeneralNames in // [IETF RFC 2459]. If the syntax is SCS_GSSExportedName, the name field // contains a GSS exported name encoded according to the rules in // [IETF RFC 2743] Section 3.2, "Mechanism-Independent Exported Name // Object Format," p. 84. struct ServiceConfiguration { ServiceConfigurationSyntax syntax; ServiceSpecificName name; }; sequence privilege_authorities; the privilege_authorities field can contain 0 or more privilege_authority "configurations" each potentially of different ServiceConfigurationSyntax. Each ServiceConfiguration indicates that the target "supports" authorization tokens of the designated syntax when acquired from the named trusted source. As stated in [177] a target is required to include in its IOR's the names of the privilege_authorities trusted by the target object. The privilege_authorities field (as currently defined) does not indicate that a client is required to provide one or more authorization tokens, nor does it restrict how many of the supported forms from trusted authorities could be included by a client. The issue raised was how does a CSS in its authorization acquistion logic interpret the multi-valued privilege_authorities field. As currently defined, there is no chance for a client to learn what it must do by looking at an IOR, as the IOR is not prescriptive of the client's behavior. The IOR tells the client what it can expect to be accepted by the target. The submission was written with the expectation that it was the client who decided when to acquire and send authorization tokens, how many, of which types, etc. This may be the subject of another issue, but it seems wise to come to a clearer picture of what is currently in the submission. Next - as defined, the privilege_authorities field allows a target to indicate that it supports requests which include multiple authorization tokens acquired from multiple authorities, and thus perhaps of different syntax. In [145], it states that the privilege authority names in the sequence of ServiceConfiguration elements which comprise the privilege_authorities field are arranged in decreasing order of target preference. This statement is the closest thing we provide to telling the client how to select from the multiple values in the privilge authority field (if the client decides to do so). Polar writes: > It is completely hard to determine having multiple privilege authorities > and the names that must be used to assert the identity for the privileges. > In fact, the client may get back an AuthorizationToken that he doesn't > understand, but will need to assert an identity for it's use, quite > possibly with endorsement. Having multiple naming types supported per > privilege authority is fine, but combine that with multiple ones, and you > may get a decision problem for the client. > I think Polar is saying that if the client is being told to acquire privileges form any of N possible authorities, then the name of the identity it must assert along with the acquired authorization token must be selected by the client to match the authorization token. I think he is saying that the dimension of multiple token formats is acceptable if there are not also multiple authorities for each form. Question: Why can't the token acquistion arguments, include in it the identity form that the client intends to use with the token (in its request to the target), such that a properly "bound" authorization token is returned? This is separate from understanding what multiple privilege authorities mean to the client (which we have not clearly defined). It might mean any of the following, and perhaps a few I haven't thought of. 1. get a token from all of them 2. get at most one from each of them 3. get at most one from one of them 4. get exactly one from one of them As the spec is currently written, I think the spec comes closest to expecting behavior 2 of its clients. perhaps what is being advocated is the removal of all such semantics from visibility in the CSIv2 spec, by hiding them in "privilege_authority" blobs (described elsewhere). Or perhaps we are assuming that the semantic we are after is 5. get exactly one using the specified mechanism Ron > It is better to be able to specify a one-to-one correspondence, locking > down the combinations that a server will accept, and the client doesn't > have to do any mucking about deciding what will work. > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 17 Jan 2001 17:24:30 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Re: Issue: Multiple Privilege Authorities and Supported Naming Types In-Reply-To: <3A660758.24531B92@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 3[*e9"5)e9ZK,!!63:e9 Along with all of this dicussion. The quesion I have to ask is: What exactly does a description of multiple privilege authorities actually buy you over just having one description? (other than complexity). Note, I don't buy arguments for fault tolerance or availablity. Those capabilities should be handled by the semantics of a singlar description, i.e. Fault Tolerant CORBA, DNS bind, WEB, some other protocol, whatever, that comprise the "logical authority". Complicating the Client Security Service to generalize fault tolerance, availability, preference, over a bunch of possibly known, unknown, supported, and unsupported privilege acquisition mechanisms is more than I care to bite off and chew. If there is a GIANT need for "multiple physical authorities", they should be pounded into a single description of a single "logical authority" (or service). Then, the exact semantics of how that space is searched, queried, and the method by which it operates in the face of faults or preference are explicitly relegated to a specification of the "logical authority" and not the Client Security Service specification and implementation. The implemenation of the Client Security Service becomes much simpler to implement and can be much more modular. I know that for a fact. I'm implementing the client side. That's why I raised the issue. -Polar On Wed, 17 Jan 2001, Ron Monzillo wrote: > In http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf > > the relevant (to our discussion) sections which describe the > privilege_authorities field are found in paragraphs: > > [73],[145],[148],[173],[174],[177],[180] > > the privilege_authorities field of the SAS_ContextSec structure > is currently defiend as follows: > > typedef const short ServiceConfigurationSyntax; > > const ServiceConfigurationSyntax SCS_GeneralNames = 0; > const ServiceConfigurationSyntax SCS_GSSExportedName = 1; > > typedef sequence ServiceSpecificName; > // The name field of the ServiceConfiguration structure identifies a > privilege > // authority in the format identified in the syntax field. If the > syntax > is > // SCS_GeneralNames, the name field contains an ASN.1 (BER) SEQUENCE > // [1..MAX] OF GeneralName, as defined by the type GeneralNames in > // [IETF RFC 2459]. If the syntax is SCS_GSSExportedName, the name > field > // contains a GSS exported name encoded according to the rules in > // [IETF RFC 2743] Section 3.2, "Mechanism-Independent Exported Name > // Object Format," p. 84. > > struct ServiceConfiguration { > ServiceConfigurationSyntax syntax; > ServiceSpecificName name; > }; > > sequence privilege_authorities; > > the privilege_authorities field can contain 0 or more > privilege_authority "configurations" each potentially of different > ServiceConfigurationSyntax. > Each ServiceConfiguration indicates that the target "supports" > authorization tokens of the designated syntax when acquired from > the named trusted source. > > As stated in [177] a target is required to include in its IOR's > the names of the privilege_authorities trusted by the target > object. > The privilege_authorities field (as currently defined) does not > indicate > that a client is required to provide one or more authorization > tokens, > nor does it restrict how many of the supported forms from trusted > authorities could be included by a client. > > The issue raised was how does a CSS in its authorization acquistion > logic > interpret the multi-valued privilege_authorities field. > > As currently defined, there is no chance for a client to learn what > it > must do by looking at an IOR, as the IOR is not prescriptive of the > client's behavior. The IOR tells the client what it can expect to be > accepted by the target. The submission was written with the > expectation > that it was the client who decided when to acquire and send > authorization tokens, how many, of which types, etc. This may be > the > subject of another issue, but it seems wise to come to a clearer > picture > of what is currently in the submission. > > Next - as defined, the privilege_authorities field allows a target > to > indicate that it supports requests which include multiple > authorization > tokens acquired from multiple authorities, and thus perhaps of > different > syntax. > > In [145], it states that the privilege authority names in the > sequence > of ServiceConfiguration elements which comprise the > privilege_authorities field are arranged in decreasing order of > target > preference. This statement is the closest thing we provide to > telling > the client how to select from the multiple values in the privilge > authority field (if the client decides to do so). > > Polar writes: > > It is completely hard to determine having multiple privilege > authorities > > and the names that must be used to assert the identity for the > privileges. > > In fact, the client may get back an AuthorizationToken that he > doesn't > > understand, but will need to assert an identity for it's use, > quite > > possibly with endorsement. Having multiple naming types supported > per > > privilege authority is fine, but combine that with multiple ones, > and you > > may get a decision problem for the client. > > > I think Polar is saying that if the client is being told to acquire > privileges form any of N possible authorities, then the name of the > identity it must assert along with the acquired authorization token > must be selected by the client to match the authorization token. I > think > he is saying that the dimension of multiple token formats is > acceptable > if there are not also multiple authorities for each form. > > Question: Why can't the token acquistion arguments, include in it > the > identity form that the client intends to use with the token (in its > request to the target), such that a properly "bound" authorization > token > is returned? > > This is separate from understanding what multiple privilege > authorities > mean to the client (which we have not clearly defined). It might > mean > any of the following, and perhaps a few I haven't thought of. > > 1. get a token from all of them > 2. get at most one from each of them > 3. get at most one from one of them > 4. get exactly one from one of them > > As the spec is currently written, I think the spec comes closest to > expecting behavior 2 of its clients. > > perhaps what is being advocated is the removal of all such semantics > from > visibility in the CSIv2 spec, by hiding them in > "privilege_authority" > blobs (described elsewhere). Or perhaps we are assuming that the > semantic > we are after is > > 5. get exactly one using the specified mechanism > > Ron > > > It is better to be able to specify a one-to-one correspondence, > locking > > down the combinations that a server will accept, and the client > doesn't > > have to do any mucking about deciding what will work. > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 18 Jan 2001 03:25:24 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Proprosed Vote Resolution Issue MPASNT Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-427817617-101357569-979806324=:5895" X-UIDL: &:\d9WZ2!!"ABe9l5F!! Attached is a proposed vote resolution for: Issue MPASNT: Multiple Privilege Authorities and Supported Naming Types Basically, elminates much of the complexity by making the privilege_authority field of the SAS_ContextSec singular. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com [] FTF-Issue-MPASNT.html From: "Don Flinn" To: "csiv2-ftf" Cc: "Bob Kukura" Subject: Issues 4200 & 4118 Date: Mon, 12 Mar 2001 12:12:04 -0500 Message-ID: <000001c0ab17$8f5fc670$7485413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: mE$e9G- addresses; }; In addition I feel that on the question of multiple privilege authorities, issue 4118, that there should be only one privilege authority. At present there are no implementations that use this field to find a privilege authority. Until we have some experience with using this functionality and understand how it will work in the real world I think that we should keep it simple and just allow one privilege authority name. Don ======================== Down the mid-tier Over the Firewall Nothing but Net ======================== Don Flinn Iona Technologies don.flinn@iona.com Tel: 781-902-8559 FAX: 781-902-8001 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 12 Mar 2001 13:50:35 -0500 (EST) From: Polar Humenn To: Don Flinn cc: csiv2-ftf , Bob Kukura Subject: Re: Issues 4200 & 4118 In-Reply-To: <000001c0ab17$8f5fc670$7485413f@boston.amer.iona.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: TUM!!3(Ie9e,$e9#!g!! On Mon, 12 Mar 2001, Don Flinn wrote: > I would like to propose the following for the SSLIOP module. The use of > multiple Address structures in the sequence addresses would be semantically > equivalent to using multiple mechanisms with one address in each, i.e. a > sequence containing one Address. > > const IOP::ComponentId TAG_SSL_SEC_TRANS = 21; // New tag number > > struct Address { > string host_name; > unsigned short port; > }; > > struct SSLSecTransComponent { > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; > sequence
addresses; > }; I still feel that the sequence is unecessary and forboding. However, by bringing multiple addresses up to this level, you are requiring the client security service to multiply the mechanism for each address? So my questions are: What if the length is zero? If length is more than one, is this short hand for multiplying the mechanism in the order of the target security service desired preference? If it is not that way, then that changes quite a bit. > In addition I feel that on the question of multiple privilege authorities, > issue 4118, that there should be only one privilege authority. At present > there are no implementations that use this field to find a privilege > authority. Until we have some experience with using this functionality and > understand how it will work in the real world I think that we should keep it > simple and just allow one privilege authority name. Well, I wouldn't say because we have no experience in this matter. :) It is quite evident in the past that I do not want the client's security service to become a privilege authority service negotiator or a fault management service for any type of privilege authority. The client should do it quickly, get in, get out, by whatever mechanism the service states. If if the privilege service fault tolerant, the ServiceConfiguration should say so. I can not see any notion of having multiple privilege authorities listed for a mechanism, without any semantics defined what it means. In that light, I say that we should deprecate ServiceConfiguationSyntax for GSS_ExportName and DN as well, as they have absolutely no meaning in the specification. Cheers, -Polar > Don > > ======================== > Down the mid-tier > Over the Firewall > Nothing but Net > ======================== > > Don Flinn > Iona Technologies > don.flinn@iona.com > Tel: 781-902-8559 > FAX: 781-902-8001 > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Mon, 12 Mar 2001 14:04:37 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Flinn CC: csiv2-ftf , Bob Kukura Subject: Re: Issues 4200 & 4118 References: <000001c0ab17$8f5fc670$7485413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _7$"!'k$!!CFa!!@JJe9 Don, We have agreed as part of the resolution of issue 4141/4142 to replace TAG_SSL_SEC_TRANS with TAG_TLS_SEC_TRANS = 36. Among other things this gives us the ability to modify the definition of this component to handle problems like that presented by issue 4200. A similar change will also be necessary to the SECIOP transport component. I'll have a modified document out either today, or tomorrow to help us keep track of what we've done so far. Linda passed Juergen the Published Spec last fri. and he will be giving us a pointer to it on the OMG site some time soon. I am merging the issue resolutions on top of that doc (which is csiv2-011701 + a title page inserted by Linda). Ron Don Flinn wrote: > > I would like to propose the following for the SSLIOP module. The use of > multiple Address structures in the sequence addresses would be semantically > equivalent to using multiple mechanisms with one address in each, i.e. a > sequence containing one Address. > > const IOP::ComponentId TAG_SSL_SEC_TRANS = 21; // New tag number > > struct Address { > string host_name; > unsigned short port; > }; > > struct SSLSecTransComponent { > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; > sequence
addresses; > }; > > In addition I feel that on the question of multiple privilege authorities, > issue 4118, that there should be only one privilege authority. At present > there are no implementations that use this field to find a privilege > authority. Until we have some experience with using this functionality and > understand how it will work in the real world I think that we should keep it > simple and just allow one privilege authority name. > > Don > > ======================== > Down the mid-tier > Over the Firewall > Nothing but Net > ======================== > > Don Flinn > Iona Technologies > don.flinn@iona.com > Tel: 781-902-8559 > FAX: 781-902-8001 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 14 Mar 2001 13:42:14 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Issue 4118 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: *P`!!W5ad9 X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Subject: Re: Issue 4118 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=koi8-r X-UIDL: *Hfd9R;,!!d''!!+;k!! I can't say that I agree with all Polar's points but I can see it clearly that there is no consensus in the FTF on this issue resolution. Therefore, I suggest that the FTF leaves this issue unresolved. Maybe it's not the best way to solve the issue generally but it looks to me as the most acceptable one today taking into account the lack of agreement. Konstantin Polar Humenn wrote: > Points I would like to make in favor of one privilege authority is client > code foot print, and future revisions of the CSIv2 specification. > > If there is only one privilege_authority in the security mechanism the > client looks at the Service Configuration Syntax tag specification and > decides whether it can deal with it. Perhaps the CSS has a module plug-in > for dealing with that type of privilege authority. IMHO, modularization is > a GOOD THING! > > Multiple privilege authorities are not as simple as Ron thinks. A couple > of weeks ago, he explained it as getting a AuthorizationToken from just > any one of them. Today, it was now getting an AuthorizationElement (not an > AuthorizationToken) from each of them. > > A type of a privilege authority "service" can be something specified in > the IOR to handle several things, whether that be CORBA, some IETF ASN.1 > protocol, or multiple "privilege authority" sources with semantics of > redundancy, additive, fail over, fault tolerant, default, etc). [my point > here is that the issue of multiple privilege authorities for a security > mechanism is not a simple one]. > > By putting multiple privilege authorities in the security mechanism you > are forcing the client to *always* have code to deal with multiple > privileges authorities, even though the client may ever only ever expect > to deal with just one authority. Multiple privilege authority > specification causes client code to be bloated with unnecessary > functionality. IMHO, this is a BAD thing!! > > By having a single privilege authority, the client need only include code > for the types of privilege authority services he expects. IMHO, this is a > GOOD thing! > > With multiple privilege authorities, if the functionality changes (i.e. > Ron didn't get it right the first time), then the entire CSIv2 > specification has to be revised! IMHO, this is a BAD thing! > > Subsequently, if the spec has to be revised then all the implementations of > a CSIv2 CSS out there have to be changed and probably remain backwards > compatible as well. IMHO, that is a BAD thing!! > > If the specification of the privilege authority is singular, then if you > want a specification for multiple privilege authorities, specify one with > a new RFP, with complete specification of the semantics of what needs to > be done on the client side. The CSIv2 specification DOES NOT have to be > touched! IMHO, this is a GOOD THING!! > > With the singular approach, if the functionality of privilege authority > service that contains multiple privileges authority sources needs to be > revised then, ONLY the document that specifies its functionality needs to > be revised, and the CSIv2 specification DOES NOT have to be touched! IMHO, > this is a GOOD THING. > > With the multiple privilege authority approach, the client code is going > to have to deal with *ALL* types of privilege authorities > (protocols,privilege semantics, etc.) in a general manner. I feel that > this cannot be done with out a lengthly specification, too long for this > document. IMHO, this is a BAD thing! > > Furthermore, I think that functionality goes beyond that of this FTF. This > is a BAD Thing! > > So, the bottom line is I came up with this score sheet: > > Singular Multiple > Reasons > > Good 4 0 > > Bad 0 5 > > I think that is enough to warrant changing the specification in this FTF > to a singluar privilege authority. > > Cheers, > -Polar > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 15 Mar 2001 10:21:45 -0500 (EST) From: Polar Humenn To: Konstantin Beznosov cc: csiv2-ftf@omg.org Subject: Re: Issue 4118 In-Reply-To: <3AB0D64F.44DBDE8@concept5.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: K"fd9SMj!!_ I can't say that I agree with all Polar's points but I can see it clearly that > there is no consensus in the FTF on this issue resolution. Therefore, I suggest > that the FTF leaves this issue unresolved. Maybe it's not the best way to solve > the issue generally but it looks to me as the most acceptable one today taking > into account the lack of agreement. Hmmm. What does this mean? First of all, it is an issue, and it cannot go "unresolved". All issues must be addressed. Second of all, it is pretty presumptous that you are sole judge whether there is consensus amongst all members of the FTF. What I would like to see is to have this FTF move faster than a slow boat to China. Let's put up resolutions and let the constituents vote, and let the powers that be veto if they wish. Jishnu has scheduled votes for the Core RTF without even knowing what the resolutions will be. That mandates progress. What do we do? We sit around pussy footing around talking over and under issues into cyber dust bin, just so we can yell at each other on the phone on the next wednesday without any results. That is, by god, if anybody even shows up to it. And then somehow we have to wait for everybody to "feel good" before a vote slips out onto the table. Since we been moving so slow to date, whether this is a intentional tactic or not, we are now relagated to poor and non-optimal solutions in the CSIv2 protocol and its implied implementations merely by the sole reason of being locked in my Sun's, and as far as I have heard, only Sun's implementation schedules and their threatening veto power. I'm not blaming Sun for having a weighty inflexible implemetation squad since they have to carry the EJB anchor, but if we move swiftly with mandated progress, we could have avoided this unfortunate situation. Let's get moving! -Polar > > Konstantin > > Polar Humenn wrote: > > > Points I would like to make in favor of one privilege authority is > client > > code foot print, and future revisions of the CSIv2 specification. > > > > If there is only one privilege_authority in the security mechanism > the > > client looks at the Service Configuration Syntax tag specification > and > > decides whether it can deal with it. Perhaps the CSS has a module > plug-in > > for dealing with that type of privilege authority. IMHO, > modularization is > > a GOOD THING! > > > > Multiple privilege authorities are not as simple as Ron thinks. A > couple > > of weeks ago, he explained it as getting a AuthorizationToken from > just > > any one of them. Today, it was now getting an AuthorizationElement > (not an > > AuthorizationToken) from each of them. > > > > A type of a privilege authority "service" can be something > specified in > > the IOR to handle several things, whether that be CORBA, some IETF > ASN.1 > > protocol, or multiple "privilege authority" sources with semantics > of > > redundancy, additive, fail over, fault tolerant, default, > etc). [my point > > here is that the issue of multiple privilege authorities for a > security > > mechanism is not a simple one]. > > > > By putting multiple privilege authorities in the security > mechanism you > > are forcing the client to *always* have code to deal with multiple > > privileges authorities, even though the client may ever only ever > expect > > to deal with just one authority. Multiple privilege authority > > specification causes client code to be bloated with unnecessary > > functionality. IMHO, this is a BAD thing!! > > > > By having a single privilege authority, the client need only > include code > > for the types of privilege authority services he expects. IMHO, > this is a > > GOOD thing! > > > > With multiple privilege authorities, if the functionality changes > (i.e. > > Ron didn't get it right the first time), then the entire CSIv2 > > specification has to be revised! IMHO, this is a BAD thing! > > > > Subsequently, if the spec has to be revised then all the > implementations of > > a CSIv2 CSS out there have to be changed and probably remain > backwards > > compatible as well. IMHO, that is a BAD thing!! > > > > If the specification of the privilege authority is singular, then > if you > > want a specification for multiple privilege authorities, specify > one with > > a new RFP, with complete specification of the semantics of what > needs to > > be done on the client side. The CSIv2 specification DOES NOT have > to be > > touched! IMHO, this is a GOOD THING!! > > > > With the singular approach, if the functionality of privilege > authority > > service that contains multiple privileges authority sources needs > to be > > revised then, ONLY the document that specifies its functionality > needs to > > be revised, and the CSIv2 specification DOES NOT have to be > touched! IMHO, > > this is a GOOD THING. > > > > With the multiple privilege authority approach, the client code is > going > > to have to deal with *ALL* types of privilege authorities > > (protocols,privilege semantics, etc.) in a general manner. I feel > that > > this cannot be done with out a lengthly specification, too long > for this > > document. IMHO, this is a BAD thing! > > > > Furthermore, I think that functionality goes beyond that of this > FTF. This > > is a BAD Thing! > > > > So, the bottom line is I came up with this score sheet: > > > > Singular Multiple > > Reasons > > > > Good 4 0 > > > > Bad 0 5 > > > > I think that is enough to warrant changing the specification in > this FTF > > to a singluar privilege authority. > > > > Cheers, > > -Polar > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Sender: Peter.Walker@Sun.COM Message-ID: <3AB0E35A.E4475838@eng.Sun.COM> Date: Thu, 15 Mar 2001 07:44:26 -0800 From: peter walker Organization: Sun Microsystems X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Konstantin Beznosov , csiv2-ftf@omg.org Subject: Re: Issue 4118 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3b7!!+)[!!jJ$!!B4Qe9 Polar Humenn wrote: Well, since we got a mention..... > > On Thu, 15 Mar 2001, Konstantin Beznosov wrote: > > > I can't say that I agree with all Polar's points but I can see it > clearly that > > there is no consensus in the FTF on this issue > resolution. Therefore, I suggest > > that the FTF leaves this issue unresolved. Maybe it's not the best > way to solve > > the issue generally but it looks to me as the most acceptable one > today taking > > into account the lack of agreement. > > Hmmm. What does this mean? > > First of all, it is an issue, and it cannot go "unresolved". The FTF can indeed decide to defer an issue. It can even advise that a particular issue is big enough to warrant a new RFP. > All issues > must be addressed. Second of all, it is pretty presumptous that you > are > sole judge whether there is consensus amongst all members of the > FTF. I believe each member is free to share their thoughts. I assumed that Konstantin was expressing his opinion. > > What I would like to see is to have this FTF move faster than a slow > boat > to China. Let's put up resolutions and let the constituents vote, > and let > the powers that be veto if they wish. Jishnu has scheduled votes for > the > Core RTF without even knowing what the resolutions will be. That > mandates progress. > > What do we do? We sit around pussy footing around talking over and > under > issues into cyber dust bin, just so we can yell at each other on the > phone > on the next wednesday without any results. That is, by god, if > anybody > even shows up to it. And then somehow we have to wait for everybody > to > "feel good" before a vote slips out onto the table. > > Since we been moving so slow to date, whether this is a intentional > tactic > or not, we are now relagated to poor and non-optimal solutions in > the > CSIv2 protocol and its implied implementations merely by the sole > reason > of being locked in my Sun's, and as far as I have heard, only Sun's > implementation schedules and their threatening veto power. Certainly we are not the only company implementing this spec. Yes there are some key aspects of the spec that we would not like to see become unstable in the FTF process. We are referencing the specification for J2EE and we believe we have a responsibility to the whole Enterprise Java community to ensure that the FTF completes its task in a timely manner. > > I'm not blaming Sun for having a weighty inflexible implemetation > squad > since they have to carry the EJB anchor, Please visit http://java.sun.com/j2ee/compatibility.html to see how many other companies also have "squads" who also believe that a timely resolution in the FTF is a good thing. Peter. -- ================================================================== Peter J. Walker Sun Microsystems, Inc. Manager, J2EE Architecture, Enterprise Java. Software Systems Group. Cupertino, CA. mailto:pwalker@eng.Sun.com http://java.sun.com/j2ee (408)517-5679 ================================================================== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 15 Mar 2001 10:58:20 -0500 (EST) From: Polar Humenn To: peter walker cc: Konstantin Beznosov , csiv2-ftf@omg.org Subject: Re: Issue 4118 In-Reply-To: <3AB0E35A.E4475838@eng.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: +7ed9%#C!!R9Td9?VYd9 On Thu, 15 Mar 2001, peter walker wrote: > Certainly we are not the only company implementing this spec. Yes there > are some key aspects of the spec that we would not like to see become > unstable in the FTF process. Please kindly specify exactly these key aspects that you want protected, so that we are not shooting in the dark. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 20 Mar 2001 14:42:19 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Issue 4118 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: N-+e9Sn&!!OO"!!m94!! Comments and suggestions on Sun's proposal for Issue 4118. You can obviously note that I do not agree with the proposed change, which is footnoting that at some later date this specification may address this issue. That is not a good answer, and it doesn't solve any problems. The goal for this FTF should be that specification not to have to change in the future. It should be of such quality, and well designed and written so that no change in the future is needed. A singular privilege_authority service specification will make chaning the specification at later date a moot point, and the solution will be quite modular, for all the reasons I mentioned in my letter last week. I'll repost it. I suggest that we take all proprosed resolutions to this issue and put it to a vote. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 20 Mar 2001 14:44:33 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Issue 4118 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 54C!!/Yg!!P,Le9mgC!! Repost: Points I would like to make in favor of one privilege authority is client code foot print, and future revisions of the CSIv2 specification. If there is only one privilege_authority in the security mechanism the client looks at the Service Configuration Syntax tag specification and decides whether it can deal with it. Perhaps the CSS has a module plug-in for dealing with that type of privilege authority. IMHO, modularization is a GOOD THING! Multiple privilege authorities are not as simple as Ron thinks. A couple of weeks ago, he explained it as getting a AuthorizationToken from just any one of them. Today, it was now getting an AuthorizationElement (not an AuthorizationToken) from each of them. A type of a privilege authority "service" can be something specified in the IOR to handle several things, whether that be CORBA, some IETF ASN.1 protocol, or multiple "privilege authority" sources with semantics of redundancy, additive, fail over, fault tolerant, default, etc). [my point here is that the issue of multiple privilege authorities for a security mechanism is not a simple one]. By putting multiple privilege authorities in the security mechanism you are forcing the client to *always* have code to deal with multiple privileges authorities, even though the client may ever only ever expect to deal with just one authority. Multiple privilege authority specification causes client code to be bloated with unnecessary functionality. IMHO, this is a BAD thing!! By having a single privilege authority, the client need only include code for the types of privilege authority services he expects. IMHO, this is a GOOD thing! With multiple privilege authorities, if the functionality changes (i.e. Ron didn't get it right the first time), then the entire CSIv2 specification has to be revised! IMHO, this is a BAD thing! Subsequently, if the spec has to be revised then all the implementations of a CSIv2 CSS out there have to be changed and probably remain backwards compatible as well. IMHO, that is a BAD thing!! If the specification of the privilege authority is singular, then if you want a specification for multiple privilege authorities, specify one with a new RFP, with complete specification of the semantics of what needs to be done on the client side. The CSIv2 specification DOES NOT have to be touched! IMHO, this is a GOOD THING!! With the singular approach, if the functionality of privilege authority service that contains multiple privileges authority sources needs to be revised then, ONLY the document that specifies its functionality needs to be revised, and the CSIv2 specification DOES NOT have to be touched! IMHO, this is a GOOD THING. With the multiple privilege authority approach, the client code is going to have to deal with *ALL* types of privilege authorities (protocols,privilege semantics, etc.) in a general manner. I feel that this cannot be done with out a lengthly specification, too long for this document. IMHO, this is a BAD thing! Furthermore, I think that functionality goes beyond that of this FTF. This is a BAD Thing! So, the bottom line is I came up with this score sheet: Singular Multiple Reasons Good 4 0 Bad 0 5 I think that is enough to warrant changing the specification in this FTF to a singluar privilege authority. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 3 Apr 2001 13:27:41 -0400 (EDT) From: Polar Humenn To: Don Flinn cc: csiv2-ftf Subject: Issue 4118: (was: Outstanding Issues) In-Reply-To: <001001c0bb2e$c6c98840$2302a8c0@boston.amer.iona.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: F$pd9P:3!!Q%~!!VjP!! Greetings, I'm just focusing on Issue 4118 here in Don's message. On Mon, 2 Apr 2001, Don Flinn wrote: > Hi All > > We have seven outstanding issues for the CSIv2 FTF. Of these Polar >and Ron > are in agreement on three and have a disagreement on four. > 4118 Multiple Privilege Authorities and Supported Naming Types > Disagreement: > Ron: Retain a sequence of Privilege Authorities and if more than one > Privilege is passed in the sequence all but the first in > undefined. The > syntax field is used to identify the form of the name. > Polar: Only allow one Privilege Authority. The semantics of > multiple > privilege authorities are not defined. > My reading of the issue: The client may have a decision problem if > it is > sent multiple privilege authorities. Don's reading of the issue is correct. The Client has no idea what to do with multiple privilege authorities, nor is there any attempt to define what it means, especially without getting into RFP territory. I don't want to see it go blatantly undefined, as that's not what the "Finalization" task force is about. Let's "finalize" this protocol. The really elegant solution to the problem is to make it one singular privilege "service". If there are actually multiple authorities within that service, then they should be defined within that "service" description, which describes the semantics of how to deal multiple privilege authorities. That can be the subject of an RFP down the line, once people get experience with the need for such things. Furthermore, on a new point, I would like to see the definition of a privilege service field, i.e. the "ServiceConfiguration" type, be changed to an IOP::TaggedComponent. If we take this approach, then when there are new IOP tags allocated for particular privilege services, they can be registered with the OMG in a common place with a pointer to the specification with the definition of the corresponding encoding. Right now, these ServiceConfigurationSyntax tags would have to be registered in other specs, which means that the tags could possibly end up all over the place, or that the CSIv2 spec needs to be revised, i.e. if an RFP explicitly has to register a new tag is CSIv2). I don't like that idea. It complicates specification management. Also, the OMG doesn't need another tag space to keep track of for extensible features. The IOP tag space is sufficient. Jishnu, is this an acceptable approach for registration of such things? So, how about it folks? Change the definition of privilege_authorities to a singular one, i.e. privilege_service, and change it's definition to an IOP::TaggedComponent. We can use the IOP::TAG_NULL_TAG for the absence of a privilege_service. Cheers, -Polar Reply-To: "David Chizmadia" From: "David Chizmadia" To: "csiv2-ftf" References: Subject: Re: Issue 4118: (was: Outstanding Issues) Date: Tue, 3 Apr 2001 14:07:57 -0400 Organization: Promia, Inc MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: X9bd9ENBe9p0S!!#m\!! I'd like to add at least one voice to Polar's that we SHOULD NOT adopt unspecified (or underspecified) functionality "just because". While promia is moving into a product space where protocol-level exploits are what will sell our product, I REALLY hate the idea of knowingly specifying an incomplete protocol. (I grew up in the assurance community and the first thing I learned is that assurance is screwed when your specification is imprecise!!) My concern is that the protocol could potentially be used in unusual and nasty ways when those unspecified "features" are used for proprietary extensions to a poorly implemented product and thereby become a path into that product. Since the product is poorly implemented because it HAD to get to market first, we can be sure that enough people will use it to make the inevitable exploits a serious security annoyance. Then again, if CSIv2 becomes the success that we all hope, remember that Microsoft might end up having to appear to support it. Any un(der)specified aspect of the protocol will represent a sublime opportunity for M$ to adopt and break the protocol. To recap, I agree with Polar that the protocol should only support a single Privilege Authority, which authority could allow runtime federation with other authorities "under-the-covers". On the issue of changing the "ServiceConfiguration" type, to an IOP::TaggedComponent to allow more modular management of its evolution, I agree with Polar - subject to the absence of a convincing argument that such an approach would impede interoperability in any way. -DMC David Chizmadia Senior Software Security Architect Promia, Inc dchizmadia@promia.com ----- Original Message ----- From: "Polar Humenn" To: "Don Flinn" Cc: "csiv2-ftf" Sent: Tuesday, April 03, 2001 1:27 PM Subject: Issue 4118: (was: Outstanding Issues) > > Greetings, > > I'm just focusing on Issue 4118 here in Don's message. > > On Mon, 2 Apr 2001, Don Flinn wrote: > > > Hi All > > > > We have seven outstanding issues for the CSIv2 FTF. Of these >Polar and Ron > > are in agreement on three and have a disagreement on four. > > > > > 4118 Multiple Privilege Authorities and Supported Naming Types > > Disagreement: > > Ron: Retain a sequence of Privilege Authorities and if more than >one > > Privilege is passed in the sequence all but the first in >undefined. The > > syntax field is used to identify the form of the name. > > Polar: Only allow one Privilege Authority. The semantics of >multiple > > privilege authorities are not defined. > > My reading of the issue: The client may have a decision problem if >it is > > sent multiple privilege authorities. > > Don's reading of the issue is correct. The Client has no idea what >to do > with multiple privilege authorities, nor is there any attempt to >define > what it means, especially without getting into RFP territory. > > I don't want to see it go blatantly undefined, as that's not what >the > "Finalization" task force is about. Let's "finalize" this protocol. > > The really elegant solution to the problem is to make it one >singular > privilege "service". If there are actually multiple authorities >within > that service, then they should be defined within that "service" > description, which describes the semantics of how to deal multiple > privilege authorities. That can be the subject of an RFP down the >line, > once people get experience with the need for such things. > > Furthermore, on a new point, I would like to see the definition of a > privilege service field, i.e. the "ServiceConfiguration" type, be >changed > to an IOP::TaggedComponent. > > If we take this approach, then when there are new IOP tags allocated >for > particular privilege services, they can be registered with the OMG >in a > common place with a pointer to the specification with the definition >of > the corresponding encoding. > > Right now, these ServiceConfigurationSyntax tags would have to be > registered in other specs, which means that the tags could possibly >end up > all over the place, or that the CSIv2 spec needs to be revised, >i.e. if an > RFP explicitly has to register a new tag is CSIv2). I don't like >that idea. > It complicates specification management. Also, the OMG doesn't need > another tag space to keep track of for extensible features. The IOP >tag > space is sufficient. > > Jishnu, is this an acceptable approach for registration of such >things? > > So, how about it folks? Change the definition of >privilege_authorities to a > singular one, i.e. privilege_service, and change it's definition to >an > IOP::TaggedComponent. We can use the IOP::TAG_NULL_TAG for the >absence of > a privilege_service. > > Cheers, > -Polar > > Date: Tue, 03 Apr 2001 14:34:28 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: Don Flinn , csiv2-ftf Subject: Re: Issue 4118: (was: Outstanding Issues) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: j?"!!`3Yd9Y1Le9MMF!! Polar Humenn wrote: > > Greetings, > > I'm just focusing on Issue 4118 here in Don's message. > > On Mon, 2 Apr 2001, Don Flinn wrote: > > > Hi All > > > > We have seven outstanding issues for the CSIv2 FTF. Of these Polar and Ron > > are in agreement on three and have a disagreement on four. > > > > > 4118 Multiple Privilege Authorities and Supported Naming Types > > Disagreement: > > Ron: Retain a sequence of Privilege Authorities and if more than one > > Privilege is passed in the sequence all but the first in undefined. The > > syntax field is used to identify the form of the name. > > Polar: Only allow one Privilege Authority. The semantics of multiple > > privilege authorities are not defined. > > My reading of the issue: The client may have a decision problem if it is > > sent multiple privilege authorities. > > Don's reading of the issue is correct. The Client has no idea what to do > with multiple privilege authorities, nor is there any attempt to define > what it means, especially without getting into RFP territory. > > I don't want to see it go blatantly undefined, as that's not what the > "Finalization" task force is about. Let's "finalize" this protocol. Actually, I don't take that extreme position. It is perfectly legitimate for an FTF to say that only this part of the behavior is defined (i.e. the first privilege authority part) and behavior when additional privilege authorities are found is that they are ignored, until additional standardization takes place to define specific behavior in that area. I tend to agree with Ron that we should avoid changing (relatively harmless) data structures at this point, and that leave open possibilities of further refinement of behavior in additional RFPs. > The really elegant solution to the problem is to make it one singular > privilege "service". If there are actually multiple authorities within > that service, then they should be defined within that "service" > description, which describes the semantics of how to deal multiple > privilege authorities. That can be the subject of an RFP down the line, > once people get experience with the need for such things. Perhaps. But this seems like designing additional features on the fly under the hood of the FTF to me. If said RFP is issued it can just as well use the existing structure and bestow additional meaning to the contents in a backward compatible manner. Also, if these sorts of changes create a jeopardy for the inclusion of this standard by reference in the J2EE specification, that would be entirely unacceptable as far as we are concerned. > Furthermore, on a new point, I would like to see the definition of a > privilege service field, i.e. the "ServiceConfiguration" type, be > changed > to an IOP::TaggedComponent. Seems like a rather significant change of dubious value to me. > If we take this approach, then when there are new IOP tags allocated for > particular privilege services, they can be registered with the OMG in a > common place with a pointer to the specification with the definition of > the corresponding encoding. So now we will land up with a slew of IOP Component Tags for instances of Privilege Services. Why is this better than just managing allocation of constants of type ServiceContextSyntax is not clear to me. Yeah they will need to be registered and maintained but so what? Yet another set of constants to register and maintain, but they are localized to the CSIv2 protocol usage, as opposed to modifying GIOP/IIOP, which in effect is what addition of new IOP component tags involves. > Right now, these ServiceConfigurationSyntax tags would have to be > registered in other specs, which means that the tags could possibly > end up > all over the place, or that the CSIv2 spec needs to be revised, > i.e. if an > RFP explicitly has to register a new tag is CSIv2). I don't like > that idea. But you like the idea that the Core GIOP/IIOP chapter would need to be revised instead. Hmmmm..... > It complicates specification management. Also, the OMG doesn't need > another tag space to keep track of for extensible features. The IOP > tag > space is sufficient. I don't agree that this would be an appropriate use of IOP Component Tags, even if it saves OMG some administrivia. CSIv2 related allocation of constant values are best kept localized to CSIv2, and not spread out into GIOP/IIOP specification, IMHO, thus saving the poor sod in embedded systems who happens to just use GIOP from having to aorry about additional standard IOP TAGs etc. > Jishnu, is this an acceptable approach for registration of such things? > > So, how about it folks? Change the definition of privilege_authorities to a > singular one, i.e. privilege_service, and change it's definition to an > IOP::TaggedComponent. We can use the IOP::TAG_NULL_TAG for the absence of > a privilege_service. Seems like a gratuitious change that does not particularly fix any problem that cannot be fixed less obtrusively in other ways, to me. We would tend to vote against these proposed changes.:-] OK, now I have put my chain mail on and will remain off line for the next four days.:-) Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 3 Apr 2001 15:47:05 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Don Flinn , csiv2-ftf Subject: Re: Issue 4118: (was: Outstanding Issues) In-Reply-To: <3ACA17B4.298D5362@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ki@!!gl_!!M;,e92NE!! Comments below. -Polar On Tue, 3 Apr 2001, Jishnu Mukerji wrote: > Polar Humenn wrote: > > > > Greetings, > > > > I'm just focusing on Issue 4118 here in Don's message. > > > > On Mon, 2 Apr 2001, Don Flinn wrote: > > > > > Hi All > > > > > > We have seven outstanding issues for the CSIv2 FTF. Of these Polar and Ron > > > are in agreement on three and have a disagreement on four. > > > > > > > > > 4118 Multiple Privilege Authorities and Supported Naming Types > > > Disagreement: > > > Ron: Retain a sequence of Privilege Authorities and if more than one > > > Privilege is passed in the sequence all but the first in undefined. The > > > syntax field is used to identify the form of the name. > > > Polar: Only allow one Privilege Authority. The semantics of multiple > > > privilege authorities are not defined. > > > My reading of the issue: The client may have a decision problem if it is > > > sent multiple privilege authorities. > > > > Don's reading of the issue is correct. The Client has no idea what to do > > with multiple privilege authorities, nor is there any attempt to define > > what it means, especially without getting into RFP territory. > > > > I don't want to see it go blatantly undefined, as that's not what the > > "Finalization" task force is about. Let's "finalize" this protocol. > > Actually, I don't take that extreme position. It is perfectly legitimate > for an FTF to say that only this part of the behavior is defined (i.e. > the first privilege authority part) and behavior when additional > privilege authorities are found is that they are ignored, until > additional standardization takes place to define specific behavior in > that area. I tend to agree with Ron that we should avoid changing > (relatively harmless) data structures at this point, and that leave open > possibilities of further refinement of behavior in additional RFPs. It may be perfectly legitimate for an FTF to do NOTHING, but I wouldn't say that position, in this case, serves any good technical merit, or progress toward issue resolution. I disagree that it is a "harmless" data structure. It does cause harm in its underspecification, and furthermore, I don't think that multiple "privilege authorities" is a factet that is going to be realized anytime soon. And if it does it will have a whole bunch of quilted patchwork restrictions, such as if you have P1,P2,P3, none of P can be of type T, with and if one P is of type S, then it takes precedence one over type V, and furthermore, if one of Type C is in there, then there cannot be any others, and you have to call type C over and over again until you get a response. Blech! Uggggghh! Garbage! Spec Pollution. > > The really elegant solution to the problem is to make it one singular > > privilege "service". If there are actually multiple authorities within > > that service, then they should be defined within that "service" > > description, which describes the semantics of how to deal multiple > > privilege authorities. That can be the subject of an RFP down the line, > > once people get experience with the need for such things. > > Perhaps. But this seems like designing additional features on the fly > under the hood of the FTF to me. There is nothing going on under the hood of this FTF! It is not designing "additional" features. There is nothing in the protocol supporting or defining the semantics for multiple privilege authorities. So, I'm just trying to call a SPADE a SPADE. The functionality isn't there so remove the potential of abuse and definite incompatibilities down the line, and give it a DEFINITE UNAMBIGOUS Semantics. > If said RFP is issued it can just as well use the existing structure > and bestow additional meaning to the contents in a backward > compatible > manner. That means the CSIv2 spec and semantics have to be revised needlessly, and possibly endlessly. And I SEVERELY doubt that you can provide backwards compatibility based on the "quilted patchwork" of restrictions that I presented above, which would arrise out of doing so. > Also, if these sorts of changes create a jeopardy for the inclusion of > this standard by reference in the J2EE specification, that would be > entirely unacceptable as far as we are concerned. I honestly do believe that there are people at Sun who do see technical merit in this solution. ;^} > > Furthermore, on a new point, I would like to see the definition of a > > privilege service field, i.e. the "ServiceConfiguration" type, be changed > > to an IOP::TaggedComponent. > > Seems like a rather significant change of dubious value to me. > > > If we take this approach, then when there are new IOP tags allocated for > > particular privilege services, they can be registered with the OMG in a > > common place with a pointer to the specification with the definition of > > the corresponding encoding. > > So now we will land up with a slew of IOP Component Tags for instances > of Privilege Services. Why is this better than just managing allocation > of constants of type ServiceContextSyntax is not clear to me. Yeah they > will need to be registered and maintained but so what? Yet another set > of constants to register and maintain, but they are localized to the > CSIv2 protocol usage, as opposed to modifying GIOP/IIOP, which in effect > is what addition of new IOP component tags involves. I was only asking your sage advice on whether it was a good approach or not, given the way things are currently managed. I surmise that you think it is not. So be it. I thought it simply would be simpler to have these tags residing in a strongly adopted, well known, and sacrosanct registry. Furthermore, I believe that CSIv2 is a part of the whole GIOP/IIOP story and in addition any new standard privilege services that are specified are a part of that version of IIOP. Wouldn't you agree? > > Right now, these ServiceConfigurationSyntax tags would have to be > > registered in other specs, which means that the tags could > > possibly end up > > all over the place, or that the CSIv2 spec needs to be revised, > > i.e. if an > > RFP explicitly has to register a new tag is CSIv2). I don't like > > that idea. > > But you like the idea that the Core GIOP/IIOP chapter would need to > > be > revised instead. Hmmmm..... Like I said, CSIv2 is a part of GIOP/IIOP. > > It complicates specification management. Also, the OMG doesn't need > > another tag space to keep track of for extensible features. The IOP tag > > space is sufficient. > > I don't agree that this would be an appropriate use of IOP Component > Tags, even if it saves OMG some administrivia. CSIv2 related allocation > of constant values are best kept localized to CSIv2, and not spread out > into GIOP/IIOP specification, IMHO, thus saving the poor sod in embedded > systems who happens to just use GIOP from having to aorry about > additional standard IOP TAGs etc. Well, what is he worrying about those tags when they do not apply to his application? If that is indeed the case, then he must still worry about TAG_SECIOP_INET_SEC_TRANS, TAG_GENERIC_SEC_MECH, TAG_ASSOCIATION_OPTIONS, TAG_SEC_NAME, TAG_SPKM_1_SEC_MECH, TAG_SPKM_2_SEC_MECH, TAG_KerberosV5_SEC_MECH, TAG_CSI_ECMA_Secret_SEC_MECH, TAG_CSI_ECMA_Hybrid_SEC_MECH, TAG_CSI_ECMA_Public_SEC_MECH, TAG_SSL_SEC_TRANS, TAG_TLS_SEC_TRANS, TAG_SECIOP_SEC_TRANS, TAG_NULL_TAG, TAG_CSI_SEC_MECH_LIST, of which the latter 4 are introduced by CSIv2. > > Jishnu, is this an acceptable approach for registration of such things? > > > > So, how about it folks? Change the definition of privilege_authorities to a > > singular one, i.e. privilege_service, and change it's definition to an > > IOP::TaggedComponent. We can use the IOP::TAG_NULL_TAG for the absence of > > a privilege_service. > > Seems like a gratuitious change that does not particularly fix any > problem that cannot be fixed less obtrusively in other ways, to me. > > We would tend to vote against these proposed changes.:-] > > OK, now I have put my chain mail on and will remain off line for the > next four days.:-) Have fun. Cheers, -Polar > Jishnu. > Date: Wed, 11 Apr 2001 17:20:09 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Subject: Proposed resolution to issue 4118: Multiple Privilege Authorities and Supported Naming Types Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: `~n!!T> X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Subject: Proposed resolution to issue 4118: Multiple Privilege Authorities and Supported Naming Types Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: `~n!!T> To: Ron Monzillo cc: Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authorities and Supported Naming Types In-Reply-To: <3AD4CA89.BA0FA9F8@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by emerald.omg.org id f3C0QTv09775 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-UIDL: (a6!!Q$Zd9>Tl!!6nB!! Hi, I do not agree with some of the text below. On Wed, 11 Apr 2001, Ron Monzillo wrote: > Issue 4118: Multiple Privilege Authorities and Supported Naming Types > > base document: > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > This issue argues that the specification of multiple privilege > authorities in a target IOR unnecessarily complicate> authorization token acquisition logic, especially as the semantics of > multiple privilege authorities are not completely defined. > > Proposed Resolution: > > [1] replace paragraph 148 with the following paragraph > > The privilege_authorities field contains a list of the names of 0 or > more privilege authorities. A non-empty list indicates that the target > supports authorization tokens provided by a CSS (in EstablishContext > messages) and containing AuthorizationElements from the authority named > by the first ServiceConfiguration element in the list. If the > privilege_authorities field contains more than one ServiceConfiguration > element, A CSS shall be conformant if it ignores all > ServiceConfiguration elements beyond the first. The syntax field within > the ServiceConfiguration element identifies the format used to represent > the authority. Two alternative formats are currently defined: an ASN.1 > encoding of the GeneralNames (as defined in [IETF RFC 2459]) which > identify a privilege authority, or a GSS exported name (as defined in > [IETF RFC 2743] Section 3.2) encoding of the name of a privilege > authority. Why don't I take a crack at it? My main beef with this is talking about conformance of CSSs in this part of the spec. Let's talk about the protocol. The privilege_authorities field contains a sequence of at most one ServiceConfiguration. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. The syntax field .... There really isn't any need to say anything else. Proprietary extensions are proprietary extensions, so what? So, if we are going to go this way, I see no reason to call out anything beyond "contains at most one" element. In fact, if you were to call out anything at all, then I suggest this: "If the CSS encounters a security mechanism with more than one ServiceConfiguration in the privilege_authorities field, the security mechanism shall be ignored as if it did not exist." But I don't even think that really needs to be called out, does it? I guess I am not in favor of this "ignoring all but the first one" approach, because you are giving semantic meaning to multiple privilege authorities, saying that the first one is special and *will* get you anything you need. Keeping backwards compatibility for all future revs of the specification reduces to always keeping a "singular" privilege authority around and in the first position. This of course reduces to, guess what? Cheers, -Polar > ------End of proposed resolution------- > A subordinate issue was also raised; that being how to partition the > namespace of ServiceConfiguration syntax identifiers to support the > definition of vendor specific syntaxes. I created a new issue for this, > as > I do not know how this is done in Corba. I know some structure is > imposed on the collection of bits of the integer, such that some bits > efectively identifier a vendor, and others identify a syntax of the > vendor, but I do not know the details. So, I chose to create a separate > issue (hopefully to be resolved by someone more knowlegeable of these > details). > s the client Date: Fri, 13 Apr 2001 11:49:26 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: Ron Monzillo , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id f3DFj7r17182 Content-Type: text/plain; charset=iso-8859-1 X-UIDL: =+ > Hi, > > I do not agree with some of the text below. > > On Wed, 11 Apr 2001, Ron Monzillo wrote: > > > Issue 4118: Multiple Privilege Authorities and Supported Naming Types > > > > base document: > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > This issue argues that the specification of multiple privilege > > authorities in a target IOR unnecessarily complicate> > authorization token acquisition logic, especially as the semantics of > > multiple privilege authorities are not completely defined. > > > > Proposed Resolution: > > > > [1] replace paragraph 148 with the following paragraph > > > > The privilege_authorities field contains a list of the names of 0 or > > more privilege authorities. A non-empty list indicates that the target > > supports authorization tokens provided by a CSS (in EstablishContext > > messages) and containing AuthorizationElements from the authority named > > by the first ServiceConfiguration element in the list. If the > > privilege_authorities field contains more than one ServiceConfiguration > > element, A CSS shall be conformant if it ignores all > > ServiceConfiguration elements beyond the first. The syntax field within > > the ServiceConfiguration element identifies the format used to represent > > the authority. Two alternative formats are currently defined: an ASN.1 > > encoding of the GeneralNames (as defined in [IETF RFC 2459]) which > > identify a privilege authority, or a GSS exported name (as defined in > > [IETF RFC 2743] Section 3.2) encoding of the name of a privilege > > authority. It seems to me that the proposal above pretty much captures what we agreed to in the meeting. I know Polar wants something else, as articulated in his comments, and to some extent in the meeting, but that is not what we agreed to in the meeting. > Why don't I take a crack at it? My main beef with this is talking about > conformance of CSSs in this part of the spec. Let's talk about the > protocol. What is wrong with stating precisely what a conformant implementation should do in the standard? I thought that is what the normative part of the specification was all about. Jishnu. s the client From: "David Chizmadia" To: References: <3AD72006.955066F2@hp.com> Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types Date: Fri, 13 Apr 2001 12:41:32 -0400 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 2hj!!~a7e99"Le9c,]d9 From: "Jishnu Mukerji" Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types > > > [1] replace paragraph 148 with the following paragraph > > > > > > The privilege_authorities field contains a list of the names of > > >0 or > > > more privilege authorities. A non-empty list indicates that the > > >target > > > supports authorization tokens provided by a CSS (in > > >EstablishContext > > > messages) and containing AuthorizationElements from the > > >authority named > > > by the first ServiceConfiguration element in the list. If the > > > privilege_authorities field contains more than one ServiceConfiguration > > > element, A CSS shall be conformant if it ignores all > > > ServiceConfiguration elements beyond the first. I would suggest that this last sentence be changed to read "A CSS shall process only the first ServiceConfiguration element in a non-empty privilege_authorities field." While it isn't as strong as raising an error, removing the conditional makes the spec slightly less ambiguous about the defined protocol processing. I, too, believe that any reference to "conformance" here is redundant, since conformance is just implementation of a defined set of "Shall"s. > > > The syntax field within > > > the ServiceConfiguration element identifies the format used to represent > > > the authority. Two alternative formats are currently defined: an > > > ASN.1 > > > encoding of the GeneralNames (as defined in [IETF RFC 2459]) > > > which > > > identify a privilege authority, or a GSS exported name (as > > > defined in > > > [IETF RFC 2743] Section 3.2) encoding of the name of a privilege > > > authority. > > It seems to me that the proposal above pretty much captures what we > agreed to in the meeting. I know Polar wants something else, as > articulated in his comments, and to some extent in the meeting, but > > > that > is not what we agreed to in the meeting. > > > Why don't I take a crack at it? My main beef with this is talking > > > about > > conformance of CSSs in this part of the spec. Let's talk about > > > the > > protocol. > > What is wrong with stating precisely what a conformant > > > implementation > should do in the standard? I thought that is what the normative part > > > of > the specification was all about. > > Jishnu. > Date: Fri, 13 Apr 2001 13:14:11 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: David Chizmadia Cc: csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types References: <3AD72006.955066F2@hp.com> <001c01c0c438$9ba0e740$a000a8c0@davidch> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: +WP!!g!?!!c"Yd9pF,e9 David Chizmadia wrote: > From: "Jishnu Mukerji" > Subject: Re: Proposed resolution to issue 4118: Multiple Privilege > Authoritiesand Supported Naming Types > > > > > [1] replace paragraph 148 with the following paragraph > > > > > > > > The privilege_authorities field contains a list of the names > of 0 or > > > > more privilege authorities. A non-empty list indicates that > the target > > > > supports authorization tokens provided by a CSS (in > EstablishContext > > > > messages) and containing AuthorizationElements from the > authority > named > > > > by the first ServiceConfiguration element in the list. If the > > > > privilege_authorities field contains more than one > ServiceConfiguration > > > > element, A CSS shall be conformant if it ignores all > > > > ServiceConfiguration elements beyond the first. > > I would suggest that this last sentence be changed to read "A CSS > shall > process only the first ServiceConfiguration element in a non-empty > privilege_authorities field." While it isn't as strong as raising > an error, > removing the conditional makes the spec slightly less ambiguous > about the > defined protocol processing. I, too, believe that any reference to > "conformance" here is redundant, since conformance is just > implementation of > a defined set of "Shall"s. I see the problem with the conditional that you mention. However, "shall process *only* the first element", could be interpreted to means that any CSS that happens to process the second element too for whatever reason is non-conformant. I got the impression that we were explicitly trying to leave the possibility of experimental implementations that use the second element etc. open, and not force implementations that do so to become non-conformant. That is why I though what was agreed to was something like: "A CSS shall process the first ServiceConfiguration element. Processing of any additional ServiceContext elements is not required." Additionally we could allow servers to choose to be stricter by saying that "A CSS may choose to reject a request that comes with multiple ServiceConfiguration elements, in which case they should document the fact that the implementation rejects requests that come with more than one ServiceConfiiguration element." Inclusion of this would allow the creation of OSSs that strictly do not accept additional ServiceConfiguration elements, while allowing for implementations that do. We could also add a clarifying footnote or some such, which says something like "For a CSS to meaningfully process any ServiceConfiguration elements other than the first, there must be an out of band agreement in place between the client OSS and the server OSS defining the semantics of such usage, since this standard does not ascribe any specific meaning to such usage. This option is included mostly to enable experimental use, without forcing such experimental implementations into becoming non-conformant." Does that cover all bases? I will be happy to propose a reworded resolution along these lines if the above covers all bases for everyone. Cheers, Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 13 Apr 2001 13:13:24 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Ron Monzillo , Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types In-Reply-To: <3AD72006.955066F2@hp.com> Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by emerald.omg.org id f3DHFPr18902 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-UIDL: ?3pd9Vi^d9C-e!!)gMd9 Jishnu, You have your own perception of what we agreed to on the phone, just as I am sure Ron, I, and anybody else on the phone that day does. So here's my perception: We agreed that we would keep the sequence and state that only the first one is *somewhat* paid attention to, *but* it wasn't clear after that what would be the constraints or behavior. I also heard directly from you on the phone that "we must make sure what we do tomorrow doesn't break what we do today." Maybe that *WASN'T* in the agreement? We agreed that we would come up with some wording and then it would be refined. I am powerless in this group, as are many of the others, to do anything at all. So all I can do is just to provide logical arguments about they way something is written and what it actually implies, and hopefully, it has some sane effect. Have a nice holiday if you do that sort of thing, -Polar On Fri, 13 Apr 2001, Jishnu Mukerji wrote: > Polar Humenn wrote: > > > > Hi, > > > > I do not agree with some of the text below. > > > > On Wed, 11 Apr 2001, Ron Monzillo wrote: > > > > > Issue 4118: Multiple Privilege Authorities and Supported Naming Types > > > > > > base document: > > > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > > > This issue argues that the specification of multiple privilege > > > authorities in a target IOR unnecessarily complicate> > > authorization token acquisition logic, especially as the semantics of > > > multiple privilege authorities are not completely defined. > > > > > > Proposed Resolution: > > > > > > [1] replace paragraph 148 with the following paragraph > > > > > > The privilege_authorities field contains a list of the names of 0 or > > > more privilege authorities. A non-empty list indicates that the target > > > supports authorization tokens provided by a CSS (in EstablishContext > > > messages) and containing AuthorizationElements from the authority named > > > by the first ServiceConfiguration element in the list. If the > > > privilege_authorities field contains more than one ServiceConfiguration > > > element, A CSS shall be conformant if it ignores all > > > ServiceConfiguration elements beyond the first. The syntax field within > > > the ServiceConfiguration element identifies the format used to represent > > > the authority. Two alternative formats are currently defined: an ASN.1 > > > encoding of the GeneralNames (as defined in [IETF RFC 2459]) which > > > identify a privilege authority, or a GSS exported name (as defined in > > > [IETF RFC 2743] Section 3.2) encoding of the name of a privilege > > > authority. > > It seems to me that the proposal above pretty much captures what we > agreed to in the meeting. I know Polar wants something else, as > articulated in his comments, and to some extent in the meeting, but that > is not what we agreed to in the meeting. > > > Why don't I take a crack at it? My main beef with this is talking about > > conformance of CSSs in this part of the spec. Let's talk about the > > protocol. > > What is wrong with stating precisely what a conformant implementation > should do in the standard? I thought that is what the normative part of > the specification was all about. > > Jishnu. > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 13 Apr 2001 13:39:46 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: David Chizmadia , Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types In-Reply-To: <3AD733E3.B27EB588@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: %>0!!l3:!!e[Sd9-'>!! On Fri, 13 Apr 2001, Jishnu Mukerji wrote: > > > David Chizmadia wrote: > > > From: "Jishnu Mukerji" > > Subject: Re: Proposed resolution to issue 4118: Multiple Privilege > > Authoritiesand Supported Naming Types > > > > > > > [1] replace paragraph 148 with the following paragraph > > > > > > > > > > The privilege_authorities field contains a list of the names >of 0 or > > > > > more privilege authorities. A non-empty list indicates that >the target > > > > > supports authorization tokens provided by a CSS (in >EstablishContext > > > > > messages) and containing AuthorizationElements from the >authority > > named > > > > > by the first ServiceConfiguration element in the list. If >the > > > > > privilege_authorities field contains more than one > > ServiceConfiguration > > > > > element, A CSS shall be conformant if it ignores all > > > > > ServiceConfiguration elements beyond the first. > > > > I would suggest that this last sentence be changed to read "A CSS >shall > > process only the first ServiceConfiguration element in a non-empty > > privilege_authorities field." While it isn't as strong as raising >an error, > > removing the conditional makes the spec slightly less ambiguous >about the > > defined protocol processing. I, too, believe that any reference >to > > "conformance" here is redundant, since conformance is just >implementation of > > a defined set of "Shall"s. > > I see the problem with the conditional that you mention. > > However, "shall process *only* the first element", could be >interpreted to means > that any CSS that happens to process the second element too for >whatever reason > is non-conformant. Non-conformance here isn't the issue. If the target produces more than one privilege authority, the client has no way of figuring out what do do with it, unless it has an extraordinary agreement with that server. Operating as such, doesn't make the implemenation of the CSS non-conformant. However, the mere fact that a conformant CSS is only required to process the first one, ignoring the subsequent ones, IMPLIES that in that a conformant TSS must produce a singular privilege authority in the first element to operate with all conformant CSSs (since they only support the first). This calls out some specific semantics about privilege authorities and multiples of them, namely the first one has to produce everything that any combinaation of the others may. I'm not so sure you want to be that restrictive explicitly or implicitly, eh? So, the basic upshot is that with "ignoring all but the first", every target must produce a singular privilege authority to get everything it needs, if it produces one or more at all. I'm not in favor of saying anything about what a "conforming CSS" will do. I am in favor of just stating the facts about the protocol. That's why I proposed the REALLY REALLY SIMPLE wording of: ---- The privilege_authorities field contains a sequence of at most one ServiceConfiguration. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. The syntax field .... ---- This leaves CSSs to do what ever they want with regard to multiple privilege authorities, because it is outside of the spec. It can ignore the security mechanism, or process the first one, or the second one, or whatever. And it allows targets to put multiples in there to interoperate with such clients. If it wants to interoperate with regular CSIv2 clients, it has to produce a security mechanism with one privilege authority in it. That is not to say it cannot produce other security mechanisms with multiples. And furthermore, it does nothing toward implying that the first privilege authority must be the be-all-end-all of privilege authorities for that security mechanism. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "David Chizmadia" From: "David Chizmadia" To: References: <3AD72006.955066F2@hp.com> <001c01c0c438$9ba0e740$a000a8c0@davidch> <3AD733E3.B27EB588@hp.com> Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types Date: Fri, 13 Apr 2001 13:49:50 -0400 Organization: Promia, Inc MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: O!d!!3XBe9:E\!!/\"e9 Jishnu Mukerji wrote: > > David Chizmadia wrote: > < Some text deleted...> > > I would suggest that this last sentence be changed to read "A CSS shall > > process only the first ServiceConfiguration element in a non-empty > > privilege_authorities field." While it isn't as strong as raising an error, > > removing the conditional makes the spec slightly less ambiguous about the > > defined protocol processing. I, too, believe that any reference to > > "conformance" here is redundant, since conformance is just implementation of > > a defined set of "Shall"s. > > I see the problem with the conditional that you mention. > > However, "shall process *only* the first element", could be interpreted to means > that any CSS that happens to process the second element too for whatever reason > is non-conformant. Exactly! From a protocol conformance perspective (which is fundamentally a marketing issue if the implementation is intelligently designed), this would be true. As I'll discuss below, experimental extensions aren't obligated to conform and therefore don't care. > I got the impression that we were explicitly trying to leave > the possibility of experimental implementations that use the second element etc. > open, and not force implementations that do so to become > non-conformant. That is > why I though what was agreed to was something like: "A CSS shall > process the > first ServiceConfiguration element. Processing of any additional ServiceContext > elements is not required." I'll admit that I was distracted during this part of the discussion, but even so, I consider that the interoperability that Polar is striving for is better served by a strict interpretation of "conformance." My view is that an experimental extensions OSS is indeed "non-conformant", but in practice - who cares! If it provides a switch to disable the experimental extensions, then there is at least one configuration of the product that is conformant and therefore the product can be advertised as "conformant." In truth, because the processing of additional ServiceConfiguration elements is a strict superset of conformant processing, either side of the OSS will still be interoperable with strictly conformant implementations. The reverse cannot be guaranteed unless some degree of intelligent thought actually went into the design of the extensions. > > Additionally we could allow servers to choose to be stricter by >saying that "A > CSS may choose to reject a request that comes with multiple ServiceConfiguration > elements, in which case they should document the fact that the implementation > rejects requests that come with more than one ServiceConfiiguration element." > Inclusion of this would allow the creation of OSSs that strictly do >not accept > additional ServiceConfiguration elements, while allowing for implementations > that do. > > We could also add a clarifying footnote or some such, which says >something like > "For a CSS to meaningfully process any ServiceConfiguration elements >other than > the first, there must be an out of band agreement in place between >the client > OSS and the server OSS defining the semantics of such usage, since >this standard > does not ascribe any specific meaning to such usage. This option is included > mostly to enable experimental use, without forcing such experimental > implementations into becoming non-conformant." > > Does that cover all bases? I will be happy to propose a reworded resolution > along these lines if the above covers all bases for everyone. I don't see any real need to state any of the caveats. The industry moves forward on the basis of customer demand. If there is money to be made, companies will do everything in the caveats whether we bless it or not. The goal of the standard is to promote interoperability by defining at least one set of message formats and protocol processing rules with enough precision to allow intelligent communication conforming to the principle of least surprise. I think that the relatively small change I suggested does that. > > Cheers, > > Jishnu. -DMC Date: Fri, 13 Apr 2001 14:00:25 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: Ron Monzillo , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: l@fd9Wg9e9-:9e9;*]!! Polar Humenn wrote: > Jishnu, > > You have your own perception of what we agreed to on the phone, just >as I > am sure Ron, I, and anybody else on the phone that day does. > > So here's my perception: > > We agreed that we would keep the sequence and state that only the >first > one is *somewhat* paid attention to, *but* it wasn't clear after >that what > would be the constraints or behavior. Polar, I missed the point that you were trying to make in your message. I got all wrapped around whether it was OK or not for the normative part of a spec to mention the word "conformant" in it.:-) Sorry about that. I agreed with David that there was a bit of ambiguity in the proposed text and have proposed much tighter text addressing it, building on the text change that David proposed. Let me know if that covers the bases that need covering to tighten things up. > I also heard directly from you on the phone that "we must make sure what > we do tomorrow doesn't break what we do today." Maybe that *WASN'T* in the > agreement? We agreed that we would come up with some wording and then it > would be refined. We are in the process of doing so as we speak/write/type whatever.:-) > I am powerless in this group, as are many of the others, to do anything at > all. So all I can do is just to provide logical arguments about they way > something is written and what it actually implies, and hopefully, it has > some sane effect. I am taking them quite seriously, as you will see in my response to David's message. He actually did a pretty good job of explaining where you were coming from I think. Again, I am sorry for having missed that. > Have a nice holiday if you do that sort of thing, > I do so only on holidays.:-) You see, today is not a holiday for us. So I shall start indulging in those activities a little after 5pm today.:-) Cheers, Jishnu. Date: Fri, 13 Apr 2001 14:14:31 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: David Chizmadia , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: FhY!!]8nd9$\)e9V;gd9 Polar Humenn wrote: > On Fri, 13 Apr 2001, Jishnu Mukerji wrote: > > > > > > > David Chizmadia wrote: > > > > > From: "Jishnu Mukerji" > > > Subject: Re: Proposed resolution to issue 4118: Multiple >Privilege > > > Authoritiesand Supported Naming Types > > > > > > > > > [1] replace paragraph 148 with the following paragraph > > > > > > > > > > > > The privilege_authorities field contains a list of the >names of 0 or > > > > > > more privilege authorities. A non-empty list indicates >that the target > > > > > > supports authorization tokens provided by a CSS (in >EstablishContext > > > > > > messages) and containing AuthorizationElements from the >authority > > > named > > > > > > by the first ServiceConfiguration element in the list. If >the > > > > > > privilege_authorities field contains more than one > > > ServiceConfiguration > > > > > > element, A CSS shall be conformant if it ignores all > > > > > > ServiceConfiguration elements beyond the first. > > > > > > I would suggest that this last sentence be changed to read "A >CSS shall > > > process only the first ServiceConfiguration element in a >non-empty > > > privilege_authorities field." While it isn't as strong as >raising an error, > > > removing the conditional makes the spec slightly less ambiguous >about the > > > defined protocol processing. I, too, believe that any reference >to > > > "conformance" here is redundant, since conformance is just >implementation of > > > a d