Issue 3907: Issue: CSIv2 Identity Assertion (corba-rtf) Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: Issue on Document orbos/2000-08-04, CSIv2 Joint Submission Document: orbos/2000-08-04, CSIv2 Joint Submission Subject: Identity Assertion of X.501 Distinguished Name is not good enough Severity: Critical Summary: The Identity Token union contains a branch that is labled X501DistinguishedName. A single DN is insufficient to identify an entity. A path of X501Distinguished Names is needed instead. Also, other concerns about naming types are raised. Discussion: An X.501 Distinguished Name is insufficient to identify a single entity. The name must be accompanied by the name of its defining authority. In the case of public key certificates, the names certificate authority must be included. The chain of DNs in this manner must be included up to a root authority to have any definitive meaning. This approach will be consistent with the client sending a X.509 Certificate Chain. A DN path is actually defined by the certificate chain. Furthermore, the DN path should only come from an authority that is acceptable to the server, whether it be a DN path, or an X.509 Certificate Chain. The IOR should list the acceptable authorities and their name types. It is becoming more an more evident that we must invent GSS_NT_Export_Name types for X.509 Certificate Chain and X.501 DN path. The SAS_ContextSec structure should list, instead of the naming types, the naming authorities! We shall assume that the name types of the asserted identities shall be the same as the name types of listed naming authorities in the IOR. This is the only way this procedure can work Interoperable and without the client Guessing what it should do. Suggestions: An OID for an X.509 Public Key Certificate Chain shall be defined for a GSS Export Name, and its encoding will be a ASN1 sequence of and X.509 certificate with the least significant certificate first. An OID for an X.501 Distinguished Name Path shall be defined for a GSS Exported Name, and its encoding shall be an ASN1 sequence of an X.501 Distinguished Name with the least significant name first. To avoid having the target put a whole certificate chain in its IOR, a new OID shall be allocated in which its GSS Exported Name encoding is a X.501 DN path, but stipulates that the client should send a certificate chain from that named authority. This GSS Exported Name shall only be used in IORs and not for transmission in the Identity Token. typedef Security::GSS_NT_ExportedName NamingAuthority; struct CompoundSecMech { Security::AssociationOptions target_requires; IOP::TaggedComponent transport_mech; sequence<ServiceConfiguration> privilege_authorities; sequence<NamingAuthority> naming_authorities; }; Resolution: Revised Text: Actions taken: September 20, 2000: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 20 Sep 2000 19:03:59 -0400 (EDT) From: Polar Humenn To: issues@omg.org, secrev@omg.org, orbos@omg.org Subject: Issue: CSIv2 Identity Assertion Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Zkd!!O/~e9,^fd9hbf!! Issue on Document orbos/2000-08-04, CSIv2 Joint Submission Document: orbos/2000-08-04, CSIv2 Joint Submission Subject: Identity Assertion of X.501 Distinguished Name is not good enough Severity: Critical Summary: The Identity Token union contains a branch that is labled X501DistinguishedName. A single DN is insufficient to identify an entity. A path of X501Distinguished Names is needed instead. Also, other concerns about naming types are raised. Discussion: An X.501 Distinguished Name is insufficient to identify a single entity. The name must be accompanied by the name of its defining authority. In the case of public key certificates, the names certificate authority must be included. The chain of DNs in this manner must be included up to a root authority to have any definitive meaning. This approach will be consistent with the client sending a X.509 Certificate Chain. A DN path is actually defined by the certificate chain. Furthermore, the DN path should only come from an authority that is acceptable to the server, whether it be a DN path, or an X.509 Certificate Chain. The IOR should list the acceptable authorities and their name types. It is becoming more an more evident that we must invent GSS_NT_Export_Name types for X.509 Certificate Chain and X.501 DN path. The SAS_ContextSec structure should list, instead of the naming types, the naming authorities! We shall assume that the name types of the asserted identities shall be the same as the name types of listed naming authorities in the IOR. This is the only way this procedure can work Interoperable and without the client Guessing what it should do. Suggestions: An OID for an X.509 Public Key Certificate Chain shall be defined for a GSS Export Name, and its encoding will be a ASN1 sequence of and X.509 certificate with the least significant certificate first. An OID for an X.501 Distinguished Name Path shall be defined for a GSS Exported Name, and its encoding shall be an ASN1 sequence of an X.501 Distinguished Name with the least significant name first. To avoid having the target put a whole certificate chain in its IOR, a new OID shall be allocated in which its GSS Exported Name encoding is a X.501 DN path, but stipulates that the client should send a certificate chain from that named authority. This GSS Exported Name shall only be used in IORs and not for transmission in the Identity Token. typedef Security::GSS_NT_ExportedName NamingAuthority; struct CompoundSecMech { Security::AssociationOptions target_requires; IOP::TaggedComponent transport_mech; sequence privilege_authorities; sequence naming_authorities; }; ------------------------------------------------------------------- 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:33:21 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Issue 3907 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 1Z>!!A-`!!T["!!]!>e9 Comments and suggestions on Sun's proposals to Issue 3907 I agree with the stance that the issue should be tabled, as this issue requires much more understanding of PKIX, and probably some help from them. It is becoming ever more clear to me, that a DN needs to locate attributes of an identity, however, we may need something like an "ldap:" URL included in the identity assertion to resolve this issue. Howver, it is more of a PKIX issue, which they are still arguing about. We should table this in an effort to resolve the other issues. It just may be that we have to solve this PKIX problem in CORBA. 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 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 Date: Wed, 27 Aug 2003 17:58:06 -0400 From: Jishnu Mukerji Organization: Software Business Unit, Hewlett-Packard User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: CORBA Core RTF Subject: Issue 3907 discussion Referring to http://www.omg.org/issues/issue3907.txt am I correct in surmising that the changes proposed for fixing this issue in its description are backward incompatible with the existing specification? If that is the case I suggest that we close this issue No Change. Comments? Jishnu. X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Thu, 28 Aug 2003 08:35:12 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: Jishnu Mukerji cc: CORBA Core RTF Subject: Re: Issue 3907 discussion On Wed, 27 Aug 2003, Jishnu Mukerji wrote: > Referring to http://www.omg.org/issues/issue3907.txt am I correct in > surmising that the changes proposed for fixing this issue in its > description are backward incompatible with the existing specification? > > If that is the case I suggest that we close this issue No Change. > > Comments? The specific resolution is outdated since it was an issue before the CSIv2 FTF ended, i.e. it contains "Security::", and it was tabled. However, the problem still exists. The suggested resolution is not backward incompatible. The suggested resolution enhances the CSIv2 protocol in that you do not have to create a certificate chain in order just to transmit an fully specified identity, which forces you to perform all computationally expensive signature and constraint checks. Also, the suggested resolution remains backward compatible in that a previous version servers will not be able to specify this new name type as acceptable, so new version clients will not send it. A client of previous versions cannot send this new type of identity token. However, if the server's IOR lists the new name type as the only acceptable name type, then the client will reject the CSIv2 sub component, as if it would reject any component for incompatiblity reasons, e.g. does not support SSL, or does not accept the listed privilege authority, or can even convert the identity to the desired acceptable name type. Cheers, -Polar > Jishnu. > -- ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 28 Aug 2003 10:56:30 -0400 From: Jishnu Mukerji Organization: Software Business Unit, Hewlett-Packard User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Polar Humenn Cc: CORBA Core RTF Subject: Re: Issue 3907 discussion So let us decide then whether this should be fixed via this RTF or it should be fixed some other way. If we decide to try to fix it via this RTF we will need an updated resolution relative to CORBA 3.0.x (or even the Draft CORBA 3.1 from the last CORBA Core RTF) to advance eventually to a vote. Thanks. Jishnu. Polar Humenn wrote: On Wed, 27 Aug 2003, Jishnu Mukerji wrote: Referring to http://www.omg.org/issues/issue3907.txt am I correct in surmising that the changes proposed for fixing this issue in its description are backward incompatible with the existing specification? If that is the case I suggest that we close this issue No Change. Comments? The specific resolution is outdated since it was an issue before the CSIv2 FTF ended, i.e. it contains "Security::", and it was tabled. However, the problem still exists. The suggested resolution is not backward incompatible. The suggested resolution enhances the CSIv2 protocol in that you do not have to create a certificate chain in order just to transmit an fully specified identity, which forces you to perform all computationally expensive signature and constraint checks. Also, the suggested resolution remains backward compatible in that a previous version servers will not be able to specify this new name type as acceptable, so new version clients will not send it. A client of previous versions cannot send this new type of identity token. However, if the server's IOR lists the new name type as the only acceptable name type, then the client will reject the CSIv2 sub component, as if it would reject any component for incompatiblity reasons, e.g. does not support SSL, or does not accept the listed privilege authority, or can even convert the identity to the desired acceptable name type. Cheers, -Polar Jishnu. -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Strategy & Technology Office Bridgewater NJ 08807, USA Software Business Unit Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Thu, 28 Aug 2003 11:03:59 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: Jishnu Mukerji cc: CORBA Core RTF Subject: Re: Issue 3907 discussion Well, I think it should be tabled a bit for now. I'll be at the SAML meeting happening at the same time as the OMG meeting. We will be discussing the ID-FF and how to resolve most integration issues with SAML and XACML. Something beneficial insight may come out of that meeting that might yield some popular alternate solutions to the problem. What's the critical timeframe? -Polar On Thu, 28 Aug 2003, Jishnu Mukerji wrote: > So let us decide then whether this should be fixed via this RTF or it > should be fixed some other way. If we decide to try to fix it via this > RTF we will need an updated resolution relative to CORBA 3.0.x (or even > the Draft CORBA 3.1 from the last CORBA Core RTF) to advance eventually > to a vote. > > Thanks. > > Jishnu. > > Polar Humenn wrote: > > On Wed, 27 Aug 2003, Jishnu Mukerji wrote: > > > > > >>Referring to http://www.omg.org/issues/issue3907.txt am I correct in > >>surmising that the changes proposed for fixing this issue in its > >>description are backward incompatible with the existing specification? > >> > >>If that is the case I suggest that we close this issue No Change. > >> > >>Comments? > > > > > > The specific resolution is outdated since it was an issue before the CSIv2 > > FTF ended, i.e. it contains "Security::", and it was tabled. However, the > > problem still exists. > > > > The suggested resolution is not backward incompatible. The suggested > > resolution enhances the CSIv2 protocol in that you do not have to create a > > certificate chain in order just to transmit an fully specified identity, > > which forces you to perform all computationally expensive signature and > > constraint checks. > > > > Also, the suggested resolution remains backward compatible in that a > > previous version servers will not be able to specify this new name > > type as acceptable, so new version clients will not send it. > > > > A client of previous versions cannot send this new type of identity token. > > However, if the server's IOR lists the new name type as the only > > acceptable name type, then the client will reject the CSIv2 sub component, > > as if it would reject any component for incompatiblity reasons, e.g. does > > not support SSL, or does not accept the listed privilege authority, or can > > even convert the identity to the desired acceptable name type. > > > > Cheers, > > -Polar > > > > > >>Jishnu. > >> > > > > > > > -- ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 28 Aug 2003 11:15:10 -0400 From: Jishnu Mukerji Organization: Software Business Unit, Hewlett-Packard User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Polar Humenn Cc: CORBA Core RTF Subject: Re: Issue 3907 discussion Polar Humenn wrote: Well, I think it should be tabled a bit for now. I'll be at the SAML meeting happening at the same time as the OMG meeting. We will be discussing the ID-FF and how to resolve most integration issues with SAML and XACML. Something beneficial insight may come out of that meeting that might yield some popular alternate solutions to the problem. Sounds very reasonable. Lets hold off on it for now then. What's the critical timeframe? None. I am just poking everyone about issues that are still open. Thanks, Jishnu.