All right, I think we are in violent agreement. Sorry if we've wasted oo much
bandwidth on this issue -- I just want to be sure that we were all on the smae
page.
The IAB doesn't enter into it, nor do I see any need for their involvement in
handing out OIDs. It is all done by IANA, and all it takes is a mail message,
as I said before.
I wasn't trying to suggest anything. I must have missed that message.
Correct. However, always remember that global uniqueness does not translate
into global knowledge. Anyone can obtain an OID and assign numbers to whatever
they want and those numbers are guaranteed to be unique. The problem comes
when
you want to find out what numbers have been assigned to something -- there's
no
guaranteed way to do that. There has been some work to implement a "translate
OID into string form" service in the directory, first on an ad-hoc basis and
later as part of the formal X.500 specifications, but it doesn't amount to
much
yet to the best of my knowledge.
Agreed, and that is a major concern of mine with respect to X.500 DUAs in
particular. Something better is needed, but in this particular case we are
distributing the knowledge of both the syntax and the semantics trhough a spec,
presumably. Maybe not the most elegant or universal way, but sufficient for our
purpose.
Telex numbers all have assigned OIDs as well, I believe. It might be nice
if phone numbers did too, but I don't know of any point in the OID tree
for them.
Actually, DEC registered such an OID as part of thier X.500 package, for usder
organizations that might not have taken the trouble to register with ANSI of
the equivalent in thier country. they can use their organizations phone number
as a qualifier.
Right, this is how all OIDs work. When an OID is assigned to a particular
organization all OIDs with values "under" that point in the tree also belong
to
that organization. Here at Innosoft, for example, we have several branches
under our assigned OID: one for directory objects, another for private SNMP
MIBs, and so on. The structure is ours to decide. (We do it in a very
high-tech
way -- there's a section on Jeff Allison's whiteboard where we write down our
assignments!)
Wow! Why didn't I think of that! We've done that for a few locally defined
attributes (not yet used or exported anywhere, and haven't even written them
down yet, except in the code.
I don't think X.500 provides enough mechanism to find out the syntax, but
there's an Internet Draft floating around that does implement directory types
for abstract syntaxes, I believe.
X.500 '93 provides a mechanism, but I'm not aware of any implementation or
usage yet. right now I can't think of the name of the attribute.
Semantics are another matter. You'd have to start by developing a
representation of semantics in ASN.1, and I'm pretty sure nothing anybody has
done along these lines is anywhere near general enough. (For example, ASN.1 is
very limited in its ability to describe the relationships between entities --
all it does in practice is leave "loopholes" where you can put in things that
are defined "out of band". This is what ANY DEFINED BY and similar constructs
end up doing.)
The X.500 '93 provides a field in the attribute syntax description called
something like description or intent (I can't remember) that could be used to
provide information about the semantics, but the comments in this section imply
that this is to be used to provide an e4xplanation in English of what the ASN.1
is trying to describe. The user is supposed to devine the semantics from the
attribute name, I guess.
That's why I said that Jim Galvin's statement about not being able to create
an
OID for an rfc822 e-mail name header did not compute. It is not necessary to
have an instantiation of X.500 in hand in order to define such an attribute,
and it certainly isn't necessary for either an X.500 DSA or DUA to
"understand"
that attribute (a simple text string) in order to create a certificate which
contains it. the PEM or PEM/MIME UA has to understand it -- that's all, at
least as far as I understand.
Sure. You can define such an attribute, but then you have to define its
semantics and you also have to convince people to use it rather than one
they devised themselves. (We have found it necessary to define a whole
bunch of directory attributes to support directory synchronization operations,
for example.)
My only point was that you didn't have to inform all the X.500 DSA vendors or
the DUA vendors. If it is an e-mail name that appears in a certificate, only
PEM or PEM/MIME really has to be able to generate and interpret it at this
stage.
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820