C=US, O=GTE Labs,
{CN="Chief Financial Officer" +
roleOccupant=(C=US, O=GTE, CN="Frank Strouse")}
Without this capability, I don't see how we can use the organizationalRole
at all, since there doesn't seem to be any way of distinguishing between
a person's common name and the name of the organizationalRole.
The easiest way is through the objectClass attribute, which would declare the
entry to be a "person","organizationalRole", something else, or some
combination of these.
Can you lead me through this line of reasoning slowly and patiently, citing
chapter and verse of X.500 (88 or 93)? Hopefully it is a misunderstanding
on my part of what you are saying.
X.501(93) 8.3 seems to say "A single value instance of any attribute type may
form part of the RDN, depending on the nature of the object class denoted.".
DN's have equality matching, so they should be usable as value instances.
If this is refined elsewhere to restrict certain values from being in RDNs,
I'd like to see this - some other things I'm working on put attribute sets and
DNs into attributes, and these attributes might be used for naming.
It occurs to me that perhaps my problem is that I have been looking
at some pseudo-syntactical descriptions of what is in the certificate, and
not looking at the way these entries are actually encoded.
Syntactically DNs are just a list of a set of pairs. The pair is (type,value):
an object identifier for the attribute, as seen in X.520
an ASN.1 'ANY', which could for instance be the encoding of another DN
The encoding rules follow this syntax.
The AVA asserts that the (type,value) pair is present in the entry. It doesn't
(and shouldn't) assert that this is the only value present for that type.
Unfortunately, organizationalRole is an object class, not an attribute type,
so unless a new OID is defined we couldn't do this at present, correct?
And even more unfortunately, as I understand it, the OID that is supposed to
be used for the value of the organizational role is Common Name. So unless
we can include the roleOccupant OID, I don't think we can distinguish between
an organizational role and an ordinary employee (organizational person).
You're right, this is incorrect. I don't think it'd be a good idea to make
a new attribute type for commonNameWhenThisIsAnOrganizationalRole.
With an X.500 Directory present, the entry is just read and the DSA returns
the objectClass values.
If there isn't an X.500 Directory present, hacks could be employed in the
meanwhile. Here is a hack that would allow this to work, but it looks too
ugly.
{cn="Chief Financial Officer" + objectClass=organizationalRole +
roleOccupant={cn="Frank Strouse",o="GTE Labs",c=US}},o=GTE Labs,c=US
The above purported DN asserts that at the level directly underneath
o=GTE Labs,c=US there is an entry which has the following attribute values
distinguished:
objectClass=organizationalRole
cn="Chief Financial Officer"
roleOccupant={cn="Frank Strouse",o="GTE Labs",c=US}
If this were held in X.500, there'd probably be some other attributes as well,
perhaps cn=CFO or even roleOccupant={cn="Robert Jueneman",o="GTE Labs",c=US}.
[Frank Strouse's entry could be present or absent from the Directory - it's
presence is never asserted or denied. The roleOccupant attribute value is a
purported DN (X.501(93) 8.2).]
-------------------------------------
Mark Wahl; M(_dot_)Wahl(_at_)isode(_dot_)com; ISODE Consortium