Steve,
Let me respond to several of your messages together.
- Yes, one could encode an employee's ID number in the serial
number field if these numbers are guaranteed to be unique.
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.
- The name in a certificate is a DN, and some of the other
attributes you note in your message seem unlikely to be distinguished
attributes in most people's idea of appropriate schema. The problem
Bob has is that he is trying to add attributes to the certificate to
provide useful information from a security standpoint, but these
attributes are not appropriate as distinguished attributes from an
X.500 standpoint.
(later)> One needs to look at more than just X.509 and X.520 (attribute
types) to understand what constitiutes a valid DN, as I noted in my
previuous message this morning. In particular, look at X.521 (object
classes) to get a feel for what combinations of attributes are
generally considered to make sense for different types of entities.
RFC 1422 provides high level guidance ( a "muddle of ideas" in your
words) because it was felt that the PEM WG was an inappropriate forum
in which to establish directory schema. If you are familiar with
earlier versions of the PEM RFCs you will note that we explicitly cut
back on the constraints imposed on DNs in certificates for use with
PEM.
(still later)>Description is clearly an attribute that is not intended to be
distinguished. I think if you re-read the sections of X.500 about
naming you can see why this would be a silly attribute to be
distinguished. So, it does not belong in a certificate subject or
issuer field.
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"?
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 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).
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.
Finally, re your earlier message, no, the IANA has not
established the "common attribute" list yet, something that was
agreede upon by the PEM and directory WGs. However, I assume you must
be joking when you ask if there IS an IANA.
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?
(earlier)>You cannot put multiple CNs into a single RDN; that is prohibited
under the X.500 rule that prohibits ANY attribute from appearing
multiples times within a single RDN. Thus multiple CNs must appear at
different levels. Think about what this means. Imagine a DN
terminating a leaf that is distinguished by one CN attribute (C=US, O=
GTE, S=MA, OU= Laboratory, CN= Robert Jueneman). Now consider adding
on other CN attributes below this one, to accommodate all those other
names you illustrated. That doesn't sound right to me in most
instances. Also, it yields multiple entries, each of which can have
its own certificate, but you can't have one certificate for all of
those entries.
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.
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.
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?
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.
Steve>P.S. The concerns Bob Jueneman raises about binding info into names
in certificates would be even more difficult to address if we had to
use DNS names, since they don't have attribute tags, are more limited
in size and characterset, ...
On that point I am absolutely in agreement. That is one concern I have
about the COST PCA, which proposes to do just that.