I'm trying to digest this.
-- An RDN is a sequence of AVAs. (For comparison purposes, two RDNs are
considered equivalent if the same set of AVAs occur, irrespective of
order, and for this reason these are coded as "sets" in the ASN.1
syntax, but unfortunately the original order must be preserved for
presentation purposes.)
-- RDNs are further restricted to have no more than one occurrence of
any OID.
- - Each AVA is a pair consisting of an OID and a value. The OIDs must
be resgistered in advance, and associated with each OID is the
expected type of the value, a further restriction on the set of
legal values, e.g. printable characters only within values of type
string, and a rule for matching that determines whether two values
are considered equivalent
I think that what you have said is that a set of AVAs can be used to make
up a multi-valued RDN, so
C=US, O="GTE Labs",
{CN="Robert R. Jueneman" + Title="Mgr, Secure Systems" + Serial="22934"}
should be a legal DN for X.509 purposes, consisting of precisely 3 RDNs.
Is this correct?
Yes, that is my understanding.
(The question then is how many PEM implementations currently support such
a construct, and whether we interpret the RFCs to require such support.)
- - A distinguished name (dname or DN) is a sequence of relative
distinguished names (RDN).
Yes.
- - nested RDNs are not permitted in distinguished names.
Oh, no?!
I hope this is incorrect or that I am misreading you, for if I
understand you correctly this would imply that an organizationalRole
which includes a roleOccupant could not be an RDN, and therefore
could not be a part of a DN.
That is, my proposed DN
C=US, O=GTE Labs,
{CN="Chief Financial Officer" +
roleOccupant=
(C=US, O=GTE, CN="Frank Strouse" +
Title="Director, Finance and Administation" +
Serial=007)
}
would not be considered legal.
It's my pretty firm understanding that the structure for distinguished
names is not very general. Only two levels of structure are provided.
There is no provision for recursion or general nesting.
For simplicity, let's eliminate the multivalued RDN, and just consider the
following:
C=US, O=GTE Labs,
{CN="Chief Financial Officer" +
roleOccupant=(C=US, O=GTE, CN="Frank Strouse")
What's the role of the "+" symbol?
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.
This would have a significant impact on an approach to distinguishing the
degree of liability that should be associated with a digital signature that
we (Steve Dusse and George Parsons of RSA and I) are exploring.
I think it would also be a serious limitation on a number of business uses of
digital signatures in general, including PEM.
I haven't yet become convinced that certificates in their present form
are the right vehicle for this purpose. Certificates serve to bind
identities to keys. One can create other kinds of documents, a la
PKCS, to describe other things.
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.
I'm not the right one to do this.
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.
Are we really saying that this should be written and presented more like
(OID=Country, Value=US), (OID=Organization, Value="GTE Labs",
(OID=organizationalRole, Value="Chief Financial Officer") ?
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).
Bob