Let me respond first to the concerns raised by Christian and Mike, then
look at some variations of my original suggestion that might get around
the concerns.
First, re DUAs. Yes, adding new attributes does present a problem in
that a DUA has trouble handling attributes of a type it does not know.
(It certainly cannot present a nice user interface for them.) In the
case of a CA entry, however, the set of genuinely affected DUAs is
maybe small, i.e., DUAs associated with PEM or other security
applications. Hence, maybe the problem is manageable. I feel one (sad
for some) truth is that DUAs will need to be able to cope with new
attributes for various reasons other than PEM (consider, for example,
the new attributes added in 1993 X.500 or by the NADF).
For a DSA performing name resolution, the new attribute should not be
an issue because if the name is in the local DSA, it will know the OID
and if it isn't it will have a knowledge reference at the appropriate
level of the RDN sequence (which may or may not be the point at which
the new attribute occurs). Of course, there may well be some DSA
implementations out there that cannot cope.
Is there a way to satisfy all the requirements without adding new
attribute types? Some possibilities come to mind:
1. We could have a convention that the last RDN in a CA's DN is always
a logical link back to an "associated node", which is the node on which
name subordination is based. (The form of the RDN could be anything,
e.g., OU= or CN=). This resolves the issue of permitting multiple CAs
and the issue of having a separate directory entry for the CA and the
real org/org-unit/etc. It lacks the niceness of being able to simply
identify any certificate as being signed by a PCA, CA, or user. It
also would not be distinguishable from the current PEM convention,
so migration looks like a problem.
2. We could invent a name convention using only X.520 attributes.
Christian suggested special values for OU but, because of the
widespread use of OU, I am not sure this adds anything over 1.
above. Another approach would be to select an attribute that is not in
actual use in PEM today. What about "title" or "serial number"? For
example, a CA name associated with an organization could be "C=US/
O=Northern Telecom/ Title=CA Number 1/". Assuming (?) noone currently
has a CA name that includes a title attribute, this would at least give
a migration path.
Perhaps reserved name value components will help but I share Bob's
dislike of such an approach.
Any other ideas?
Warwick Ford
??????