Maybe it has a DOD OID, reflecting its ARPAnet routes?
Yes, it has iso(1) identifiedOrganization(3) dod(6) internet(1)
I thought so. So it already is an ISO identified organization, assuming that
the IETF has the right to use the Internet OID. Who and where is the
secretariat that controls these things -- the Internet Architecture Board
(IAB?).What role does the INA play (or the IANA? I'm not sure of either the
acronym or the organization name)?
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.
There are so many OIDs (cardinality one notch up from integers and equivalent
to the cardinality of the reals if you ignore limits imposed by BER and assume
the continuum hypothesis to be true) that there are plenty to go around!
I didn't mean to imply that it did "contain" a directory. by subsume, I meant
that like X.400 and other specs, X.500 followed the concept of Organizational
IDs and a numeric way of globally qualifying a "name" by assigning ownership.
That is totally independent of a DN -- I agree.
I don't know what you mean by "organizationally qualified" attributes -
perhaps an attribute whose attribute type OID is assigned by the same
organization which operates the Directory Management Domain where the entry
containing that attribute resides?
That's very close to what I think I meant. But my impression was that if my
organization was assigned an OID, I could uniquely name any abstract construct
that I wished to, and by virtue of the OID that name would be guaranteed to be
globally unique.
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.
In particular, I think that I can create an attribute, e.g., a particular data
structure, give it a unique name, and also assign it (the attribute) a unique
encoded value, e.g., an X.509 certificate format. I _thought_, though I might
be wrong, that such an attriibute could exist totally outside of an X.500
directory, >e.g, the coded value that indicates RSA MD5 message digest
algorithm in a digital signature block.
Sure. But I might choose to label MD5 with a different OID.
As a data structure, an attribute normally has values (contents). But not all
names necessarily have values or variable contents. for all I know, IBM "True
Blue" may have an OID associated with it, bu it is a paint color. As a color,
it might have a numeric value in the Munsell color system, but "blue" doesn't
have a value in and of itself. (Again, someone correct me if I have an
incorrect understanding.)
My usual example here is the fact that all of the software products and their
respective error codes on the system I happen to be using (VMS) have unique
OIDs assigned to them. This happens "for free" when you register products with
with Digital (which almost all VMS developers do). There are literally hundreds
of thousands of defined OIDs as a result of this.
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.
Whoops, I just realized one of my problems. OID stands for Object Identifier,
not Organization Identifier, although an organization can have an OID.
Right. And there's no defined structure you can assume for a given
organization's OIDs, even assuming you know the OID that was assigned to a
particular organization, which is generally impossible.
So what I meant by the rather nebulous term "organizationally qualified
attribute" was an attribute that has as its leading components the OID of the
organization that assigns it, and a single trailing part that is an attribute
number assign by that orgnaization.
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!)
I don't think that is precisely the same as
what you said. I don't believe that an attribute has to "reside" anywhere, and
although a Private Directory Management Domain's OID can be used to uniquely
qualify an attribute through the assignment of an OID, a company using the
services of a PRDMD can also define a uniqe attribute that the PRDMD knows
nothing about. It would certainly be nice if there were a uniform and simple
way of disseminating the existance, syntax, and semantics of these attributes,
and X.500 '93 provides some mechanisms, but this isn't required.
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.
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.)
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.)
Ned