Steve,
I said:
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.
You replied:
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
i>nstances of you, distinguished by employee number (unless GTE is into
cloning in a big way).
I need to clone myself, just to handle all the email recently and still
get some other (less useful/more useful?) work done.
But remember that I originally brought this up in the context of "eternal"
DNs. I know of a dozen or so Juenemans in various cities in the US,
but no other Robert R.'s. But what if my name were Jones or Smith
(or Chao or Chang or Schmidt)? I checked the GTEL phone book, which
contains about 500 names, and found two Oscar Lee's (distinguished
by a middle initial) and two Maureen Sullivan's (no distinction except
their organization).
Obviously an employee number isn't much help if you are trying to
send email to someone and cna;t tell which one is which. But
if you are trying to determine who signed a particular purchase
request, or whether someone is authorized to change a particular
W4 form, etc., employee number is a perfectly good DN attribute.
The question is how to encode it in the existing directory scheme.
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
more Robert Jueneman's, all of whom work for GTE.
I'm not sure I understand what you mean. Can GTE, as Tom Jones
suggested, register its name under ANSI as an organization, and define
its own attributes? It appears that is the case, particularly if we were to
become a directory services provider. If so, then presumably that attribute
could be used as a distinguished attribute, and thereby become a part of
a DN?
What happens when other PEM implementations that have never hear of
this attribute receive my certificate? Is this specified somewhere in the RFCs
and I missed it? (For that matter, how do we handle backward compatibility
when we eventually migrate to X.500 1993?)
Take your terminal with you when you go to the beach, or wherever,
but try not to get sand in it. :-)
Bob