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)?
Somebody correct me if I am wrong, but I thought that the use of OIDs and
organizationally qualified attributes registered under the global name
registration tree, e.g., under the joint-iso-ccitt arc (2, was independent
of and subsumes X.500.
OIDs are independent of X.500 Directory Distinguished names and does not
"contain" a directory. An OSI registration authority will assign an
organization an OID or a Directory name or both, but they are used for very
different purposes.
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.
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.
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.)
X.500 is a hierarchical collection of entries. Entries are a set of
attributes:
each attribute is a (type, value(s) pair). Attribute types are OIDs.
Whoops, I just realized one of my problems. OID stands for Object Identifier,
not Organization Identifier, although an organization can have an OID.
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. 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.
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.
The
OID "iso(1) identifiedOrganization(3) teletrust(36) attr(4) pemCRL(1)" does
not
identify a single CRL, nor a CRL attribute in a particular entry, and does
not contain any information to enable CRL attributes of this type to be found
in the Directory, as it may be used as the type of an attribute in an entry
located anywhere in the Directory.
The map is not the territory. The name of an attribute is not equivalent to an
instance of bit values that have the structure of that attribute. Agreed.
Now I think we are in sync. So my question was, what is the OID (numeric
encoding) of the attribute "Certificate" as used in the baseline X.509
specification, and what was the numeric encoding of the attribute "Certificate"
as defined in RFC-142x. And moreover, what OID _should_ be assigned to the "V3
certificate" to be defined in RFC-XXXX for PEM/MIME before the ISO version is
standardized. Does the proposed v3 ISO certificate have a different OID than
the v1, in addition to the version number that is encoded within it?
And I guess I am assuming that the way that the certificate is actually encoded
includes both the attribute OID, identifying the structure as a certificate of
a particular type, together with the appropriate values, as opposed to somehow
recognizing that a particular structure is a certificate through some context
mechanism.
Sorry if these are dumb questions, but I've never gotten down to the actual bit
level in these specs before -- I had someone else to do it!
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820