Here's my original message to Tom and Bob. Recall that earlier versions
of RFC 1422 went into great detail on name formats, but recent versions
leave that ambiguous, since the issue really is outside the scope of PEM.
This message contains one modification, recognizing that the role occupant
attribute has a syntax of DN, not PrintableString. This makes it a little
more kludgy than in my original message, and violates the suggestion
that only attributes with printable representations be used (although
implementations will be able to parse DNs into printable form anyway).
The NADF is one group that is defining the naming hierarchy for the US
and Canada. (ISO 9834-1 specifically delegates the naming authority to
each country, and the common carriers in the US and Canada formed the
NADF to do this.) They don't make any recommendations on name forms
within an organization.
Recall that there is nothing to prevent us from defining our own attributes
if we can't define useful names with what's in X.520. That's the approach
used in my first two suggestions.
Regards,
Rich
-----------------------------------------------------------------
Tom,
Those were great suggestions about using existing X.520 attributes for
various purposes. I've become too fixated on the 1993 drafts, which
indicate (using NAME-BINDING macros) exactly what attributes are used
to name each type of entry. To fill you in on the background, here's
an extract from my original message to Bob about roles:
There is no apparent way, given the naming attributes etc. in X.500,
to distinguish between a person and a role on the basis of just the DN.
Both types of object are named by the common name attribute. So the
following name a role and person respectively.
C=US; O=Acme Corp.; OU=Purchasing; CN=Purchasing Agent
C=US; O=Acme Corp.; OU=Purchasing; CN=R.K. Maroon
In a real X.500 directory, one would read the entry and examine it's
object class attribute to determine if it is a role or a person. A
role entry contains a multi-valued attribute called "role occupant"
which lists the DNs of the persons with that role. (This obviously
requires a high degree of trust in the Directory to not falsify this
information; the new X9F1 drafts suggest that the role occupant
attribute be carried in an attribute certificate signed by the CA.)
There are several possibilities to get around this:
1. Name roles with a new attribute called e.g. "role name" with the
same syntax as common name, leading to:
C=US; O=Acme Corp.; OU=Purchasing; RN=Purchasing Agent
C=US; O=Acme Corp.; OU=Purchasing; CN=R.K. Maroon
2. Add a role name attribute to the user's DN:
C=US; O=Acme Corp.; OU=Purchasing; {CN=R.K. Maroon; R=Purch. Agent}
3. Don't worry about it. The CA will ensure that extra security is
provided for organizational roles [...]
So one could also use something like this to indicate a role:
C=US; O=Acme Corp.; OU=Purchasing; CN=Purchasing Agent;
RO=C=US;O=Acme Corp; R.K. Maroon <-- changed
The problem with our use of X.500 DNs, of course, is that in X.500,
much of this information is carried in the actual directory entry,
so the DN only names the entry uniquely. But one would need a trusted
directory in order to rely on it to convey role information in this
case. The X9F1 attribute certificates sort of provide this kind of
capability.
A little thought will be required when moving to a real directory,
if the DNs contain these "non-naming" attributes. But of course,
certificates expire periodically anyway.
[ Stuff on UIDs, ISO and X9.30 etc. deleted... ]