A few thoughts:
1. I can see lots of value in using a file (that maps an object identifier's
numeric representation to and from its string representation) when decoding.
I can't see much use when encoding. Perhaps someone else can?
2. When possible, use an existing standard. RFC 2253's oid = 1*DIGIT *("."
1*DIGIT) is probably the most common numeric representation of an object
identifier.
3. RFC 2253's "short names" identify attribute types (i.e., attributeType =
(ALPHA 1*keychar) / oid), not object identifiers. I am not aware of any
standard for short object identifier names, nor do I see a whole lot of
value in them.
Frank
> -----Original Message-----
> From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 25, 2000 5:14 PM
> To: [EMAIL PROTECTED]
> Subject: Objects and a configuration file
>
>
> In this whole discussion about OIDs and object names, there's one
> thought that I think Mickael Str�der mentioned about having the object
> names completely configurable through a file or maybe a section of
> openssl.cnf. On the other hand, as it is today, there are a number of
> places in OpenSSL today that depends on the existing names being
> known.
>
> In any case, the current format in crypto/objects/objects.txt
> is very much a hack (partly created by yours truly) and should be
> replaced by something with a bit more elegance and readability into
> it.
>
> I'm definitely willing to redesign the contents of objects.txt, and am
> currently looking for ideas. I'm pondering regular LDAP schema
> entries as shown in RFC2256, or something similar to Peter Gutmanns
> config file for dumpasn1, or maybe something different. There's also
> the format used by some OpenSSL utilities which is very simple (OID
> followed by a "shortname" optionally followed by a "longname").
>
> Comments?
>
> --
> Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
> Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
> Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10
> Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
> Member of the OpenSSL development team: http://www.openssl.org/
> Software Engineer, Celo Communications: http://www.celocom.com/
>
> Unsolicited commercial email is subject to an archival fee of $400.
> See <http://www.stacken.kth.se/~levitte/mail/> for more info.
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
