Bob,
If I understand you, you are talking about the serial number in the
certificate?? Surely those serial numbers are intended to increment
for each new certificate issued, and never repeat within a given CA's
domain. Are you suggesting that they are relative to the DN?
What happens the next time that I issue a certificate to that user,
even if it has a different validity period? I hope I misunderstood
you.
Whoops! I was trying to find something to agree with in Tom's message
and went overboard. Serial numbers are unique per CA, not per
subject. So, although there is no requirement to make them monotonic,
increasing values, there would be a problem in using an employee
serial number here since the number needs to change if the certificate
is revoked for other than name change or termination purposes. So, I
sopke too soon and you're right, the serial nukber is a bad place to
"hide" an employee ID.
I said I was probably in over my head, and now I am certain of it. Not
to be too facetious, but what is the ASN.1 definition of "silly"?
The ASN.1 defintion of silly is contained, by example, in numerous
places in the 42 pages of 1988 X.400 formats, most obviously in the
vaious, redundant formats for security options ;-).
I've gone back to X.521 (as opposed to X.520) and read it again more
carefully, and I see that the Organization object class must contain
the organizationName and may contain the organizationalAttributeSet,
but organizationalAttributeSet doesn't contain the OrganizationalUnit
object class! Further, the Organizational Unit object class is a
subclass of Top, not of Organization. And Organizational Unit may also
contain the organizationalAttributeSet, but this still doesn't seem to
support multiple organizationalUnitNames.
I'm packing for an office move, before taking off for two weeks, so I
don't have my copy of X.500 convenient. Maybe someone with better
access to X.521 can help out here.
I'm confused. I thought I understood that the organizationUnitName
came under the organization, and that you could only have four of
them, but I can't find this definition anywhere. The Person object
class doesn't define a subsequent attribute set, but it seems to be as
ambiguous as Organizational Unit in defining whether or not you have
have multiple common names in a Distinguished Name (as opposed to an
RDN, which I understand you cannot).
The idea of at most 4 OUs under O is a confusion from X.400 O/R names.
I was confused about that when I started to work on this and it even
showed up in our first document on use of DNs in PEM.
I also can't find any definition of what constitutes an acceptable
definition for a distinguished attribute, as opposed to an attribute
which would be included in the content of an object but not in the
distinguished name.
I agree that the the Description attribute would be difficult, but not
impossible, to use as a direct search field, but not at all
unreasonable for use in browse mode (I'll recognize it when I see it.)
Many times I look up someone's name in the phone book and have to scan
a number of entries before I find the one I want, perhaps based on the
person's exchange code=city.
The concept of what constitues a "reasonable" distinguished attribute
is one that I have had explained to me by Marshall Rose and others who
are more expert on directory systems than I. A simple definition,
beyond what has alreday been said, may not appear in X.500.
Noentheless, I think if one remembers the role DNs play in organizing
the directory database, it becomes easier to develop a sense of what
does and does not make sense in this context. This is not just a
syntactic issue.
I'm not joking, for I've not been able to find a reference to the
IANA's full name in the RFC, so I don't know whether they exist or
not. Who are they, what is their charter, and what kind of progress
are they making?
The IANA (Internet Assigned Numbers Authority) is instantiated by Jon
Postel at USC-ISI. Sereval time a year Jon publishes the "official
numbers" RFC, listing assigned protocol IDs, well known port numbers,
etc.
I understand that you can't have multiple attributes of any
kind in an RDN, but that doesn't mean (to me) that you can't have
multiple attributes in a DN, a la OU.
That is correct, multiple instances of an attribute in different RDNs
is OK. I didn't realize I had said otherwise.
But let's ignore the possibility of using multiple versions of the
user's name, in the ordinary sense. What about
C=US, O=GTE Labs, CN=Robert R. Jueneman, CN=Emp. 123456.
I argue that the second CN is not intended as a second attribute
within the CN=Robert R. Jueneman RDN, but the second CN is
what actually defines the leaf. The immediate predecessor,
C=US, O=GTE Labs, CN= Robert R. Jueneman,
would also be a DN, but not a leaf node. I would propose that only one
certificate be generated, for the entire, complete, DN,
including the employee number.
If the last 2 CNs are in different RDNs, then I would expect to see
other nodes below the Robert R. Jueneman entry, distinguished by
employee number. But that is silly, i.e., there are not multiple
instances of you, distinguished by employee number (unless GTE is into
cloning in a big way).
Granted, I would prefer not to have to use something like
this, but the question is whether it would be considered valid within
the context of version 0 of PEM, or would it be better to use the
OU=Employee 123456 construct?
I'd rather we not talk about whether a DN is valid within PEM, because
one of the reasons for using DNs in PEM is because they have an
existance outside of PEM. Rather, the question should be whether a
given DN makes sense, period. I think the right answer for the sort
of example you have created is to have a separate attribute for ID
numbers assigned by organizations (e.g., employee or student ID #s)
and to have that attribute be part of the terminal RDN, along with the
CN) for those times when it is necessary to distinguish between two or
morre Robert Jueneman's, all of whom work for GTE.
Both seem to have significant disadvantages, and both are caused by
the same root problem, i.e., that the X.509 certificate is markedly
inadequate for the job that it is intended to serve, both within PEM
and elsewhere.
I'm not convinced that DNs are inadequate to serve as unique,
descriptive names for PEM. But, if we try to overlaod the name with
lots of authorization info, despite the fcat that these certificates
are primarily designed for identofication, not authorization, then
yes, they may come up short.
Steve