Issue 3906: CSIv2 Protocol (csiv2-ftf) Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: ssue on Document orbos/2000-08-04, CSIv2 Joint Submission: Document: orbos/2000-08-04 CSIv2 Joint Submmission Subject: Protocol and IOR incompatabilities for Identity Assertion Severity: Critical Summary: The CSIv2 protocol is too vague on acceptance of identity tokens. This yeilds an uneeded and unwarranted complexity in implemenations. Vague protocols are not a good idea. It limits interoperability. Discussion: In the IOR, the CSIv2 protocol states a list of OIDs signifying the acceptable forms of an IdentityToken delivered by the client. This list of acceptable name forms is stated only to apply to GSS_NT_ExportedName types. There are no OIDs signifying that an X.501 DN or X.509 Public Key Certificate are acceptable. It seems that the specification is written so that both X.501 DNs and X.509 Certificate chains are always acceptable. This requirement would cause all clients to send only X.501 DNs or X.509 Certificate Chains, regardless of the server listing its acceptable name types. Also, there is no indication of which of an X.501 DN or X.509 Public Key Certificate Chain is desirable. This is vague. It is completely unwarranted to tell all CSI mechanisms that they must support X.509 DNs or X.509 Certificate chains. These name forms may not be relevant to the mechanism at all. The mechanism may not support public key technology, have facility for verification of certificates, may not be able to parse X.501 DNs or X.509 Certificate Chains, and further more, but not least, the security mechanism may not know what to do with it. One example, might be an TCPIP CSI mechanism that only wants to accept Kerberos principal names, Unix user names, or NT user names. DNs or Certificate Chains are irrelevant. With that in mind, a client should not be allowed to send the server an X.509 certificate chain or an X.501 DN at it. Those name forms are not acceptable to the server. The easiest way around this problem is to allocated OIDs under the OMG OID that signify the acceptance of each of the X.509 DNs and X.509 Public Key Certificate chains. Servers that accept X.501 DNs and X.509 Public Key Certificate chains for identity assertion shall list the appropriate OIDs in the IOR. Resolution: Apply revised text and close issue Revised Text: Base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] Replace the paragraph 53, which starts with "A target that supports identity assertion shall ...", with the following: When a TSS rejects a request because it carries an identity token constructed using an identity type or naming mechanism that is not supported by the target, the TSS shall return a ContextError service context element containing major and minor status codes indicating the mechanism was invalid. [2] In the CSI Module page 16-61, change the last two of the IdentityTokenType constants, such that they are powers of 2, for use in a bitmap. Also, change its type definition to an unsigned long and add the comment as follows: typedef unsigned long IdentityTokenType; // Additional standard identity token types shall only be defined by the // OMG. All IdentityTokenType constants shall be a power of 2. const IdentityTokenType ITTAbsent = 0; const IdentityTokenType ITTAnonymous = 1; const IdentityTokenType ITTPrincipalName = 2; const IdentityTokenType ITTX509CertChain = 4; const IdentityTokenType ITTDistinguishedName = 8; [3] On page 16-46 and in the CSIIOP module IDL section on page 16-65, add a new field called "supported_identity_types" to the SAS_ContextSec structure, such that it is defined as follows: struct SAS_ContextSec{ AssociationOptions target_supports; AssociationOptions target_requires; sequence <ServiceConfiguration> privilege_authorities; CSI::OIDList supported_naming_mechanisms; CSI::IdentityTokenType supported_identity_types; }; [4] Replace para 149 with the following: (the section reference is actually a cross reference, in which case it may change in detail based on other changes to the document). The supported_naming_mechanisms field shall contain a list of 0 or more GSS mechanism OIDs. A TSS shall set the value of this field to contain the GSS mechanism OIDs for which the target supports identity assertions using an identity token of type ITTPrincipalName. The Identity token types are defined in Section 16.2.5, "Identity Token Format," on page 16-17. [5] Add the following new paragraphs after the new para 149: The value of the supported_identity_types field shall be the bitmapped representation of the set of identity token types for which the target supports. The target always supports ITTAbsent. The value in supported_identity_types shall be non-zero if and only if the IdentityAssertion bit is non-zero in target_supports. The bit corresponding to the ITTPrincipalName identity token type shall be non-zero in supported_identity_types if and only if the value in supported_naming_mechanisms contains at least one element. [6] In section 16.9.3 (the CSI module idl) add the IdentityExtension typedef and add a default selector to the IdentityTokenType union as follows: typedef sequence <octet> IdentityExtension; union IdentityToken switch ( IdentityTokenType ) { case ITTAbsent: boolean absent; case ITTAnonymous: boolean anonymous; case ITTPrincipalName: GSS_NT_ExportedName principal_name; case ITTX509CertChain: X509CertificateChain certificate_chain; case ITTDistinguishedName: X501DistinguishedName dn; default: IdentityExtension id; }; [7] after paragraph 50 add the following new paragraphs: In addition to the identity token types described in the following table, the IdentityTokenType as defined in Section 16.9.3, "Module CSI - Common Secure Interoperability," provides for the definition of additional CSIv2 identity token types through the default selector of the IdentityToken union type. Additional standard identity token types shall only be defined by the OMG. All IdentityTokenType constants shall be a power of 2. Actions taken: September 20, 2000: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 20 Sep 2000 18:26:58 -0400 (EDT) From: Polar Humenn To: issues@omg.org, secrev@omg.org, orbos@omg.org Subject: CSIv2 Protocol Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Lh1e9nfh!!fCc!!:/*!! Issue on Document orbos/2000-08-04, CSIv2 Joint Submission: Document: orbos/2000-08-04 CSIv2 Joint Submmission Subject: Protocol and IOR incompatabilities for Identity Assertion Severity: Critical Summary: The CSIv2 protocol is too vague on acceptance of identity tokens. This yeilds an uneeded and unwarranted complexity in implemenations. Vague protocols are not a good idea. It limits interoperability. Discussion: In the IOR, the CSIv2 protocol states a list of OIDs signifying the acceptable forms of an IdentityToken delivered by the client. This list of acceptable name forms is stated only to apply to GSS_NT_ExportedName types. There are no OIDs signifying that an X.501 DN or X.509 Public Key Certificate are acceptable. It seems that the specification is written so that both X.501 DNs and X.509 Certificate chains are always acceptable. This requirement would cause all clients to send only X.501 DNs or X.509 Certificate Chains, regardless of the server listing its acceptable name types. Also, there is no indication of which of an X.501 DN or X.509 Public Key Certificate Chain is desirable. This is vague. It is completely unwarranted to tell all CSI mechanisms that they must support X.509 DNs or X.509 Certificate chains. These name forms may not be relevant to the mechanism at all. The mechanism may not support public key technology, have facility for verification of certificates, may not be able to parse X.501 DNs or X.509 Certificate Chains, and further more, but not least, the security mechanism may not know what to do with it. One example, might be an TCPIP CSI mechanism that only wants to accept Kerberos principal names, Unix user names, or NT user names. DNs or Certificate Chains are irrelevant. With that in mind, a client should not be allowed to send the server an X.509 certificate chain or an X.501 DN at it. Those name forms are not acceptable to the server. The easiest way around this problem is to allocated OIDs under the OMG OID that signify the acceptance of each of the X.509 DNs and X.509 Public Key Certificate chains. Servers that accept X.501 DNs and X.509 Public Key Certificate chains for identity assertion shall list the appropriate OIDs in the IOR. ------------------------------------------------------------------- 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: Wed, 14 Feb 2001 18:59:08 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Re: Issue 3906 The Identity Token Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Pn0e93~c!!Kg`d97a\!! As far as using the GSS Exported Name , if we hold true to the notion that the OID in the Exported Name really names a security mechanism, then I think we are going to need "mechanisms" for each of Anonymous X.500 DN X.509 Certificate X.509 sequence of certificates (how ever that plays out). Then these mechanisms essentially become synonymous with nametypes. One can use the same OIDs for the mechanism and the "import_name" type. I cannot see this happening any other way, unless we get rid of using GSS exported name all together. (????) One approach that was discussed was creating a CORBA PKI "mechanism" OID and bundling the DN,Cert,and seq Certs in the GSS_ExportName blob. However that would hide each types availability in "supported_naming_types". I do not think we want to do that. Also, there is no proper way to discern either of the three without trying to parse them all and finding the successful one (this is how an ASN.1 CHOICE is decoded anyway, believe it or not). Even if we went that way, we still need an "anonymous mechanism OID" to cover the GSS_C_NT_ANONYMOUS_NAME name type! Alternatively, we could just go with name types, and use a structure similar to (*very* similar) to the GSS_NT_ExportedName encoding, and just call it something else, like TypedName. This is almost analogous to doing something like struct IdentityToken { CSI::OID name_type; sequence name_value; }; And create OIDs for DN, Cert, and seq Certs, but then this gets into the problem of specifying the name type of GSS_NT_ExportedName, which then hides the mechanisms supported! Arrrgggh! So, I think the only consistent and EASIEST way to go is to generate "mechanism" OIDS for Anonymous, DN, Cert, seq Cert, and generate corresponding nametype OIDs. This looks like it might work quite nicely, and with a somewhat added benefit. :) One can always "negotiate" an internal name to another mechanism by using Gss_canonocialize_name. For example, lets take THE Mechanism for dealing with DNs, GSS_DN_MechOID. The exported name for the DN mechanism is an ASN.1 encoded DN. Imported name types may contain string encoded DNs as well as ASN.1 encoded blobs, even ASN.1 encoded certificates! gss_name_t name; int ret, minor; ret = gss_import_name( &minor,"CN=Polar, O=Adiron",GSS_NT_StrinDN, &name); // The GSS spec says you should really do this after an import // before an export, anyway. gss_name_t new_name; ret = gss_canonicalize_name(&minor,name,GSS_DN_Mech,&new_name); gss_buffert_t exported_name; ret = gss_export_name(&minor,new_name,&exported_name); // exported name is defined by the DN mechanism to come out as // asn ASN.1 DN encoding of the string version of the DN. Let's say you might be able to import a PEM encoded certificate in your GSS implementation. ret = gss_import_name(&minor,pemCert,GSS_NT_PEM_CERT, &name); ret = gss_canonicalize_name(&minor,name,GSS_DN_Mech,&new_name); ret = gss_exported_name(&minor,new_name,&exported_name) // exported name is defined by the DN mechanism to come out as // the ASN.1 encoded subject Id of the certificate. It all gets quite hairy, but what isn't at this point? gss_canonicalize_name gets us out of most situations, should that case arise. Comments? 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: Wed, 21 Feb 2001 11:59:17 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Re: Issue 3906 The Identity Token (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: @NM!!jEX!!65Pd96DD!! Repost. ---------- Forwarded message ---------- Date: Wed, 14 Feb 2001 18:59:08 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Re: Issue 3906 The Identity Token As far as using the GSS Exported Name , if we hold true to the notion that the OID in the Exported Name really names a security mechanism, then I think we are going to need "mechanisms" for each of Anonymous X.500 DN X.509 Certificate X.509 sequence of certificates (how ever that plays out). Then these mechanisms essentially become synonymous with nametypes. One can use the same OIDs for the mechanism and the "import_name" type. I cannot see this happening any other way, unless we get rid of using GSS exported name all together. (????) One approach that was discussed was creating a CORBA PKI "mechanism" OID and bundling the DN,Cert,and seq Certs in the GSS_ExportName blob. However that would hide each types availability in "supported_naming_types". I do not think we want to do that. Also, there is no proper way to discern either of the three without trying to parse them all and finding the successful one (this is how an ASN.1 CHOICE is decoded anyway, believe it or not). Even if we went that way, we still need an "anonymous mechanism OID" to cover the GSS_C_NT_ANONYMOUS_NAME name type! Alternatively, we could just go with name types, and use a structure similar to (*very* similar) to the GSS_NT_ExportedName encoding, and just call it something else, like TypedName. This is almost analogous to doing something like struct IdentityToken { CSI::OID name_type; sequence name_value; }; And create OIDs for DN, Cert, and seq Certs, but then this gets into the problem of specifying the name type of GSS_NT_ExportedName, which then hides the mechanisms supported! Arrrgggh! So, I think the only consistent and EASIEST way to go is to generate "mechanism" OIDS for Anonymous, DN, Cert, seq Cert, and generate corresponding nametype OIDs. This looks like it might work quite nicely, and with a somewhat added benefit. :) One can always "negotiate" an internal name to another mechanism by using Gss_canonocialize_name. For example, lets take THE Mechanism for dealing with DNs, GSS_DN_MechOID. The exported name for the DN mechanism is an ASN.1 encoded DN. Imported name types may contain string encoded DNs as well as ASN.1 encoded blobs, even ASN.1 encoded certificates! gss_name_t name; int ret, minor; ret = gss_import_name( &minor,"CN=Polar, O=Adiron",GSS_NT_StrinDN, &name); // The GSS spec says you should really do this after an import // before an export, anyway. gss_name_t new_name; ret = gss_canonicalize_name(&minor,name,GSS_DN_Mech,&new_name); gss_buffert_t exported_name; ret = gss_export_name(&minor,new_name,&exported_name); // exported name is defined by the DN mechanism to come out as // asn ASN.1 DN encoding of the string version of the DN. Let's say you might be able to import a PEM encoded certificate in your GSS implementation. ret = gss_import_name(&minor,pemCert,GSS_NT_PEM_CERT, &name); ret = gss_canonicalize_name(&minor,name,GSS_DN_Mech,&new_name); ret = gss_exported_name(&minor,new_name,&exported_name) // exported name is defined by the DN mechanism to come out as // the ASN.1 encoded subject Id of the certificate. It all gets quite hairy, but what isn't at this point? gss_canonicalize_name gets us out of most situations, should that case arise. Comments? 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:28:00 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Issue 3906 In-Reply-To: <3AB78762.EF3972C0@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: lF1e9]eL!![`^d9*-/e9 Comments and suggestions on Sun's issue resolution document Isse 3906: I do not even agree with their interpretation that "One objective of this issue is to make it possible for a target to instruct its clients not to assert name forms perceived to be weak or ambiguous (i.e DN's)." The subject of the issue is for the target to instruct the client not to send it name forms it does not support for a particular security mechanism. Some name forms may not even make sense in certain security mechanisms. If I am operating in a complete Kerberos or Microsoft environment, don't send me a DN! Also, don't send me an X509CertChain, (I don't want to process it). Unfortunately, the way the specification is written, logically, a client can send a target an X509 DN or an X509 Certificate Chain (non-standard ASN.1 encoded) regardless of what the target actually supports. The "supported_naming_mechanisms" field is really completely useless. Having an error code come back stating that the name form is unacceptable is not a way to resolve this issue or even address it. The proposed error code should exist regardless of this issue. The way I see it, there are two ways to resolve this issue. 1. Create OID's for DN's and this X509CertificateChain thingy, and put them in the supported_naming_types), OR, 2. Remove supported_naming_types altogether, as it really does nothing. The first approach guarantees that the client can select the proper naming mechanism before the call is made, without negotiating a context error. In contrast, Sun's approach you send it the DN all the time. Then what happens when you get a context error? The information can be available from the get-go, I do not understand what the problem is. Sun's approach impacts the complexity of the client's implementation. Approach 2 is not much different than what we have now, as no client is really forced to even look at the field. I don't like that. However, looking for compromise, I think there is one other approach that might work: If the supported_naming_mechanisms field is filed in, that means that the other naming forms (DN,X509CertificateChain) are explicitly forbidden and declared NOT supported for that particular security mechanism. Then sending a DN or one of these X509CertificateChain thingys (can we get rid of this monstrosity?) results in the proposed context error. 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: Fri, 30 Mar 2001 18:16:11 -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: Proposed resolution to issue 3906 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: aX$e9$j:!!hJcd990=e9 Status: RO base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] add the following paragraph after para 53. Note that the spec already says in para 74, that an assertion that is rejected because trust was not established should be rejected with an indication that the evidence was invalid. When a TSS rejects a request because it carries an identity token constructed using an identity type or naming mechanism that is not supported by the target, the TSS shall return a ContextError service context element containing major and minor status codes indicating the mechanism was invalid. [2] In the CSI Module, change the last two of the IdentyTokenType constants, such that they are powers of 2, for use in a bitmap. const IdentityTokenType ITTAbsent = 0; const IdentityTokenType ITTAnonymous = 1; const IdentityTokenType ITTPrincipalName = 2; const IdentityTokenType ITTX509CertChain = 4; const IdentityTokenType ITTDistinguishedName = 8; [3] In the CSIIOP module, make the following changes to result in the addition of an new field called "supported_identity_types" in the SAS_ContextSec structure. const CSI::IdentityTokenType IdentityOptions; struct SAS_ContextSec{ AssociationOptions target_supports; AssociationOptions target_requires; sequence privilege_authorities; CSI::OIDList supported_naming_mechanisms; IdentityOptions supported_identity_types; }; [5] make the same changes as in [4] to the IDL that precedes paragraph 149 [4] modify para 149 as follows The supported_naming_mechanisms field shall contain a list of 0 or more GSS mechanism OIDs. A TSS shall set the value of this field to contain the GSS mechanism OIDs for which the target supports (that is, evaluates) identity assertions using an identity token of type ITTPrincipalName. The Identity token types are defined in Section 16.2.5 , on page 16-17. [5] add this new para after 149 The supported_identity_types field shall contain the bitmapped set of identity token types for which the target supports (that is evaluates) identity assertions at the mechanism. The meaning of a non-zero value in supported_identity_types is not defined if the IdentityAssertion bit is not set in target_supports. The meaning of the bit corresponding to the ITTPrincipalName identity token type being set in supported_identity_types is not defined if supported_naming_mechanisms does not contain at least one mechanism OID. The meaning of a non-empty supported_naming_mechanisms field is not defined if the bit corresponding to the ITTPrincipalName identity token type is not set in supported_identity_types. -----------end of proposal Yes there is some duplication of meaning between the IdentityAssertion bit being set in target_supports and a non-empty bitset in supported_identity_types. From: Ron Monzillo - JavaSoft Message-Id: <200103311102.GAA24118@jse.East.Sun.COM> Date: Sat, 31 Mar 2001 06:08:09 -0500 To: "Ron Monzillo" , Reply-To: Subject: Re: Proposed resolution to issue 3906 X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="ISO-8859-1" X-UIDL: CpQd9Q(gd96J-e9oUQ!! Status: RO I'm sending a revised proposal, because I mis-numbered some of the items in my last msg, and I was unhappy with what I proposed for what had been item 5, and is now item 6. The lines I changed are not preceded with a >. >base document: > >http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > >[1] add the following paragraph after para 53. Note that the spec >already says in para 74, that an assertion that is rejected because >trust was not >established should be rejected with an indication that the evidence >was >invalid. > >When a TSS rejects a request because it carries an identity token >constructed using an identity type or naming mechanism that is not >supported by the target, the TSS shall return a ContextError service >context element containing major and minor status codes indicating >the >mechanism was invalid. > >[2] In the CSI Module, change the last two of the IdentyTokenType >constants, such that they are powers of 2, for use in a bitmap. > > const IdentityTokenType ITTAbsent = 0; > const IdentityTokenType ITTAnonymous = 1; > const IdentityTokenType ITTPrincipalName = 2; > const IdentityTokenType ITTX509CertChain = 4; > const IdentityTokenType ITTDistinguishedName = 8; > >[3] In the CSIIOP module, make the following changes to result in the >addition of an new field called "supported_identity_types" in the >SAS_ContextSec structure. > >const CSI::IdentityTokenType IdentityOptions; > >struct SAS_ContextSec{ > AssociationOptions target_supports; > AssociationOptions target_requires; > sequence privilege_authorities; > CSI::OIDList supported_naming_mechanisms; > IdentityOptions supported_identity_types; >}; > [4] make the same changes as in [3] to the IDL that precedes >paragraph 149 > [5] modify para 149 as follows > >The supported_naming_mechanisms field shall contain a list of 0 or more >GSS mechanism OIDs. A TSS shall set the value of this field to contain >the GSS mechanism OIDs for which the target supports (that is, >evaluates) identity assertions using an identity token of type >ITTPrincipalName. The Identity token types are defined in Section >16.2.5 , on page 16-17. > [6] add the following new paragraphs after 149 > The value of the supported_identity_types field shall be the bitmapped representation of the set of identity token types for which the target supports (that is evaluates) identity assertions at the mechanism. The correspondence between identity token type and bit position shall be defined by the values of the identity token type constants defined in Section 16.9.3, "Module CSI - Common Secure Interoperability," on page 16-60. The value in supported_identity_types shall be consistent with the value of the IdentityAssertion bit in target_supports and the value in the supported_naming_mechanisms field. The value in supported_identity_types shall be non-zero if and only if the IdentityAssertion bit is set in target_supports. The bit corresponding to the ITTPrincipalName identity token type shall be set in supported_identity_types if and only if the value in supported_naming_mechanisms contains at least one mechanism OID. > >-----------end of proposal > >Yes there is some duplication of meaning between the IdentityAssertion >bit being set in target_supports and a non-empty bitset in >supported_identity_types. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 3 Apr 2001 09:56:14 -0400 (EDT) From: Polar Humenn To: Ron Monzillo - JavaSoft cc: Subject: Re: Proposed resolution to issue 3906 In-Reply-To: <200103311102.GAA24118@jse.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 f33DwDp15820 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-UIDL: 5*kd9]0W!!d[Zd92o+!! See comments interspersed below: On Sat, 31 Mar 2001, Ron Monzillo - JavaSoft wrote: > I'm sending a revised proposal, because I mis-numbered some of the > items in my last msg, and I was unhappy with what I proposed for > what had been item 5, and is now item 6. The lines I changed are > not preceded with a >. > > > >base document: > > > >http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > >[1] add the following paragraph after para 53. Note that the spec > >already says in para 74, that an assertion that is rejected because > >trust was not > >established should be rejected with an indication that the evidence > was > >invalid. > > > >When a TSS rejects a request because it carries an identity token > >constructed using an identity type or naming mechanism that is not > >supported by the target, the TSS shall return a ContextError > service > >context element containing major and minor status codes indicating > the > >mechanism was invalid. > > > >[2] In the CSI Module, change the last two of the IdentyTokenType > >constants, such that they are powers of 2, for use in a bitmap. > > > > const IdentityTokenType ITTAbsent = 0; > > const IdentityTokenType ITTAnonymous = 1; > > const IdentityTokenType ITTPrincipalName = 2; > > const IdentityTokenType ITTX509CertChain = 4; > > const IdentityTokenType ITTDistinguishedName = 8; > > > >[3] In the CSIIOP module, make the following changes to result in > the > >addition of an new field called "supported_identity_types" in the > >SAS_ContextSec structure. > > > >const CSI::IdentityTokenType IdentityOptions; > > > >struct SAS_ContextSec{ > > AssociationOptions target_supports; > > AssociationOptions target_requires; > > sequence privilege_authorities; > > CSI::OIDList supported_naming_mechanisms; > > IdentityOptions supported_identity_types; > >}; > > > [4] make the same changes as in [3] to the IDL that precedes > paragraph 149 > > > > [5] modify para 149 as follows > > > >The supported_naming_mechanisms field shall contain a list of 0 or > more > >GSS mechanism OIDs. A TSS shall set the value of this field to > contain > >the GSS mechanism OIDs for which the target supports (that is, > >evaluates) identity assertions using an identity token of type > >ITTPrincipalName. The Identity token types are defined in Section > >16.2.5 , on page 16-17. > > > [6] add the following new paragraphs after 149 > > > > The value of the supported_identity_types field shall be the > bitmapped > representation of the set of identity token types for which the > target > supports (that is evaluates) identity assertions at the > mechanism. The > correspondence between identity token type and bit position shall be > defined by the values of the identity token type constants defined > in > Section 16.9.3, "Module CSI - Common Secure Interoperability," on > page 16-60. > > The value in supported_identity_types shall be consistent with the > value > of the IdentityAssertion bit in target_supports and the value in the > supported_naming_mechanisms field. The value in > supported_identity_types > shall be non-zero if and only if the IdentityAssertion bit is set in > target_supports. This approach precludes the supported_identity_types with the Absent bit set, which absent must be "supported" if the IdentityAssertion bit is NOT set. > The bit corresponding to the ITTPrincipalName identity > token type shall be set in supported_identity_types if and only if > the > value in supported_naming_mechanisms contains at least one mechanism > OID. > > > > > >-----------end of proposal What worries me about this proposal is the proliferation of identity token types. There can be only 16 of them. One might think this is tantamount to the Internet Address problem, and therefore, nothing will have to be worried about until we are sitting in a Caribean retirement home sipping margerittas from our wheelchairs on the beach. No Problem. Let me say, that I am not totally against this approach, but I do have a few things to say about it. There are going to be XML based names shortly, where will these go? IdentityToken types, or creating an OID and a GSS nametype? Anyway, with this approach, since we have a union IdentityToken type, which is not extensible, the IdentityOptions are pretty much locked in to the above set without doing a major revision to the protocol and spec. Future revisions to the specification is REALLY something I am trying to avoid!!!!! I do not understand what is the problem with defining OIDs for a type, and a particular name encoding. Why all the spaghetti? GSS Exported Name oid: anonymous (there really is an OID for this) oid:1.2.840.113554.1.2.2 a Kerberos PrincipalName oid:2.23.130.1.1.1 a GSSUP Name oid:2.23.130.1.1.2 a sequence of X.509Certificates oid:2.23.130.1.1.3 a sequence of DNs Of course this approach obviates the need for the any of the branches in the Identity Token union type, i.e. the union alltogether. Either the IdentityToken is a sequence of octets that is a GSS ExportedName, or it is empty. REALLY SIMPLE. So granted, there may always be some amount of OIDs listed multiple times in an IOR, but is this really a big problem? With Sun's proposal, in order to support the conformance points, you still have to have ITTPrincipalName bit set in supporting_name_types and one OID in the supported_naming_types, which is the GSSUP naming format. Okay, so the approach I outlined above, you would have to include the 4 other OIDs. However, once nobody ever uses ASN.1 encoded sequences of certificates, and everybody finds out that a DN is pretty much useless without giving a directory URL, we will have to come up with other name forms. So this proposal doesn't buy all that much, other than a field that is always going to have the Absent,Anonymous,PrincipalName bits set. The fundamental thing here is that we want names to be extensible for future generations. And I rather to it in a consistent programatic manner that allows modularity. Hmm. if you are willing to go this far and change the IOR structure, you should be willing to change the SSL and SECIOP structures for multiple addresses, change the privileges authorities to singular, and quite possibly change the ServiceConfiguration to an IOP component (which I will talk about later). > >Yes there is some duplication of meaning between the IdentityAssertion > >bit being set in target_supports and a non-empty bitset in > >supported_identity_types. More than that, as I said before, they are in conflict, since you must always support "absent". Any other comments on how we should proceed on this issue? Cheers, -Polar Date: Tue, 03 Apr 2001 11:00:10 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Ron Monzillo - JavaSoft , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 3906 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \OLe9~_/!!NLid9Z`_d9 > Polar Humenn wrote: > > > The value in supported_identity_types shall be consistent with the value > > of the IdentityAssertion bit in target_supports and the value in the > > supported_naming_mechanisms field. The value in supported_identity_types > > shall be non-zero if and only if the IdentityAssertion bit is set in > > target_supports. > > This approach precludes the supported_identity_types with the Absent bit > set, which absent must be "supported" if the IdentityAssertion bit is NOT > set. > You may be saying this, but I can't parse what you wrote, so I'll explain why absent was not included as a supported identity type. The absent type is how you indicate that there is no identity assertion present. If we, as you suggest allow absent to appear in the bitmap, what should it mean when this bit is not set in supported identity types (and the IdentityAssertion bit is set in target_supports)? I think it would have to mean IdentityAssertion required, which would change the semantics of the protocol (that is, we do not allow a tagt to require identity assertion). That's why I decided not to indicate support for a non-existent identity assertion in supported_identity_types. > > The bit corresponding to the ITTPrincipalName identity > > token type shall be set in supported_identity_types if and only if > > the > > value in supported_naming_mechanisms contains at least one > > mechanism OID. > > > > > > > > > >-----------end of proposal > > > What worries me about this proposal is the proliferation of identity > > token > types. There can be only 16 of them. One might think this is > > tantamount to > the Internet Address problem, and therefore, nothing will have to be > worried about until we are sitting in a Caribean retirement home > > sipping > margerittas from our wheelchairs on the beach. No Problem. > > Let me say, that I am not totally against this approach, but I do > > have a > few things to say about it. glad to hear that. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 3 Apr 2001 13:05:16 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: Re: Proposed resolution to issue 3906 In-Reply-To: <3AC9E57A.ABAEAAE@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: FnT!!)C]d9+C[d9n1od9 On Tue, 3 Apr 2001, Ron Monzillo wrote: > > Polar Humenn wrote: > > > > > > The value in supported_identity_types shall be consistent with the value > > > of the IdentityAssertion bit in target_supports and the value in the > > > supported_naming_mechanisms field. The value in supported_identity_types > > > shall be non-zero if and only if the IdentityAssertion bit is set in > > > target_supports. > > > > This approach precludes the supported_identity_types with the Absent bit > > set, which absent must be "supported" if the IdentityAssertion bit is NOT > > set. > > > You may be saying this, but I can't parse what you wrote, so I'll > explain why absent was not included as a supported identity type. You DID NOT say "absent" was NOT included as a supported identity type. So, are you saying that the proposed ITTAbsent bit is a "don't care"? If so, then should be ITTAnonymous, as well? This approach is not thoroughly laid out. > The absent type is how you indicate that there is no identity > assertion present. If we, as you suggest allow absent to appear in > the > bitmap, what should it mean when this bit is not set in supported > identity types (and the IdentityAssertion bit is set in > target_supports)? I think it would have to mean IdentityAssertion > required, which would change the semantics of the protocol (that is, > we do not allow a tagt to require identity assertion). That's why I > decided not to indicate support for a non-existent identity > assertion > in supported_identity_types. > > > > The bit corresponding to the ITTPrincipalName identity > > > token type shall be set in supported_identity_types if and only > if the > > > value in supported_naming_mechanisms contains at least one > mechanism OID. > > > > > > > > > > > > > >-----------end of proposal > > > > > > What worries me about this proposal is the proliferation of > identity token > > types. There can be only 16 of them. One might think this is > tantamount to > > the Internet Address problem, and therefore, nothing will have to > be > > worried about until we are sitting in a Caribean retirement home > sipping > > margerittas from our wheelchairs on the beach. No Problem. > > > > Let me say, that I am not totally against this approach, but I do > have a > > few things to say about it. > > glad to hear that. NOT SO FAST whipper snapper! I didn't say I"m in agreement with the proposal. So be so kind as not to dismiss my points so blatantly. Please discuss them. > -Polar Date: Tue, 03 Apr 2001 14:48:40 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; 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 3906 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~,h!!*T=!!(h%!!!LCe9 Polar Humenn wrote: > > On Tue, 3 Apr 2001, Ron Monzillo wrote: > > > > Polar Humenn wrote: > > > > > > > > > The value in supported_identity_types shall be consistent with the value > > > > of the IdentityAssertion bit in target_supports and the value in the > > > > supported_naming_mechanisms field. The value in supported_identity_types > > > > shall be non-zero if and only if the IdentityAssertion bit is set in > > > > target_supports. > > > > > > This approach precludes the supported_identity_types with the Absent bit > > > set, which absent must be "supported" if the IdentityAssertion bit is NOT > > > set. > > > > > > You may be saying this, but I can't parse what you wrote, so I'll > > explain why absent was not included as a supported identity type. > > You DID NOT say "absent" was NOT included as a supported identity type. > So, are you saying that the proposed ITTAbsent bit is a "don't care"? > If so, then should be ITTAnonymous, as well? This approach is not > thoroughly laid out. The approach is consistent. A target that supports identity assertions must indicate whether or not it supports anonymous identity assertions. There is nothing more that needs to be said. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 3 Apr 2001 15:58:51 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: Re: Proposed resolution to issue 3906 In-Reply-To: <3ACA1B08.480E36E7@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: N&?!!Y98e9YX-!!VL1!! Comments below On Tue, 3 Apr 2001, Ron Monzillo wrote: > > > Polar Humenn wrote: > > > > On Tue, 3 Apr 2001, Ron Monzillo wrote: > > > > > > Polar Humenn wrote: > > > > > > > > > > > > The value in supported_identity_types shall be consistent >with the value > > > > > of the IdentityAssertion bit in target_supports and the >value in the > > > > > supported_naming_mechanisms field. The value in >supported_identity_types > > > > > shall be non-zero if and only if the IdentityAssertion bit >is set in > > > > > target_supports. > > > > > > > > This approach precludes the supported_identity_types with the >Absent bit > > > > set, which absent must be "supported" if the IdentityAssertion >bit is NOT > > > > set. > > > > > > > > > You may be saying this, but I can't parse what you wrote, so >I'll > > > explain why absent was not included as a supported identity >type. > > > > You DID NOT say "absent" was NOT included as a supported identity >type. > > So, are you saying that the proposed ITTAbsent bit is a "don't >care"? > > If so, then should be ITTAnonymous, as well? This approach is not > > thoroughly laid out. > > The approach is consistent. A target that supports identity >assertions > must indicate whether or not it supports anonymous identity >assertions. So, this is a NEW set of semantics then? Before you were always allowed to assert anonymous and absent. So, now you will only be able to assert anonymous and absent if the target says it's okay. Is that true? Or is it true that you will always be able to use "Absent" without worry, or looking at the "absent" bit? Any sage comments on the other points I brought up? I am still very worried about the extensibility of the Identity Token. Such as, how and where will these new XML name types be defined? We cannot extend the union and that means we will have to think up GSS exported name types for them anyway. So, the approach is almost the same as the one one I straw manned, and there isn't two levels of indirection in decoding the GSS nametypes. Cheers, -Polar > There is nothing more that needs to be said. Date: Wed, 11 Apr 2001 11:41:43 -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: some added thoughts on 3906 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: Y\!!!Ya,e9^))!!$@Ge9 Ron Monzillo wrote: > > Ron Monzillo - JavaSoft wrote: > > > > I'm sending a revised proposal, because I mis-numbered some of the > > items in my last msg, and I was unhappy with what I proposed for > > what had been item 5, and is now item 6. The lines I changed are > > not preceded with a >. > > > > >base document: > > > > > >http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > > >[1] add the following paragraph after para 53. Note that the spec > > >already says in para 74, that an assertion that is rejected because > > >trust was not > > >established should be rejected with an indication that the evidence was > > >invalid. > > > > > >When a TSS rejects a request because it carries an identity token > > >constructed using an identity type or naming mechanism that is not > > >supported by the target, the TSS shall return a ContextError service > > >context element containing major and minor status codes indicating the > > >mechanism was invalid. > > > > > >[2] In the CSI Module, change the last two of the IdentyTokenType > > >constants, such that they are powers of 2, for use in a bitmap. > > > > > > const IdentityTokenType ITTAbsent = 0; > > > const IdentityTokenType ITTAnonymous = 1; > > > const IdentityTokenType ITTPrincipalName = 2; > > > const IdentityTokenType ITTX509CertChain = 4; > > > const IdentityTokenType ITTDistinguishedName = 8; > > > > > > [3] In the CSIIOP module, make the following changes to result in the > > >addition of an new field called "supported_identity_types" in the > > >SAS_ContextSec structure. > > > > > typedef short IdentityOptions; > > > > > > >struct SAS_ContextSec{ > > > AssociationOptions target_supports; > > > AssociationOptions target_requires; > > > sequence privilege_authorities; > > > CSI::OIDList supported_naming_mechanisms; > > > IdentityOptions supported_identity_types; > > >}; > > > > > [4] make the same changes as in [3] to the IDL that precedes paragraph 149 > > > > > > > [5] modify para 149 as follows > > > > > >The supported_naming_mechanisms field shall contain a list of 0 or more > > >GSS mechanism OIDs. A TSS shall set the value of this field to contain > > >the GSS mechanism OIDs for which the target supports (that is, > > >evaluates) identity assertions using an identity token of type > > >ITTPrincipalName. The Identity token types are defined in Section > > >16.2.> > > > > [6] add the following new paragraphs after 149 > > > > > > > The value of the supported_identity_types field shall be the bitmapped > > representation of the set of identity token types for which the target > > supports (that is evaluates) identity assertions at the mechanism. The > > correspondence between identity token type and bit position shall be > > defined by the values of the identity token type constants defined in > > Section 16.9.3, "Module CSI - Common Secure Interoperability," on > > page 16-60. > > > > The value in supported_identity_types shall be consistent with the value > > of the IdentityAssertion bit in target_supports and the value in the > > supported_naming_mechanisms field. The value in supported_identity_types > > shall be non-zero if and only if the IdentityAssertion bit is set in > > target_supports. The bit corresponding to the ITTPrincipalName identity > > token type shall be set in supported_identity_types if and only if the > > value in supported_naming_mechanisms contains at least one mechanism OID. > > > > > > > [7] In section 16.9.3 (the CSI module idl) add a default selector to the > IdentityTokenType union as follows > > typedef sequence IdentityTypeExtension; > > union IdentityToken switch ( IdentityTokenType ) { > case ITTAbsent: boolean absent; > case ITTAnonymous: boolean anonymous; > case ITTPrincipalName: GSS_NT_ExportedName principal_name; > case ITTX509CertChain: X509CertificateChain certificate_chain; > case ITTDistinguishedName: X501DistinguishedName dn; > default: IdentityTypeExtension id; > }; > > [8] add a row to the IdentityTokenType table in section 16.2.5 to > describe the use of the default selector, and the algorithm for adding > additional identity token types to the standard. > > > >-----------end of proposal > > > > > >Yes there is some duplication of meaning between the IdentityAssertion > > >bit being set in target_supports and a non-empty bitset in > > >supported_identity_types. 5, Date: Tue, 17 Apr 2001 15:11:07 -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 3906 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: o?)!!"oTd9S"Ke9pET!! Note: In the proposed changes that follow, I have not added new types or made changes to existing structures as will be done to deal with the deprecation of the use of sequence within idl structs. I felt it best to deal with such changes separately, so as not to confuse what is being proposed to resolve this issue. ----- base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] add the following paragraph after para 53. Note that the spec already says in para 74, that an assertion that is rejected because trust was not established should be rejected with an indication that the evidence was invalid. When a TSS rejects a request because it carries an identity token constructed using an identity type or naming mechanism that is not supported by the target, the TSS shall return a ContextError service context element containing major and minor status codes indicating the mechanism was invalid. [2] In the CSI Module, change the last two of the IdentyTokenType constants, such that they are powers of 2, for use in a bitmap. const IdentityTokenType ITTAbsent = 0; const IdentityTokenType ITTAnonymous = 1; const IdentityTokenType ITTPrincipalName = 2; const IdentityTokenType ITTX509CertChain = 4; const IdentityTokenType ITTDistinguishedName = 8; [3] In the CSIIOP module, add a new field called "supported_identity_types" to the SAS_ContextSec structure, such that it is defined as follows: typedef short IdentityOptions; struct SAS_ContextSec{ AssociationOptions target_supports; AssociationOptions target_requires; sequence privilege_authorities; CSI::OIDList supported_naming_mechanisms; IdentityOptions supported_identity_types; }; [4] make the same changes as in [3] to the IDL that precedes paragraph 149 [5] modify para 149 as follows (the section reference is actually a cross reference, in which case it may change in detail based on other changes to the document). The supported_naming_mechanisms field shall contain a list of 0 or more GSS mechanism OIDs. A TSS shall set the value of this field to contain the GSS mechanism OIDs for which the target supports (that is, evaluates) identity assertions using an identity token of type ITTPrincipalName. The Identity token types are defined in Section 16.2. [6] add the following new paragraphs after 149. Same comment as in 5 applies to the section reference. The value of the supported_identity_types field shall be the bitmapped representation of the set of identity token types for which the target supports (that is evaluates) identity assertions at the mechanism. The correspondence between identity token type and bit value shall be defined by the values of the identity token type constants* defined in Section 16.9.3, "Module CSI - Common Secure Interoperability," on page 16-60. footnote * - Note that no bit value in supported_identity_types corresponds to the identity token type ITTAbsent. This must be the case to ensure that supported_identity_types cannot be used to indicate that a target requires IdentityAssertion (as a result of it not supporting ITTAbsent). The value in supported_identity_types shall be consistent with the value of the IdentityAssertion bit in target_supports and the value in the supported_naming_mechanisms field. The value in supported_identity_types shall be non-zero if and only if the IdentityAssertion bit is set in target_supports. The bit corresponding to the ITTPrincipalName identity token type shall be set in supported_identity_types if and only if the value in supported_naming_mechanisms contains at least one mechanism OID. [7] In section 16.9.3 (the CSI module idl) add a default selector to the IdentityTokenType union as follows typedef sequence IdentityTypeExtension; union IdentityToken switch ( IdentityTokenType ) { case ITTAbsent: boolean absent; case ITTAnonymous: boolean anonymous; case ITTPrincipalName: GSS_NT_ExportedName principal_name; case ITTX509CertChain: X509CertificateChain certificate_chain; case ITTDistinguishedName: X501DistinguishedName dn; default: IdentityTypeExtension extended_id; }; [8] after paragraph 50 add the following new paras. Same comment as in 5 applies to the section reference. In addition to the five identity token types described in the following table, the IdentityTokenType as defined in Section 16.9.3, "Module CSI - Common Secure Interoperability," provides for the definition of additional CSIv2 identity token types (through the default selector of the union). Additional identity token types may only be defined by the OMG. All IdentityTokenType constants must be a power of 2. The greatest power of 2 that may be assigned as the value of an IdentityTokenType constant is 2**15. [9] in section 16.9.3 (the CSI module idl) add the following comment above the definition of the first of the IdentityTokenType constants. // Additional identity token types may only be defined by the OMG. // All IdentityTokenType constants must be a power of 2. The // greatest power of 2 that may be assigned as the value of an // IdentityTokenType constant is 2**15. 5, X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 18 Apr 2001 11:31:57 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: Re: Proposed resolution to issue 3906 In-Reply-To: <3ADC954B.9E50DEC6@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 f3IFXvv10907 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-UIDL: G:R!!IYKd9mk7e9;]L!! On Tue, 17 Apr 2001, Ron Monzillo wrote: > Note: In the proposed changes that follow, I have not added new types or > made changes to existing structures as will be done to deal with the > deprecation of the use of sequence within idl structs. I felt it best to > deal with such changes separately, so as not to confuse what is being > proposed to resolve this issue. > > ----- > base document: > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > [1] add the following paragraph after para 53. Note that the spec > already says in para 74, that an assertion that is rejected because > trust was not established should be rejected with an indication that the > evidence was invalid. > > When a TSS rejects a request because it carries an identity token > constructed using an identity type or naming mechanism that is not > supported by the target, the TSS shall return a ContextError service > context element containing major and minor status codes indicating the > mechanism was invalid. Okay. > [2] In the CSI Module, change the last two of the IdentyTokenType > constants, such that they are powers of 2, for use in a bitmap. > > const IdentityTokenType ITTAbsent = 0; > const IdentityTokenType ITTAnonymous = 1; > const IdentityTokenType ITTPrincipalName = 2; > const IdentityTokenType ITTX509CertChain = 4; > const IdentityTokenType ITTDistinguishedName = 8; Okay. > [3] In the CSIIOP module, add a new field called > "supported_identity_types" to the SAS_ContextSec structure, such > that it > is defined as follows: > > typedef short IdentityOptions; > > struct SAS_ContextSec{ > AssociationOptions target_supports; > AssociationOptions target_requires; > sequence > privilege_authorities; > CSI::OIDList supported_naming_mechanisms; > IdentityOptions supported_identity_types; > }; Okay. > [4] make the same changes as in [3] to the IDL that precedes paragraph > 149 > > [5] modify para 149 as follows (the section reference is actually a > cross reference, in which case it may change in detail based on other > changes to the document). > > The supported_naming_mechanisms field shall contain a list of 0 or more > GSS mechanism OIDs. A TSS shall set the value of this field to contain > the GSS mechanism OIDs for which the target supports (that is, > evaluates) identity assertions using an identity token of type > ITTPrincipalName. The Identity token types are defined in Section > 16.2. Let's remove the "(that is, evaluates)" because I don't really know what that means. > [6] add the following new paragraphs after 149. Same comment as in 5 > applies to the section reference. > > The value of the supported_identity_types field shall be the > bitmapped > representation of the set of identity token types for which the > target > supports (that is evaluates) identity assertions at the > mechanism. The > correspondence between identity token type and bit value shall be > defined by the values of the identity token type constants* defined > in > Section 16.9.3, "Module CSI - Common Secure Interoperability," on > page 16-60. Again, remove "(that is evaluates)". Replace "at the mechanism" with "of the mechanism". > footnote * - Note that no bit value in supported_identity_types > corresponds to the identity token type ITTAbsent. This must be the > case > to ensure that supported_identity_types cannot be used to indicate > that > a target requires IdentityAssertion (as a result of it not > supporting > ITTAbsent). This footnote is really confusing. I don't see your point. Are you trying to say that it is impossible for the TSS to require Absent? Or are you trying to say that the the CSS can still deliver Absent even though the supported_identity_types has a bit set? > The value in supported_identity_types shall be consistent with the value > of the IdentityAssertion bit in target_supports and the value in the > supported_naming_mechanisms field. The value in supported_identity_types > shall be non-zero if and only if the IdentityAssertion bit is set in > target_supports. The bit corresponding to the ITTPrincipalName identity > token type shall be set in supported_identity_types if and only if the > value in supported_naming_mechanisms contains at least one mechanism > OID. Okay. > [7] In section 16.9.3 (the CSI module idl) add a default selector to the > IdentityTokenType union as follows > > typedef sequence IdentityTypeExtension; Why the naming convention switch? How about typedef sequence ITTExtension; > union IdentityToken switch ( IdentityTokenType ) { > case ITTAbsent: boolean absent; > case ITTAnonymous: boolean anonymous; > case ITTPrincipalName: GSS_NT_ExportedName principal_name; > case ITTX509CertChain: X509CertificateChain > certificate_chain; > case ITTDistinguishedName: X501DistinguishedName dn; > default: IdentityTypeExtension extended_id; > }; default: ITTExtension extended_id; > > [8] after paragraph 50 add the following new paras. Same comment as >in 5 > applies to the section reference. > > In addition to the five identity token types described in the >following > table, the IdentityTokenType as defined in Section 16.9.3, "Module >CSI - > Common Secure Interoperability," provides for the definition of > additional CSIv2 identity token types (through the default selector >of > the union). Additional identity token types may only be defined by >the > OMG. All IdentityTokenType constants must be a power of 2. The >greatest > power of 2 that may be assigned as the value of an IdentityTokenType > constant is 2**15. Change "Addition identity toke types ..." to "Aditional standard identity token types shall only be defined by the OMG." And why don't we go to an unsigned long, while were at it? > [9] in section 16.9.3 (the CSI module idl) add the following comment > above the definition of the first of the IdentityTokenType > constants. > > // Additional identity token types may only be defined by the OMG. > // All IdentityTokenType constants must be a power of 2. The > // greatest power of 2 that may be assigned as the value of an > // IdentityTokenType constant is 2**15. Same comments as above. 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 5, X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 18 Apr 2001 11:48:10 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: Re: Proposed resolution to issue 3906 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by emerald.omg.org id f3IFp6v11475 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-UIDL: ~Xf!!ES$!![4Xd9D=+!! Woops! It's a good thing these things come back to me so I can re-read them. I made a point about changing "IdentityTypeExtension" to "ITTExtension" because of the naming convention, because I wasn't looking at "default:" in the branch of the union. My mistake. I still don't like IdentityTypeExtension for a name. The type identifies the structure used in the union. This typedef is probably better off suited being called "IdentityExtension"? where as "default" is an IdentityTokenType, which although not possible, would be better called ITTExtension (I know that is not possible in IDL, but you get the idea of the argument). Cheers, -Polar On Wed, 18 Apr 2001, Polar Humenn wrote: > On Tue, 17 Apr 2001, Ron Monzillo wrote: > > > Note: In the proposed changes that follow, I have not added new >types or > > made changes to existing structures as will be done to deal with >the > > deprecation of the use of sequence within idl structs. I felt it >best to > > deal with such changes separately, so as not to confuse what is >being > > proposed to resolve this issue. > > > > ----- > > base document: > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > [1] add the following paragraph after para 53. Note that the spec > > already says in para 74, that an assertion that is rejected >because > > trust was not established should be rejected with an indication >that the > > evidence was invalid. > > > > When a TSS rejects a request because it carries an identity token > > constructed using an identity type or naming mechanism that is not > > supported by the target, the TSS shall return a ContextError >service > > context element containing major and minor status codes indicating >the > > mechanism was invalid. > > Okay. > > > [2] In the CSI Module, change the last two of the IdentyTokenType > > constants, such that they are powers of 2, for use in a bitmap. > > > > const IdentityTokenType ITTAbsent = 0; > > const IdentityTokenType ITTAnonymous = 1; > > const IdentityTokenType ITTPrincipalName = 2; > > const IdentityTokenType ITTX509CertChain = 4; > > const IdentityTokenType ITTDistinguishedName = 8; > > Okay. > > > [3] In the CSIIOP module, add a new field called > > "supported_identity_types" to the SAS_ContextSec structure, such >that it > > is defined as follows: > > > > typedef short IdentityOptions; > > > > struct SAS_ContextSec{ > > AssociationOptions target_supports; > > AssociationOptions target_requires; > > sequence >privilege_authorities; > > CSI::OIDList supported_naming_mechanisms; > > IdentityOptions supported_identity_types; > > }; > > Okay. > > > [4] make the same changes as in [3] to the IDL that precedes >paragraph > > 149 > > > > [5] modify para 149 as follows (the section reference is actually >a > > cross reference, in which case it may change in detail based on >other > > changes to the document). > > > > The supported_naming_mechanisms field shall contain a list of 0 or >more > > GSS mechanism OIDs. A TSS shall set the value of this field to >contain > > the GSS mechanism OIDs for which the target supports (that is, > > evaluates) identity assertions using an identity token of type > > ITTPrincipalName. The Identity token types are defined in Section > > 16.2. > > Let's remove the "(that is, evaluates)" because I don't really know >what > that means. > > > [6] add the following new paragraphs after 149. Same comment as in >5 > > applies to the section reference. > > > > The value of the supported_identity_types field shall be the >bitmapped > > representation of the set of identity token types for which the >target > > supports (that is evaluates) identity assertions at the >mechanism. The > > correspondence between identity token type and bit value shall be > > defined by the values of the identity token type constants* >defined in > > Section 16.9.3, "Module CSI - Common Secure Interoperability," on > > page 16-60. > > Again, remove "(that is evaluates)". > Replace "at the mechanism" with "of the mechanism". > > > footnote * - Note that no bit value in supported_identity_types > > corresponds to the identity token type ITTAbsent. This must be the >case > > to ensure that supported_identity_types cannot be used to indicate >that > > a target requires IdentityAssertion (as a result of it not >supporting > > ITTAbsent). > > This footnote is really confusing. I don't see your point. > Are you trying to say that it is impossible for the TSS to require >Absent? > Or are you trying to say that the the CSS can still deliver Absent >even > though the supported_identity_types has a bit set? > > > The value in supported_identity_types shall be consistent with the >value > > of the IdentityAssertion bit in target_supports and the value in >the > > supported_naming_mechanisms field. The value in >supported_identity_types > > shall be non-zero if and only if the IdentityAssertion bit is set >in > > target_supports. The bit corresponding to the ITTPrincipalName >identity > > token type shall be set in supported_identity_types if and only if >the > > value in supported_naming_mechanisms contains at least one >mechanism > > OID. > > Okay. > > > [7] In section 16.9.3 (the CSI module idl) add a default selector >to the > > IdentityTokenType union as follows > > > > typedef sequence IdentityTypeExtension; > > Why the naming convention switch? How about > > typedef sequence ITTExtension; > > > > > > union IdentityToken switch ( IdentityTokenType ) { > > case ITTAbsent: boolean absent; > > case ITTAnonymous: boolean anonymous; > > case ITTPrincipalName: GSS_NT_ExportedName principal_name; > > case ITTX509CertChain: X509CertificateChain >certificate_chain; > > case ITTDistinguishedName: X501DistinguishedName dn; > > default: IdentityTypeExtension extended_id; > > }; > > default: ITTExtension extended_id; > > > > > [8] after paragraph 50 add the following new paras. Same comment >as in 5 > > applies to the section reference. > > > > In addition to the five identity token types described in the >following > > table, the IdentityTokenType as defined in Section 16.9.3, "Module >CSI - > > Common Secure Interoperability," provides for the definition of > > additional CSIv2 identity token types (through the default >selector of > > the union). Additional identity token types may only be defined by >the > > OMG. All IdentityTokenType constants must be a power of 2. The >greatest > > power of 2 that may be assigned as the value of an >IdentityTokenType > > constant is 2**15. > > Change "Addition identity toke types ..." to > > "Aditional standard identity token types shall only be defined by >the > OMG." > > And why don't we go to an unsigned long, while were at it? > > > [9] in section 16.9.3 (the CSI module idl) add the following >comment > > above the definition of the first of the IdentityTokenType >constants. > > > > // Additional identity token types may only be defined by the OMG. > > // All IdentityTokenType constants must be a power of 2. The > > // greatest power of 2 that may be assigned as the value of an > > // IdentityTokenType constant is 2**15. > > Same comments as above. > > 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 5, Date: Tue, 24 Apr 2001 18:58:49 -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: Revised proposal for 3906 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: >_5e97&6e92&(!!J(g!! Based on Polar's Comments. > This footnote is really confusing. I don't see your point. > Are you trying to say that it is impossible for the TSS to require > > Absent? > Or are you trying to say that the the CSS can still deliver Absent > even > though the supported_identity_types has a bit set No (to the first question). The second question is approximately what I am saying, but not quite. I am saying that it was made impossible for a CSS to indicate that it does NOT support absent, because if it were possible, it would amount to a target being able to require an identity token (that is, an didentity assertion). > And why don't we go to an unsigned long, while were at it? OK but doing so will require us to also change the IdentityTokenType (which is also a short). We have had some trouble in our marshalling of typed union discrimnators, so I hope I don't regret agreeing to this. --------- base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] add the following paragraph after para 53. Note that the spec already says in para 74, that an assertion that is rejected because trust was not established should be rejected with an indication that the evidence was invalid. When a TSS rejects a request because it carries an identity token constructed using an identity type or naming mechanism that is not supported by the target, the TSS shall return a ContextError service context element containing major and minor status codes indicating the mechanism was invalid. [2] In the CSI Module, change the last two of the IdentyTokenType constants, such that they are powers of 2, for use in a bitmap. const IdentityTokenType ITTAbsent = 0; const IdentityTokenType ITTAnonymous = 1; const IdentityTokenType ITTPrincipalName = 2; const IdentityTokenType ITTX509CertChain = 4; const IdentityTokenType ITTDistinguishedName = 8; [3] In the CSIIOP module, add a new field called "supported_identity_types" to the SAS_ContextSec structure, such that it is defined as follows: typedef unsigned long IdentityOptions; struct SAS_ContextSec{ AssociationOptions target_supports; AssociationOptions target_requires; sequence privilege_authorities; CSI::OIDList supported_naming_mechanisms; IdentityOptions supported_identity_types; }; [4] make the same changes as in [3] to the IDL that precedes paragraph 149 [5] modify para 149 as follows (the section reference is actually a cross reference, in which case it may change in detail based on other changes to the document). The supported_naming_mechanisms field shall contain a list of 0 or more GSS mechanism OIDs. A TSS shall set the value of this field to contain the GSS mechanism OIDs for which the target supports identity assertions using an identity token of type ITTPrincipalName. The Identity token types are defined in Section 16.2. [6] add the following new paragraphs after 149. Same comment as in 5 applies to the section reference. The value of the supported_identity_types field shall be the bitmapped representation of the set of identity token types for which the target supports identity assertions of the mechanism. The correspondence between identity token type and bit value shall be defined by the values of the identity token type constants* defined in Section 16.9.3, "Module CSI - Common Secure Interoperability," on page 16-60. footnote * - Note that no bit value in supported_identity_types corresponds to the identity token type ITTAbsent. This must be the case to ensure that supported_identity_types cannot be used to indicate that a target requires IdentityAssertion (as a result of it not supporting ITTAbsent). The value in supported_identity_types shall be consistent with the value of the IdentityAssertion bit in target_supports and the value in the supported_naming_mechanisms field. The value in supported_identity_types shall be non-zero if and only if the IdentityAssertion bit is set in target_supports. The bit corresponding to the ITTPrincipalName identity token type shall be set in supported_identity_types if and only if the value in supported_naming_mechanisms contains at least one mechanism OID. [7] In section 16.9.3 (the CSI module idl) add a default selector to the IdentityTokenType union as follows typedef sequence IdentityExtension; union IdentityToken switch ( IdentityTokenType ) { case ITTAbsent: boolean absent; case ITTAnonymous: boolean anonymous; case ITTPrincipalName: GSS_NT_ExportedName principal_name; case ITTX509CertChain: X509CertificateChain certificate_chain; case ITTDistinguishedName: X501DistinguishedName dn; default: IdentityExtension extended_id; }; [8] after paragraph 50 add the following new paras. Same comment as in 5 applies to the section reference. In addition to the five identity token types described in the following table, the IdentityTokenType as defined in Section 16.9.3, "Module CSI - Common Secure Interoperability," provides for the definition of additional CSIv2 identity token types (through the default selector of the union). Aditional standard identity token types shall only be defined by the OMG. All IdentityTokenType constants must be a power of 2. The greatest power of 2 that may be assigned as the value of an IdentityTokenType constant is 2**31. [9] in section 16.9.3 (the CSI module idl) add the following comment above the definition of the first of the IdentityTokenType constants. // Aditional standard identity token types shall only be defined by the // OMG. All IdentityTokenType constants must be a power of 2. The // greatest power of 2 that may be assigned as the value of an // IdentityTokenType constant is 2**31. [10] in section 16.9.3 (the CSI module idl) change the definition of the IdentityTokenType to the following typedef unsigned long IdentityTokenType; From: "Don Flinn" To: "csiv2-ftf" Subject: Issues 3906 3907 4200 Date: Wed, 2 May 2001 14:37:16 -0400 Message-ID: <000d01c0d336$e9847280$7485413f@boston.amer.iona.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Type: multipart/mixed; boundary="----=_NextPart_000_000E_01C0D315.6272D280" X-UIDL: bPQe9%Pc!!Ep4!!nXY!! Attached is the proposal for issues 3906, 3907 and 4200. This is for comment at this time. I have tried to capture the final e-mail discussion and resolutions for these issues. If there are no further comments or discussion required then the resolutions of these issues, as written, will be put out for a vote. There is another issue raised by David Chang which has not yet an issue number. If David submits a resolution for his issue to the mailing list and that issue does not require further discussion and comment then his issue will also be included in Vote 5. All comments, corrections and suggestions cheerfully accepted. 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 [] csiv2_ftf_vote_5.htm 5, X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 3 May 2001 12:40:26 -0400 (EDT) From: Polar Humenn To: Don Flinn cc: csiv2-ftf Subject: Re: Issues 3906 3907 4200 In-Reply-To: <000d01c0d336$e9847280$7485413f@boston.amer.iona.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: P+id9@=b!!0D5!!:p"e9 Don, after a quick read, I still have problems with the wording on your version of 3906, especially the "constience" stuff and the footnote is confusing. It needs to be reworded. Unfortunately, I am traveling back to the US for the next few days. Let's work on 3906 a bit more before a vote. Thanks, -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 From: "Don Flinn" To: "Polar Humenn" Cc: "csiv2-ftf" Subject: RE: Issues 3906 3907 4200 Date: Thu, 3 May 2001 16:49:31 -0400 Message-ID: <001301c0d412$8d641460$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: pl^d9S$Me9=>id9R]ed9 Sounds good. We'll work on it when you get back. Don > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Thursday, May 03, 2001 12:40 PM > To: Don Flinn > Cc: csiv2-ftf > Subject: Re: Issues 3906 3907 4200 > > > > Don, > > after a quick read, I still have problems with the wording on your version > of 3906, especially the "constience" stuff and the footnote is confusing. > It needs to be reworded. Unfortunately, I am traveling back to the US > for the next few days. > > Let's work on 3906 a bit more before a vote. > > Thanks, > -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 > From: "Don Flinn" To: "csiv2-ftf" , "Polar Humenn" Subject: Issue 3906 Date: Mon, 14 May 2001 18:33:13 -0400 Message-ID: <002101c0dcc5$dce33640$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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: b%_!!1m@!!VK3e9)<`d9 Hi Polar I realize that you may still digging out from your e-mail after the Paris meeting. But,if you could get a few minutes to look at the proposed resolution to issue 3906, you said that you had some comments on the wording. Thanks 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: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from unknown (128.230.111.5) by hobbit.omg.org asmtp(1.0) id 4554; Tue, 15 May 2001 18:02:27 -0400 (EDT) Received: from localhost (polar@localhost) by marcy.adiron.com (8.10.2/8.10.2) with ESMTP id f4FLolw26433 for ; Tue, 15 May 2001 21:50:47 GMT X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 15 May 2001 17:50:47 -0400 (EDT) From: Polar Humenn To: Subject: Revised proposal for 3906 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: g:9e94$/e9N_De9_gDe9 This proposal is revised from Rons. Differences: 1. Fixed a couple of typeOs 2. Ron's proposal added [1] after para 53. I feel [1] should outright replace para 53. 3. Consolidated two changes for SAS_ContextSec into one and two changes for IdentityTokenTypes into one. 4. Just used CSI::IdentityTokenType for the supported_identity_types. It is more to the point. The fact that we call out that it's a bitmap only in supported_identity_types is fine. We don't need a new type and wording to explain the mapping. 5. Removed the footnote from the proposed paragraphs after para 149. 6. Reworded those paragraphs, by removing a note about "consistency" between IdentityAssertion in target_supports, supported_identity_types, and supported_naming_mechanisms. I feel that just stating the requirements in the form of "shall" is sufficient, as the notion of "consistency" would need to be defined, and the requirements subsequently define it. Just makes the description a bit more concise and to the point without beating around the bush. 6. Changed the name of the default branch of IdentityToken type from "extended_id" to "id", as "extended" implied some notion of an extension to an identifier itself, as opposed to the format of the identity assertion. The term "id" should be sufficient. 7. Took out the comment about the greatest power of 2 that can be used is 2**31 as this requirement is self evident from the type. ------------------------------------ Resolution of 3906: base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] Replace the paragraph 53, which starts with "A target that supports identity assertion shall ...", with the following: When a TSS rejects a request because it carries an identity token constructed using an identity type or naming mechanism that is not supported by the target, the TSS shall return a ContextError service context element containing major and minor status codes indicating the mechanism was invalid. [2] In the CSI Module page 16-61, change the last two of the IdentityTokenType constants, such that they are powers of 2, for use in a bitmap. Also, change its type definition to an unsigned long and add the comment as follows: typedef unsigned long IdentityTokenType; // Additional standard identity token types shall only be defined by the // OMG. All IdentityTokenType constants shall be a power of 2. const IdentityTokenType ITTAbsent = 0; const IdentityTokenType ITTAnonymous = 1; const IdentityTokenType ITTPrincipalName = 2; const IdentityTokenType ITTX509CertChain = 4; const IdentityTokenType ITTDistinguishedName = 8; [3] On page 16-46 and in the CSIIOP module IDL section on page 16-65, add a new field called "supported_identity_types" to the SAS_ContextSec structure, such that it is defined as follows: struct SAS_ContextSec{ AssociationOptions target_supports; AssociationOptions target_requires; sequence privilege_authorities; CSI::OIDList supported_naming_mechanisms; CSI::IdentityTokenType supported_identity_types; }; [4] Replace para 149 with the following: (the section reference is actually a cross reference, in which case it may change in detail based on other changes to the document). The supported_naming_mechanisms field shall contain a list of 0 or more GSS mechanism OIDs. A TSS shall set the value of this field to contain the GSS mechanism OIDs for which the target supports identity assertions using an identity token of type ITTPrincipalName. The Identity token types are defined in Section 16.2.5, "Identity Token Format," on page 16-17. [5] Add the following new paragraphs after the new para 149: The value of the supported_identity_types field shall be the bitmapped representation of the set of identity token types for which the TSS supports. The TSS always supports ITTAbsent. The value in supported_identity_types shall be non-zero if and only if the IdentityAssertion bit is non-zero in target_supports. The bit corresponding to the ITTPrincipalName identity token type shall be non-zero in supported_identity_types if and only if the value in supported_naming_mechanisms contains at least one element. [6] In section 16.9.3 (the CSI module idl) add the IdentityExtension typedef and add a default selector to the IdentityTokenType union as follows: typedef sequence IdentityExtension; union IdentityToken switch ( IdentityTokenType ) { case ITTAbsent: boolean absent; case ITTAnonymous: boolean anonymous; case ITTPrincipalName: GSS_NT_ExportedName principal_name; case ITTX509CertChain: X509CertificateChain certificate_chain; case ITTDistinguishedName: X501DistinguishedName dn; default: IdentityExtension id; }; [7] after paragraph 50 add the following new paragraphs: In addition to the identity token types described in the following table, the IdentityTokenType as defined in Section 16.9.3, "Module CSI - Common Secure Interoperability," provides for the definition of additional CSIv2 identity token types through the default selector of the IdentityToken union type. Additional standard identity token types shall only be defined by the OMG. All IdentityTokenType constants shall be a power of 2. Date: Wed, 16 May 2001 10:12:20 -0400 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 Subject: Re: Revised proposal for 3906 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ]&Sd9L'Ud9hFY!!:eH!! I support the changes proposed by Polar, with one exception In [5] Polar proposed. The value of the supported_identity_types field shall be the bitmapped representation of the set of identity token types for which the TSS supports. The TSS always supports ITTAbsent. This should be changed both for editorial reasons, and because we are talking about targets not TSS's at this point. I suggest The value of the supported_identity_types field shall be the bitmapped representation of the set of identity token types supported by the target. A target always supports ITTAbsent. Polar Humenn wrote: > > This proposal is revised from Rons. > > Differences: > 1. Fixed a couple of typeOs > 2. Ron's proposal added [1] after para 53. I feel [1] should outright > replace para 53. > 3. Consolidated two changes for SAS_ContextSec into one and two > changes for IdentityTokenTypes into one. > 4. Just used CSI::IdentityTokenType for the supported_identity_types. > It is more to the point. The fact that we call out that it's a bitmap > only in supported_identity_types is fine. We don't need a new type > and wording to explain the mapping. > 5. Removed the footnote from the proposed paragraphs after para 149. > 6. Reworded those paragraphs, by removing a note about "consistency" between > IdentityAssertion in target_supports, supported_identity_types, and > supported_naming_mechanisms. I feel that just stating the requirements > in the form of "shall" is sufficient, as the notion of "consistency" > would need to be defined, and the requirements subsequently define it. > Just makes the description a bit more concise and to the point without > beating around the bush. > 6. Changed the name of the default branch of IdentityToken type from > "extended_id" to "id", as "extended" implied some notion of an > extension to an identifier itself, as opposed to the format of the > identity assertion. The term "id" should be sufficient. > 7. Took out the comment about the greatest power of 2 that can be used > is 2**31 as this requirement is self evident from the type. > > ------------------------------------ > Resolution of 3906: > > base document: > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > [1] Replace the paragraph 53, which starts with "A target that supports > identity assertion shall ...", with the following: > > When a TSS rejects a request because it carries an identity token > constructed using an identity type or naming mechanism that is not > supported by the target, the TSS shall return a ContextError service > context element containing major and minor status codes indicating the > mechanism was invalid. > > [2] In the CSI Module page 16-61, change the last two of the > IdentityTokenType constants, such that they are powers of 2, for use in a > bitmap. Also, change its type definition to an unsigned long and add > the comment as follows: > > typedef unsigned long IdentityTokenType; > > // Additional standard identity token types shall only be defined by the > // OMG. All IdentityTokenType constants shall be a power of 2. > > const IdentityTokenType ITTAbsent = 0; > const IdentityTokenType ITTAnonymous = 1; > const IdentityTokenType ITTPrincipalName = 2; > const IdentityTokenType ITTX509CertChain = 4; > const IdentityTokenType ITTDistinguishedName = 8; > > [3] On page 16-46 and in the CSIIOP module IDL section on page 16-65, add > a new field called "supported_identity_types" to the SAS_ContextSec > structure, such that it is defined as follows: > > struct SAS_ContextSec{ > AssociationOptions target_supports; > AssociationOptions target_requires; > sequence privilege_authorities; > CSI::OIDList supported_naming_mechanisms; > CSI::IdentityTokenType supported_identity_types; > }; > > [4] Replace para 149 with the following: (the section reference is > actually a cross reference, in which case it may change in detail based on > other changes to the document). > > The supported_naming_mechanisms field shall contain a list of 0 or more > GSS mechanism OIDs. A TSS shall set the value of this field to contain the > GSS mechanism OIDs for which the target supports identity assertions using > an identity token of type ITTPrincipalName. The Identity token types are > defined in Section 16.2.5, "Identity Token Format," on page 16-17. > > [5] Add the following new paragraphs after the new para 149: > > The value of the supported_identity_types field shall be the bitmapped > representation of the set of identity token types for which the TSS > supports. The TSS always supports ITTAbsent. > > The value in supported_identity_types shall be non-zero if and only if the > IdentityAssertion bit is non-zero in target_supports. The bit > corresponding to the ITTPrincipalName identity token type shall be > non-zero in supported_identity_types if and only if the value in > supported_naming_mechanisms contains at least one element. > > [6] In section 16.9.3 (the CSI module idl) add the IdentityExtension > typedef and add a default selector to the IdentityTokenType union as > follows: > > typedef sequence IdentityExtension; > > union IdentityToken switch ( IdentityTokenType ) { > case ITTAbsent: boolean absent; > case ITTAnonymous: boolean anonymous; > case ITTPrincipalName: GSS_NT_ExportedName principal_name; > case ITTX509CertChain: X509CertificateChain certificate_chain; > case ITTDistinguishedName: X501DistinguishedName dn; > default: IdentityExtension id; > }; > > [7] after paragraph 50 add the following new paragraphs: > > In addition to the identity token types described in the following table, > the IdentityTokenType as defined in Section 16.9.3, "Module CSI - Common > Secure Interoperability," provides for the definition of additional CSIv2 > identity token types through the default selector of the IdentityToken > union type. Additional standard identity token types shall only be > defined by the OMG. All IdentityTokenType constants shall be a power of 2. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 16 May 2001 10:34:17 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: Re: Revised proposal for 3906 In-Reply-To: <3B028AC4.1EC2CFCE@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Tl]d9V76!!m;X!!)Y]d9 Ron, I am puzzled by your remark, because I thought we worked this out a while ago. The "TSS" is the "target's security service", which governs all aspects of *THE* target's security protocol etc. The target (which is in fact the target object) really has no notion of what it supports securitywise (except at maybe at some high level). It is the security service that it employs that requires and supports things directly in the protocol. Let me conjecture that you are trying to restrict definition to the the "target" object as there may be other objects in the same ORB that do different things. That's okay, because we are talking about THE target's security service, not the ORB's security service, and not ALL targets' security service. Also, especially with access control, a TSS may certainly support a particular naming type, or absent, but the "target" may not not accept it. If the target doesn't support a particular naming type, or doesn't like absent, it may throw the same exception as the TSS, i.e. a CORBA::NO_PERMISSOIN only with different minor codes, one for a TSS unspupport (because of mechanism incompatibility), and a different code if a "target" just didn't like it. It effect the "target" doesn't support "absent" or a particular naming type, but it's (T)SS does. Cheers, -Polar On Wed, 16 May 2001, Ron Monzillo wrote: > I support the changes proposed by Polar, with one exception > > In [5] Polar proposed. > > The value of the supported_identity_types field shall be the >bitmapped > representation of the set of identity token types for which the TSS > supports. The TSS always supports ITTAbsent. > > This should be changed both for editorial reasons, and because we > are talking about targets not TSS's at this point. I suggest > > The value of the supported_identity_types field shall be the >bitmapped > representation of the set of identity token types supported by the > target. > A target always supports ITTAbsent. > > Polar Humenn wrote: > > > > This proposal is revised from Rons. > > > > Differences: > > 1. Fixed a couple of typeOs > > 2. Ron's proposal added [1] after para 53. I feel [1] should >outright > > replace para 53. > > 3. Consolidated two changes for SAS_ContextSec into one and two > > changes for IdentityTokenTypes into one. > > 4. Just used CSI::IdentityTokenType for the >supported_identity_types. > > It is more to the point. The fact that we call out that it's a >bitmap > > only in supported_identity_types is fine. We don't need a new >type > > and wording to explain the mapping. > > 5. Removed the footnote from the proposed paragraphs after para >149. > > 6. Reworded those paragraphs, by removing a note about >"consistency" between > > IdentityAssertion in target_supports, supported_identity_types, >and > > supported_naming_mechanisms. I feel that just stating the >requirements > > in the form of "shall" is sufficient, as the notion of >"consistency" > > would need to be defined, and the requirements subsequently >define it. > > Just makes the description a bit more concise and to the point >without > > beating around the bush. > > 6. Changed the name of the default branch of IdentityToken type >from > > "extended_id" to "id", as "extended" implied some notion of an > > extension to an identifier itself, as opposed to the format of >the > > identity assertion. The term "id" should be sufficient. > > 7. Took out the comment about the greatest power of 2 that can be >used > > is 2**31 as this requirement is self evident from the type. > > > > ------------------------------------ > > Resolution of 3906: > > > > base document: > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > [1] Replace the paragraph 53, which starts with "A target that >supports > > identity assertion shall ...", with the following: > > > > When a TSS rejects a request because it carries an identity token > > constructed using an identity type or naming mechanism that is not > > supported by the target, the TSS shall return a ContextError >service > > context element containing major and minor status codes indicating >the > > mechanism was invalid. > > > > [2] In the CSI Module page 16-61, change the last two of the > > IdentityTokenType constants, such that they are powers of 2, for >use in a > > bitmap. Also, change its type definition to an unsigned long and >add > > the comment as follows: > > > > typedef unsigned long IdentityTokenType; > > > > // Additional standard identity token types shall only be >defined by the > > // OMG. All IdentityTokenType constants shall be a power >of 2. > > > > const IdentityTokenType ITTAbsent = 0; > > const IdentityTokenType ITTAnonymous = 1; > > const IdentityTokenType ITTPrincipalName = 2; > > const IdentityTokenType ITTX509CertChain = 4; > > const IdentityTokenType ITTDistinguishedName = 8; > > > > [3] On page 16-46 and in the CSIIOP module IDL section on page >16-65, add > > a new field called "supported_identity_types" to the >SAS_ContextSec > > structure, such that it is defined as follows: > > > > struct SAS_ContextSec{ > > AssociationOptions target_supports; > > AssociationOptions target_requires; > > sequence >privilege_authorities; > > CSI::OIDList supported_naming_mechanisms; > > CSI::IdentityTokenType supported_identity_types; > > }; > > > > [4] Replace para 149 with the following: (the section reference is > > actually a cross reference, in which case it may change in detail >based on > > other changes to the document). > > > > The supported_naming_mechanisms field shall contain a list of 0 or >more > > GSS mechanism OIDs. A TSS shall set the value of this field to >contain the > > GSS mechanism OIDs for which the target supports identity >assertions using > > an identity token of type ITTPrincipalName. The Identity token >types are > > defined in Section 16.2.5, "Identity Token Format," on page 16-17. > > > > [5] Add the following new paragraphs after the new para 149: > > > > The value of the supported_identity_types field shall be the >bitmapped > > representation of the set of identity token types for which the >TSS > > supports. The TSS always supports ITTAbsent. > > > > The value in supported_identity_types shall be non-zero if and >only if the > > IdentityAssertion bit is non-zero in target_supports. The bit > > corresponding to the ITTPrincipalName identity token type shall be > > non-zero in supported_identity_types if and only if the value in > > supported_naming_mechanisms contains at least one element. > > > > [6] In section 16.9.3 (the CSI module idl) add the >IdentityExtension > > typedef and add a default selector to the IdentityTokenType union >as > > follows: > > > > typedef sequence IdentityExtension; > > > > union IdentityToken switch ( IdentityTokenType ) { > > case ITTAbsent: boolean absent; > > case ITTAnonymous: boolean anonymous; > > case ITTPrincipalName: GSS_NT_ExportedName principal_name; > > case ITTX509CertChain: X509CertificateChain >certificate_chain; > > case ITTDistinguishedName: X501DistinguishedName dn; > > default: IdentityExtension id; > > }; > > > > [7] after paragraph 50 add the following new paragraphs: > > > > In addition to the identity token types described in the following >table, > > the IdentityTokenType as defined in Section 16.9.3, "Module CSI - >Common > > Secure Interoperability," provides for the definition of >additional CSIv2 > > identity token types through the default selector of the >IdentityToken > > union type. Additional standard identity token types shall only >be > > defined by the OMG. All IdentityTokenType constants shall be a >power of 2. > ------------------------------------------------------------------- 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: Subject: Re: Revised proposal for 3906 Date: Wed, 16 May 2001 11:04:27 -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: _\d!!'ekd95h$!!'SNd9 Polar, I'm not entirely sure that I understand all of what you said, but my current interpretation is that the following meaning has to be conveyed: "A TSS shall be able to process an identity token of type ITTAbsent; however, the target of the invocation may refuse to accept a request with such a token." Is this anywhere near your intended meaning? -DMC PS: At this point I'm only trying to understand the issue, not propose revised wording. ----- Original Message ----- From: "Polar Humenn" To: "Ron Monzillo" Cc: Sent: Wednesday, May 16, 2001 10:34 AM Subject: Re: Revised proposal for 3906 > > Ron, I am puzzled by your remark, because I thought we worked this >out a > while ago. > > The "TSS" is the "target's security service", which governs all >aspects of > *THE* target's security protocol etc. > > The target (which is in fact the target object) really has no notion >of > what it supports securitywise (except at maybe at some high level). >It is > the security service that it employs that requires and supports >things > directly in the protocol. > > Let me conjecture that you are trying to restrict definition to the >the > "target" object as there may be other objects in the same ORB that >do > different things. That's okay, because we are talking about THE >target's > security service, not the ORB's security service, and not ALL >targets' > security service. > > Also, especially with access control, a TSS may certainly support a > particular naming type, or absent, but the "target" may not not >accept it. > If the target doesn't support a particular naming type, or doesn't >like > absent, it may throw the same exception as the TSS, i.e. a > CORBA::NO_PERMISSOIN only with different minor codes, one for a TSS > unspupport (because of mechanism incompatibility), and a different >code if > a "target" just didn't like it. It effect the "target" doesn't >support > "absent" or a particular naming type, but it's (T)SS does. > > Cheers, > -Polar > > > > On Wed, 16 May 2001, Ron Monzillo wrote: > > > I support the changes proposed by Polar, with one exception > > > > In [5] Polar proposed. > > > > The value of the supported_identity_types field shall be the >bitmapped > > representation of the set of identity token types for which the >TSS > > supports. The TSS always supports ITTAbsent. > > > > This should be changed both for editorial reasons, and because we > > are talking about targets not TSS's at this point. I suggest > > > > The value of the supported_identity_types field shall be the >bitmapped > > representation of the set of identity token types supported by the > > target. > > A target always supports ITTAbsent. > > > > Polar Humenn wrote: > > > > > > This proposal is revised from Rons. > > > > > > Differences: > > > 1. Fixed a couple of typeOs > > > 2. Ron's proposal added [1] after para 53. I feel [1] should >outright > > > replace para 53. > > > 3. Consolidated two changes for SAS_ContextSec into one and two > > > changes for IdentityTokenTypes into one. > > > 4. Just used CSI::IdentityTokenType for the >supported_identity_types. > > > It is more to the point. The fact that we call out that it's >a bitmap > > > only in supported_identity_types is fine. We don't need a new >type > > > and wording to explain the mapping. > > > 5. Removed the footnote from the proposed paragraphs after para >149. > > > 6. Reworded those paragraphs, by removing a note about >"consistency" between > > > IdentityAssertion in target_supports, >supported_identity_types, and > > > supported_naming_mechanisms. I feel that just stating the requirements > > > in the form of "shall" is sufficient, as the notion of "consistency" > > > would need to be defined, and the requirements subsequently >define it. > > > Just makes the description a bit more concise and to the >point without > > > beating around the bush. > > > 6. Changed the name of the default branch of IdentityToken type >from > > > "extended_id" to "id", as "extended" implied some notion of >an > > > extension to an identifier itself, as opposed to the format >of the > > > identity assertion. The term "id" should be sufficient. > > > 7. Took out the comment about the greatest power of 2 that can >be used > > > is 2**31 as this requirement is self evident from the type. > > > > > > ------------------------------------ > > > Resolution of 3906: > > > > > > base document: > > > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > > > [1] Replace the paragraph 53, which starts with "A target that supports > > > identity assertion shall ...", with the following: > > > > > > When a TSS rejects a request because it carries an identity >token > > > constructed using an identity type or naming mechanism that is >not > > > supported by the target, the TSS shall return a ContextError >service > > > context element containing major and minor status codes >indicating the > > > mechanism was invalid. > > > > > > [2] In the CSI Module page 16-61, change the last two of the > > > IdentityTokenType constants, such that they are powers of 2, for >use in a > > > bitmap. Also, change its type definition to an unsigned long and >add > > > the comment as follows: > > > > > > typedef unsigned long IdentityTokenType; > > > > > > // Additional standard identity token types shall only >be defined by the > > > // OMG. All IdentityTokenType constants shall be a power >of 2. > > > > > > const IdentityTokenType ITTAbsent = 0; > > > const IdentityTokenType ITTAnonymous = 1; > > > const IdentityTokenType ITTPrincipalName = 2; > > > const IdentityTokenType ITTX509CertChain = 4; > > > const IdentityTokenType ITTDistinguishedName = 8; > > > > > > [3] On page 16-46 and in the CSIIOP module IDL section on page >16-65, add > > > a new field called "supported_identity_types" to the >SAS_ContextSec > > > structure, such that it is defined as follows: > > > > > > struct SAS_ContextSec{ > > > AssociationOptions target_supports; > > > AssociationOptions target_requires; > > > sequence >privilege_authorities; > > > CSI::OIDList supported_naming_mechanisms; > > > CSI::IdentityTokenType supported_identity_types; > > > }; > > > > > > [4] Replace para 149 with the following: (the section reference >is > > > actually a cross reference, in which case it may change in >detail based on > > > other changes to the document). > > > > > > The supported_naming_mechanisms field shall contain a list of 0 >or more > > > GSS mechanism OIDs. A TSS shall set the value of this field to >contain the > > > GSS mechanism OIDs for which the target supports identity >assertions using > > > an identity token of type ITTPrincipalName. The Identity token >types are > > > defined in Section 16.2.5, "Identity Token Format," on page >16-17. > > > > > > [5] Add the following new paragraphs after the new para 149: > > > > > > The value of the supported_identity_types field shall be the >bitmapped > > > representation of the set of identity token types for which the >TSS > > > supports. The TSS always supports ITTAbsent. > > > > > > The value in supported_identity_types shall be non-zero if and >only if the > > > IdentityAssertion bit is non-zero in target_supports. The bit > > > corresponding to the ITTPrincipalName identity token type shall >be > > > non-zero in supported_identity_types if and only if the value in > > > supported_naming_mechanisms contains at least one element. > > > > > > [6] In section 16.9.3 (the CSI module idl) add the >IdentityExtension > > > typedef and add a default selector to the IdentityTokenType >union as > > > follows: > > > > > > typedef sequence IdentityExtension; > > > > > > union IdentityToken switch ( IdentityTokenType ) { > > > case ITTAbsent: boolean absent; > > > case ITTAnonymous: boolean anonymous; > > > case ITTPrincipalName: GSS_NT_ExportedName >principal_name; > > > case ITTX509CertChain: X509CertificateChain >certificate_chain; > > > case ITTDistinguishedName: X501DistinguishedName dn; > > > default: IdentityExtension id; > > > }; > > > > > > [7] after paragraph 50 add the following new paragraphs: > > > > > > In addition to the identity token types described in the >following table, > > > the IdentityTokenType as defined in Section 16.9.3, "Module CSI >- Common > > > Secure Interoperability," provides for the definition of >additional CSIv2 > > > identity token types through the default selector of the >IdentityToken > > > union type. Additional standard identity token types shall only >be > > > defined by the OMG. All IdentityTokenType constants shall be a >power of 2. > > > > ------------------------------------------------------------------- > 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: Wed, 16 May 2001 11:12:52 -0400 (EDT) From: Polar Humenn To: David Chizmadia cc: Subject: Re: Revised proposal for 3906 In-Reply-To: <003501c0de19$81266660$a000a8c0@chizmadia> Message-ID: > MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9Y\d9#QV!!dGKe9TChd9 David, You are correct in your understanding. -Polar On Wed, 16 May 2001, David Chizmadia wrote: > Polar, > > I'm not entirely sure that I understand all of what you said, >but my > current interpretation is that the following meaning has to be >conveyed: > > "A TSS shall be able to process an identity token of type >ITTAbsent; > however, the target of the invocation may refuse to accept a request >with > such a token." > > Is this anywhere near your intended meaning? > > -DMC > > PS: At this point I'm only trying to understand the issue, not >propose > revised wording. > > > ----- Original Message ----- > From: "Polar Humenn" > To: "Ron Monzillo" > Cc: > Sent: Wednesday, May 16, 2001 10:34 AM > Subject: Re: Revised proposal for 3906 > > > > > > Ron, I am puzzled by your remark, because I thought we worked this >out a > > while ago. > > > > The "TSS" is the "target's security service", which governs all >aspects of > > *THE* target's security protocol etc. > > > > The target (which is in fact the target object) really has no >notion of > > what it supports securitywise (except at maybe at some high >level). It is > > the security service that it employs that requires and supports >things > > directly in the protocol. > > > > Let me conjecture that you are trying to restrict definition to >the the > > "target" object as there may be other objects in the same ORB that >do > > different things. That's okay, because we are talking about THE >target's > > security service, not the ORB's security service, and not ALL >targets' > > security service. > > > > Also, especially with access control, a TSS may certainly support >a > > particular naming type, or absent, but the "target" may not not >accept it. > > If the target doesn't support a particular naming type, or doesn't >like > > absent, it may throw the same exception as the TSS, i.e. a > > CORBA::NO_PERMISSOIN only with different minor codes, one for a >TSS > > unspupport (because of mechanism incompatibility), and a different >code if > > a "target" just didn't like it. It effect the "target" doesn't >support > > "absent" or a particular naming type, but it's (T)SS does. > > > > Cheers, > > -Polar > > > > > > > > On Wed, 16 May 2001, Ron Monzillo wrote: > > > > > I support the changes proposed by Polar, with one exception > > > > > > In [5] Polar proposed. > > > > > > The value of the supported_identity_types field shall be the >bitmapped > > > representation of the set of identity token types for which the >TSS > > > supports. The TSS always supports ITTAbsent. > > > > > > This should be changed both for editorial reasons, and because >we > > > are talking about targets not TSS's at this point. I suggest > > > > > > The value of the supported_identity_types field shall be the >bitmapped > > > representation of the set of identity token types supported by >the > > > target. > > > A target always supports ITTAbsent. > > > > > > Polar Humenn wrote: > > > > > > > > This proposal is revised from Rons. > > > > > > > > Differences: > > > > 1. Fixed a couple of typeOs > > > > 2. Ron's proposal added [1] after para 53. I feel [1] should >outright > > > > replace para 53. > > > > 3. Consolidated two changes for SAS_ContextSec into one and >two > > > > changes for IdentityTokenTypes into one. > > > > 4. Just used CSI::IdentityTokenType for the >supported_identity_types. > > > > It is more to the point. The fact that we call out that >it's a > bitmap > > > > only in supported_identity_types is fine. We don't need a >new type > > > > and wording to explain the mapping. > > > > 5. Removed the footnote from the proposed paragraphs after >para 149. > > > > 6. Reworded those paragraphs, by removing a note about >"consistency" > between > > > > IdentityAssertion in target_supports, >supported_identity_types, and > > > > supported_naming_mechanisms. I feel that just stating the > requirements > > > > in the form of "shall" is sufficient, as the notion of > "consistency" > > > > would need to be defined, and the requirements subsequently >define > it. > > > > Just makes the description a bit more concise and to the >point > without > > > > beating around the bush. > > > > 6. Changed the name of the default branch of IdentityToken >type from > > > > "extended_id" to "id", as "extended" implied some notion of >an > > > > extension to an identifier itself, as opposed to the format >of the > > > > identity assertion. The term "id" should be sufficient. > > > > 7. Took out the comment about the greatest power of 2 that can >be used > > > > is 2**31 as this requirement is self evident from the type. > > > > > > > > ------------------------------------ > > > > Resolution of 3906: > > > > > > > > base document: > > > > > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > > > > > [1] Replace the paragraph 53, which starts with "A target that > supports > > > > identity assertion shall ...", with the following: > > > > > > > > When a TSS rejects a request because it carries an identity >token > > > > constructed using an identity type or naming mechanism that is >not > > > > supported by the target, the TSS shall return a ContextError >service > > > > context element containing major and minor status codes >indicating the > > > > mechanism was invalid. > > > > > > > > [2] In the CSI Module page 16-61, change the last two of the > > > > IdentityTokenType constants, such that they are powers of 2, >for use > in a > > > > bitmap. Also, change its type definition to an unsigned long >and add > > > > the comment as follows: > > > > > > > > typedef unsigned long IdentityTokenType; > > > > > > > > // Additional standard identity token types shall only >be > defined by the > > > > // OMG. All IdentityTokenType constants shall be a >power of 2. > > > > > > > > const IdentityTokenType ITTAbsent = 0; > > > > const IdentityTokenType ITTAnonymous = 1; > > > > const IdentityTokenType ITTPrincipalName = 2; > > > > const IdentityTokenType ITTX509CertChain = 4; > > > > const IdentityTokenType ITTDistinguishedName = 8; > > > > > > > > [3] On page 16-46 and in the CSIIOP module IDL section on page >16-65, > add > > > > a new field called "supported_identity_types" to the >SAS_ContextSec > > > > structure, such that it is defined as follows: > > > > > > > > struct SAS_ContextSec{ > > > > AssociationOptions target_supports; > > > > AssociationOptions target_requires; > > > > sequence >privilege_authorities; > > > > CSI::OIDList supported_naming_mechanisms; > > > > CSI::IdentityTokenType >supported_identity_types; > > > > }; > > > > > > > > [4] Replace para 149 with the following: (the section >reference is > > > > actually a cross reference, in which case it may change in >detail > based on > > > > other changes to the document). > > > > > > > > The supported_naming_mechanisms field shall contain a list of >0 or > more > > > > GSS mechanism OIDs. A TSS shall set the value of this field to >contain > the > > > > GSS mechanism OIDs for which the target supports identity >assertions > using > > > > an identity token of type ITTPrincipalName. The Identity token >types > are > > > > defined in Section 16.2.5, "Identity Token Format," on page >16-17. > > > > > > > > [5] Add the following new paragraphs after the new para 149: > > > > > > > > The value of the supported_identity_types field shall be the >bitmapped > > > > representation of the set of identity token types for which >the TSS > > > > supports. The TSS always supports ITTAbsent. > > > > > > > > The value in supported_identity_types shall be non-zero if and >only if > the > > > > IdentityAssertion bit is non-zero in target_supports. The bit > > > > corresponding to the ITTPrincipalName identity token type >shall be > > > > non-zero in supported_identity_types if and only if the value >in > > > > supported_naming_mechanisms contains at least one element. > > > > > > > > [6] In section 16.9.3 (the CSI module idl) add the >IdentityExtension > > > > typedef and add a default selector to the IdentityTokenType >union as > > > > follows: > > > > > > > > typedef sequence IdentityExtension; > > > > > > > > union IdentityToken switch ( IdentityTokenType ) { > > > > case ITTAbsent: boolean absent; > > > > case ITTAnonymous: boolean anonymous; > > > > case ITTPrincipalName: GSS_NT_ExportedName >principal_name; > > > > case ITTX509CertChain: X509CertificateChain >certificate_chain; > > > > case ITTDistinguishedName: X501DistinguishedName dn; > > > > default: IdentityExtension id; > > > > }; > > > > > > > > [7] after paragraph 50 add the following new paragraphs: > > > > > > > > In addition to the identity token types described in the >following > table, > > > > the IdentityTokenType as defined in Section 16.9.3, "Module >CSI - > Common > > > > Secure Interoperability," provides for the definition of >additional > CSIv2 > > > > identity token types through the default selector of the >IdentityToken > > > > union type. Additional standard identity token types shall >only be > > > > defined by the OMG. All IdentityTokenType constants shall be a >power > of 2. > > > > > > > >------------------------------------------------------------------- > > 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, 16 May 2001 11:31:51 -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: [Fwd: Revised proposal for 3906] Content-Type: multipart/mixed; boundary="------------E5BDE52188C75FA8985E84E8" X-UIDL: "QR!!j)cd9-~,e9Kkg!! I forgot to reply-allMessage-ID: <3B0297E5.B31EB67C@east.sun.com> Date: Wed, 16 May 2001 11:08:21 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: David Chizmadia Subject: Re: Revised proposal for 3906 References: <003501c0de19$81266660$a000a8c0@chizmadia> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm not sure this is the most efficient way for us to get closure on this If you guys have the time (and anyone else) for that matter, what do you say we just call in to the conference number? Let me know. Ron David Chizmadia wrote: > > Polar, > > I'm not entirely sure that I understand all of what you said, but my > current interpretation is that the following meaning has to be conveyed: > > "A TSS shall be able to process an identity token of type ITTAbsent; > however, the target of the invocation may refuse to accept a request with > such a token." > > Is this anywhere near your intended meaning? > > -DMC > > PS: At this point I'm only trying to understand the issue, not propose > revised wording. > > ----- Original Message ----- > From: "Polar Humenn" > To: "Ron Monzillo" > Cc: > Sent: Wednesday, May 16, 2001 10:34 AM > Subject: Re: Revised proposal for 3906 > > > > > Ron, I am puzzled by your remark, because I thought we worked this out a > > while ago. > > > > The "TSS" is the "target's security service", which governs all aspects of > > *THE* target's security protocol etc. > > > > The target (which is in fact the target object) really has no notion of > > what it supports securitywise (except at maybe at some high level). It is > > the security service that it employs that requires and supports things > > directly in the protocol. > > > > Let me conjecture that you are trying to restrict definition to the the > > "target" object as there may be other objects in the same ORB that do > > different things. That's okay, because we are talking about THE target's > > security service, not the ORB's security service, and not ALL targets' > > security service. > > > > Also, especially with access control, a TSS may certainly support a > > particular naming type, or absent, but the "target" may not not accept it. > > If the target doesn't support a particular naming type, or doesn't like > > absent, it may throw the same exception as the TSS, i.e. a > > CORBA::NO_PERMISSOIN only with different minor codes, one for a TSS > > unspupport (because of mechanism incompatibility), and a different code if > > a "target" just didn't like it. It effect the "target" doesn't support > > "absent" or a particular naming type, but it's (T)SS does. > > > > Cheers, > > -Polar > > > > > > > > On Wed, 16 May 2001, Ron Monzillo wrote: > > > > > I support the changes proposed by Polar, with one exception > > > > > > In [5] Polar proposed. > > > > > > The value of the supported_identity_types field shall be the bitmapped > > > representation of the set of identity token types for which the TSS > > > supports. The TSS always supports ITTAbsent. > > > > > > This should be changed both for editorial reasons, and because we > > > are talking about targets not TSS's at this point. I suggest > > > > > > The value of the supported_identity_types field shall be the bitmapped > > > representation of the set of identity token types supported by the > > > target. > > > A target always supports ITTAbsent. > > > > > > Polar Humenn wrote: > > > > > > > > This proposal is revised from Rons. > > > > > > > > Differences: > > > > 1. Fixed a couple of typeOs > > > > 2. Ron's proposal added [1] after para 53. I feel [1] should outright > > > > replace para 53. > > > > 3. Consolidated two changes for SAS_ContextSec into one and two > > > > changes for IdentityTokenTypes into one. > > > > 4. Just used CSI::IdentityTokenType for the supported_identity_types. > > > > It is more to the point. The fact that we call out that it's a > bitmap > > > > only in supported_identity_types is fine. We don't need a new type > > > > and wording to explain the mapping. > > > > 5. Removed the footnote from the proposed paragraphs after para 149. > > > > 6. Reworded those paragraphs, by removing a note about "consistency" > between > > > > IdentityAssertion in target_supports, supported_identity_types, and > > > > supported_naming_mechanisms. I feel that just stating the > requirements > > > > in the form of "shall" is sufficient, as the notion of > "consistency" > > > > would need to be defined, and the requirements subsequently define > it. > > > > Just makes the description a bit more concise and to the point > without > > > > beating around the bush. > > > > 6. Changed the name of the default branch of IdentityToken type from > > > > "extended_id" to "id", as "extended" implied some notion of an > > > > extension to an identifier itself, as opposed to the format of the > > > > identity assertion. The term "id" should be sufficient. > > > > 7. Took out the comment about the greatest power of 2 that can be used > > > > is 2**31 as this requirement is self evident from the type. > > > > > > > > ------------------------------------ > > > > Resolution of 3906: > > > > > > > > base document: > > > > > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > > > > > [1] Replace the paragraph 53, which starts with "A target that > supports > > > > identity assertion shall ...", with the following: > > > > > > > > When a TSS rejects a request because it carries an identity token > > > > constructed using an identity type or naming mechanism that is not > > > > supported by the target, the TSS shall return a ContextError service > > > > context element containing major and minor status codes indicating the > > > > mechanism was invalid. > > > > > > > > [2] In the CSI Module page 16-61, change the last two of the > > > > IdentityTokenType constants, such that they are powers of 2, for use > in a > > > > bitmap. Also, change its type definition to an unsigned long and add > > > > the comment as follows: > > > > > > > > typedef unsigned long IdentityTokenType; > > > > > > > > // Additional standard identity token types shall only be > defined by the > > > > // OMG. All IdentityTokenType constants shall be a power of 2. > > > > > > > > const IdentityTokenType ITTAbsent = 0; > > > > const IdentityTokenType ITTAnonymous = 1; > > > > const IdentityTokenType ITTPrincipalName = 2; > > > > const IdentityTokenType ITTX509CertChain = 4; > > > > const IdentityTokenType ITTDistinguishedName = 8; > > > > > > > > [3] On page 16-46 and in the CSIIOP module IDL section on page 16-65, > add > > > > a new field called "supported_identity_types" to the SAS_ContextSec > > > > structure, such that it is defined as follows: > > > > > > > > struct SAS_ContextSec{ > > > > AssociationOptions target_supports; > > > > AssociationOptions target_requires; > > > > sequence privilege_authorities; > > > > CSI::OIDList supported_naming_mechanisms; > > > > CSI::IdentityTokenType supported_identity_types; > > > > }; > > > > > > > > [4] Replace para 149 with the following: (the section reference is > > > > actually a cross reference, in which case it may change in detail > based on > > > > other changes to the document). > > > > > > > > The supported_naming_mechanisms field shall contain a list of 0 or > more > > > > GSS mechanism OIDs. A TSS shall set the value of this field to contain > the > > > > GSS mechanism OIDs for which the target supports identity assertions > using > > > > an identity token of type ITTPrincipalName. The Identity token types > are > > > > defined in Section 16.2.5, "Identity Token Format," on page 16-17. > > > > > > > > [5] Add the following new paragraphs after the new para 149: > > > > > > > > The value of the supported_identity_types field shall be the bitmapped > > > > representation of the set of identity token types for which the TSS > > > > supports. The TSS always supports ITTAbsent. > > > > > > > > The value in supported_identity_types shall be non-zero if and only if > the > > > > IdentityAssertion bit is non-zero in target_supports. The bit > > > > corresponding to the ITTPrincipalName identity token type shall be > > > > non-zero in supported_identity_types if and only if the value in > > > > supported_naming_mechanisms contains at least one element. > > > > > > > > [6] In section 16.9.3 (the CSI module idl) add the IdentityExtension > > > > typedef and add a default selector to the IdentityTokenType union as > > > > follows: > > > > > > > > typedef sequence IdentityExtension; > > > > > > > > union IdentityToken switch ( IdentityTokenType ) { > > > > case ITTAbsent: boolean absent; > > > > case ITTAnonymous: boolean anonymous; > > > > case ITTPrincipalName: GSS_NT_ExportedName principal_name; > > > > case ITTX509CertChain: X509CertificateChain certificate_chain; > > > > case ITTDistinguishedName: X501DistinguishedName dn; > > > > default: IdentityExtension id; > > > > }; > > > > > > > > [7] after paragraph 50 add the following new paragraphs: > > > > > > > > In addition to the identity token types described in the following > table, > > > > the IdentityTokenType as defined in Section 16.9.3, "Module CSI - > Common > > > > Secure Interoperability," provides for the definition of additional > CSIv2 > > > > identity token types through the default selector of the IdentityToken > > > > union type. Additional standard identity token types shall only be > > > > defined by the OMG. All IdentityTokenType constants shall be a power > of 2. > > > > > > > ------------------------------------------------------------------- > > 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: <3B029D66.2D045D82@east.sun.com> Subject: Re: Revised proposal for 3906] Date: Wed, 16 May 2001 11:54:46 -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: ^J To: Sent: Wednesday, May 16, 2001 11:31 AM Subject: [Fwd: Revised proposal for 3906] > I forgot to reply-all X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 16 May 2001 12:19:11 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: Re: [Fwd: Revised proposal for 3906] In-Reply-To: <3B029D66.2D045D82@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 'e9 Ron, What's the beef? Why do you think it's the target object, and not the TSS? -Polar On Wed, 16 May 2001, Ron Monzillo wrote: > I forgot to reply-all ------------------------------------------------------------------- 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, 16 May 2001 13:15:41 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Ron Monzillo , csiv2-ftf@omg.org Subject: Re: [Fwd: Revised proposal for 3906] References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Ad+!!6pa!!(:k!!5S-e9 we currently define TSS as follows: [16] A client security service (CSS) is the security service associated with the ORB that is used by the client to invoke the target object. A target security service (TSS) is the security service associated with the ORB that hosts the target object. I don't interpret this to mean that uniform policy must be applied to all target objects hosted by the same TSS. A uniform policy bound to a TSS would be an affective implementation, as would an implementation that uses the security service associated with the ORB to enforce target specific policy. Genrally speaking, the spec uses TSS to identify something that is implementing/enforcing the CSIv2 protocol, and target (and in some cases mechanism) to identify somthing that requires a specific CSIv2 target side security policy. As I said before, It would probably be best to talk on the phone. I'll call you. Ron Polar Humenn wrote: > > Ron, > > What's the beef? > > Why do you think it's the target object, and not the TSS? > > -Polar > > On Wed, 16 May 2001, Ron Monzillo wrote: > > > I forgot to reply-all > > ------------------------------------------------------------------- > 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, 16 May 2001 13:26:34 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: polar@adiron.com CC: csiv2-ftf@omg.org Subject: Re: Revised proposal for 3906] References: <3B029D66.2D045D82@east.sun.com> <005301c0de20$88789ee0$a000a8c0@chizmadia> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ")ad9&R>e9?:K!!)%`d9 David wrote: > "A TSS shall be able to process an identity token of type ITTAbsent; > however, the target of the invocation may refuse to accept a request with > such a token." On what basis would the target refuse to accept such a request? I want it to be clear that the absence of ITTAbsent in supported_identity_types cannot be the basis for the refusal of a request made without an identity assertion. The absence of an identity assertion can at best be a coincidence of the refusal, not the cause (at the CSIv2 layer). IMO, the second half of the sentence proposed by David, that is, everything after the ";", clouds this distinction. The value of the supported_identity_types field shall be the bitmapped representation of the set of identity token types supported by the xxxx. A TSS shall not reject requests for lack of an identity assertion (that is, because they contain an identity token of type ITTAbsent). xxxx = Subject of another discussion. Ron David Chizmadia wrote: > > Ron, > > Given that Polar agrees that my single sentence was an accurate > understanding of his point, I think that its just a matter of deciding how > to transfer the sentence into the proposed revision. > > While I'm open to a short telecon, I think that the issue could be > resolved just as quickly by email (though I have to disappear for a couple > of hours, so I probably wouldn't participate directly). > > -DMC > > ----- Original Message ----- > From: "Ron Monzillo" > To: > Sent: Wednesday, May 16, 2001 11:31 AM > Subject: [Fwd: Revised proposal for 3906] > > > I forgot to reply-all X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 16 May 2001 13:46:22 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: Re: Revised proposal for 3906] In-Reply-To: <3B02B84A.3F05FC69@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: UT;e9I0;!!7KSd9oM?!! On Wed, 16 May 2001, Ron Monzillo wrote: > David wrote: > > > "A TSS shall be able to process an identity token of type >ITTAbsent; > > however, the target of the invocation may refuse to accept a >request with > > such a token." > > On what basis would the target refuse to accept such a request? The target may not accept the use of Absent, because he may decide that the principal must quote some individual. The target is expecting a firewall to forward a request on the client's behalf. Therefore the principal for that request, R, should look like (Firewall|Client) says R The target will be happy. However, if the firewall screws up, or perhaps is another firewall, maybe it shouldn't accept it. You get something like Firewall says R This may not be acceptable to the target object. However, the TSS has acceptted it, and supported the invocation enough to get dispatched to the target object. Therefore the TSS supports Absent, but the target object "effectively" doesn't. > I want it to be clear that the absence of ITTAbsent in > supported_identity_types cannot be the basis for the refusal of a > request made without an identity assertion. That is agreed. There is NO WAY one can turn on, or turn off the support of ITTAbsent in supported_identity_types, because it doesn't have a bit representation. Therefore a TSS always supports IITAbsent. > The absence of an identity assertion can at best be a coincidence of > the refusal, not the cause (at the CSIv2 layer). That's what a "TSS always supports ITTAbsent" means. > IMO, the second half of the sentence proposed by David, that is, > everything after the ";", clouds this distinction. Well, it clouds the distinction, but he's not proposing it go into the text. He's just trying to understand. The fact is that no matter how correct and acceptable, and supported a whole CSIv2 context is to a TSS, the target can still reject it. > The value of the supported_identity_types field shall be the bitmapped > representation of the set of identity token types supported by the > xxxx. A TSS shall not reject requests for lack of an identity > assertion (that is, because they contain an identity token of type > ITTAbsent). I don't think you need to go that far. A TSS shall always support ITTAbsent is clear enough. If we just talk about the TSS here, and not the target object, there is not problem. Cheers, -Polar > xxxx = Subject of another discussion. > > Ron > > David Chizmadia wrote: > > > > Ron, > > > > Given that Polar agrees that my single sentence was an >accurate > > understanding of his point, I think that its just a matter of >deciding how > > to transfer the sentence into the proposed revision. > > > > While I'm open to a short telecon, I think that the issue >could be > > resolved just as quickly by email (though I have to disappear for >a couple > > of hours, so I probably wouldn't participate directly). > > > > -DMC > > > > ----- Original Message ----- > > From: "Ron Monzillo" > > To: > > Sent: Wednesday, May 16, 2001 11:31 AM > > Subject: [Fwd: Revised proposal for 3906] > > > > > I forgot to reply-all > ------------------------------------------------------------------- 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, 16 May 2001 17:35:34 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: dflinn@iona.com CC: csiv2-ftf@omg.org Subject: Re: Revised proposal for 3906] References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: RVfd9aR>!!cG6e9\ch!! Don, I've discussed this with Polar, and I would like to repropose my original suggested modification to the resolution prepared by Polar. Ron For item [5] of the proposed resolution to 3906 use the following The value of the supported_identity_types field shall be the bitmapped representation of the set of identity token types supported by the target. A target always supports ITTAbsent. The value in supported_identity_types shall be non-zero if and only if the IdentityAssertion bit is non-zero in target_supports. The bit corresponding to the ITTPrincipalName identity token type shall be non-zero in supported_identity_types if and only if the value in supported_naming_mechanisms contains at least one element. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 17 May 2001 09:49:32 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: , Subject: Re: Revised proposal for 3906] In-Reply-To: <3B02F2A6.46F237C7@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: "Mbd98IIe9d0S!!=)+!! On Wed, 16 May 2001, Ron Monzillo wrote: > Don, > > I've discussed this with Polar, and I would like to repropose > my original suggested modification to the resolution prepared > by Polar. For those interested this is the "discusson": 1. Ron called me at 5:00. 2. I thought going to the gym was more important than talking to him. 3. I think the point is overly pendantic. 4. If it's really conformance point, nobody will give a rat's ass anyway. 5. Stop! Stop! I conceed, I need to go to the gym! Call it target instead of TSS. Cheers, -Polar > > Ron > > For item [5] of the proposed resolution to 3906 use the following > > The value of the supported_identity_types field shall be the >bitmapped > representation of the set of identity token types supported by the > target. A target always supports ITTAbsent. > > The value in supported_identity_types shall be non-zero if and only >if > the > IdentityAssertion bit is non-zero in target_supports. The bit > corresponding to the ITTPrincipalName identity token type shall be > non-zero in supported_identity_types if and only if the value in > supported_naming_mechanisms contains at least one element. > ------------------------------------------------------------------- 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