Issue 4143: OIDs (csiv2-ftf) Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: There is a need to define OIDs, at least one for GSSUP. However, an OID is represented by a sequence of positive integers, encoded as a octet sequence. The encoding has the property that two encodings are equivalent if and only if their definitions are equivalent (which is something ASN.1 DER is not particulary good at). We cannot define a costant in IDL for a sequence of octets. However, I've seen an number of ASN.1 compilers and it seems that the internal form of the definition of an OID is a string of natural numbers in base 10 separated by dots. This is a parseable representation, and widely used. I suggest that we introduce a definition, possibly a type, for and OID string representation. module CSI { // // An OID String Representation. // The OID is represented in dot format. // For example, "2.23.130.1.1.1". // typedef string OIDStringRep; }; module GSSUP { const OIDStringRep GSSUP_OID_DEF = "2.23.130.1.1.1"; }; This will allow ASN.1 compilers to at least map from this internal string representation if they don't already do so. What do you think? If there is consensus, I'll raise an issue, and we can resolve it. Resolution: Close issue with revised text. Revised Text: The following modifications are presented against document http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf. [1] Place the following into module CSI: // The following type represents the string representation // of an ASN.1 OBJECT IDENTIFIER (OID). OIDs are represented // by the string "oid:" followed by the integer base 10 // representation of the OID separated by dots. // For example, the OID signifying the OMG is represented as: // "oid:2.23.130" typedef string StringOID; [2] In Section 16.9.5 GSSUP replace the comment block starting with "// The GSS Object Identifier allocated for the username/password ..." with the following: // The GSS Object Identifier allocated for the username/password mechanism is defined below. // // { iso-itu-t (2) international-organization (23) omg (130) security (1) // authentication (1) gssup-mechanism (1) } const CSI::StringOID GSSUPMechOID = "oid:2.23.130.1.1.1"; Actions taken: January 10, 2001: received issue Discussion: OIDs are usually expressed in documents and programming tools as base 10 integers separated by dots, such as "2.23.130". It would be good to adopt something similar to this representation so that they can be represented as constants in IDL, as a sequence of octets does not have a constant representation in IDL. A typedef created to handle this will be: typedef string StringOID; We use the term "StringOID" because already have an "OID" type in the CSI module, and in the spirit of the CosNamingExt module, it is analogous to the "Name" and "StringName" types and their definitions. End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 10 Jan 2001 14:54:19 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: OIDs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: pkQd9=Ng!!<6L!!F;Je9 There is a need to define OIDs, at least one for GSSUP. However, an OID is represented by a sequence of positive integers, encoded as a octet sequence. The encoding has the property that two encodings are equivalent if and only if their definitions are equivalent (which is something ASN.1 DER is not particulary good at). We cannot define a costant in IDL for a sequence of octets. However, I've seen an number of ASN.1 compilers and it seems that the internal form of the definition of an OID is a string of natural numbers in base 10 separated by dots. This is a parseable representation, and widely used. I suggest that we introduce a definition, possibly a type, for and OID string representation. module CSI { // // An OID String Representation. // The OID is represented in dot format. // For example, "2.23.130.1.1.1". // typedef string OIDStringRep; }; module GSSUP { const OIDStringRep GSSUP_OID_DEF = "2.23.130.1.1.1"; }; This will allow ASN.1 compilers to at least map from this internal string representation if they don't already do so. What do you think? If there is consensus, I'll raise an issue, and we can resolve it. 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-Sender: hlowe@emerald.omg.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 10 Jan 2001 17:59:40 -0500 To: Polar Humenn From: Henry Lowe Subject: Re: OIDs Cc: csiv2-ftf@omg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: IJ/e99kgd9mPP!!EFL!! While this message is about how to represent an OID, when you actually get down to wanting to assign them, let me know. OMG is now a registration authority for OIDs and I will be handling giving them out. However, I only assign them for OMG work (I don't want to get into doing it for outside organizations). Best regards, Henry -------------------------------- At 02:54 PM 01/10/2001 -0500, Polar Humenn wrote: > >There is a need to define OIDs, at least one for GSSUP. However, an OID is >represented by a sequence of positive integers, encoded as a octet >sequence. The encoding has the property that two encodings are equivalent >if and only if their definitions are equivalent (which is something ASN.1 >DER is not particulary good at). > >We cannot define a costant in IDL for a sequence of octets. However, I've >seen an number of ASN.1 compilers and it seems that the internal form of >the definition of an OID is a string of natural numbers in base 10 >separated by dots. This is a parseable representation, and widely used. > >I suggest that we introduce a definition, possibly a type, for and OID >string representation. > > module CSI { > // > // An OID String Representation. > // The OID is represented in dot format. > // For example, "2.23.130.1.1.1". > // > typedef string OIDStringRep; > }; > > module GSSUP { > const OIDStringRep GSSUP_OID_DEF = "2.23.130.1.1.1"; > }; > >This will allow ASN.1 compilers to at least map from this internal string >representation if they don't already do so. > >What do you think? If there is consensus, I'll raise an issue, and we can >resolve it. > >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 > Discussion: OIDs are usually expressed in documents and programming tools as base 10 integers separated by dots, such as "2.23.130". It would be good to adopt something similar to this representation so that they can be represented as constants in IDL, as a sequence of octets does not have a constant representation in IDL. A typedef created to handle this will be: typedef string StringOID; We use the term "StringOID" because already have an "OID" type in the CSI module, and in the spirit of the CosNamingExt module, it is analogous to the "Name" and "StringName" types and their definitions. Resolution: Close issue with revised text. Revised Text: The following modifications are presented against document http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf. [1] Place the following into module CSI: // The following type represents the string representation // of an ASN.1 OBJECT IDENTIFIER (OID). OIDs are represented // by the string "oid:" followed by the integer base 10 // representation of the OID separated by dots. // For example, the OID signifying the OMG is represented as: // "oid:2.23.130" typedef string StringOID; [2] In Section 16.9.5 GSSUP replace the comment block starting with "// The GSS Object Identifier allocated for the username/password ..." with the following: // The GSS Object Identifier allocated for the username/password mechanism is defined below. // // { iso-itu-t (2) international-organization (23) omg (130) security (1) // authentication (1) gssup-mechanism (1) } const CSI::StringOID GSSUPMechOID = "oid:2.23.130.1.1.1";