Rhys,
I'd like to continue discussing some of the naming issues
you have raised.
I am sympathetic to your concern regarding your
administratator's (perceived) reluctance to get involved
in assigning distinguished names, particularly before
the benefits of the use of PEM or whatever other PKC
technology are clearly demonstrated.
This is a chicken and egg problem that is a little hard
to overcome. I may have even added to the problem,
by raising concerns about the potential liability
implications of using a name. And you have pointed
out how people are sensitive to usage of certain
legal forms, e.g., _The_ University of Queensland.
I'm in the process of writing a "CA Guidelines for
Name Registration" document as part of the ABA
committee I am working with. I hadn't specifically
planned to do so, but with a little editing I could
probably submit this as an Internet draft or RFC,
if you think that would be of any help.
In the meantime, let me offer some simple, pragmatic
suggestions for your use/criticism:
The NADF standing documents (available via
anonymous FTP from host ftp.ics.uci.edu,
area mrose/nadf/, files sd-*.ps, mode ascii;
or via e-mail to archie-server(_at_)ftp(_dot_)ics(_dot_)uci(_dot_)edu,
with body part send mrose/nadf/sd-*.ps),
in particular SD-5, "An X.500 Naming Scheme for
National DIT Subtrees" and SD-6 "Guidelines
on Naming and Subtrees," may provide some
useful information. Granted they are intended for US
and Canada, but the problems are pretty generic.
In particular, the issue of "Flat" vs. "Deep"
hierarchies is discussed in SD-6, section 3.3 and 4.
Case studies involving Virginia Polytechnic Institute
(Virginia Tech), Duke University, and Portland State
University are discussed. Virginia Tech uses a very
hierarchical organization with 21,000 students and
1700 faculty divided into 9 schools and over 600
departments and departmental units. Duke, on the other
hand, has 10,000 students and 1500 faculty,
all listed under O=Duke University, CN=<name>.
Portland is somewhere in the middle, with
three OUs defined under O=Portland State University,
OU=Faculty and Staff, OU=Students, and OU=Computing
Services.
Of the three approaches, I tend to favor the one used
by Portland State University, although one of the purposes
of the pilot is to gain experience in using different kinds of
structures.
With respect to the DN that is used in a certificate,
there doesn't seem to be any particular need
capture all of the information that might be contained on
a business card, and consideration should be given to
interdepartmental transfers of students and/or faculty.
(This may be less of a problem for a university than for
a corporation.) On the other hand, the point raised by
Steve Crocker concerned the alleged Robert Bork
is valid -- the more information that is provided, the better
chance we have of making an informed judgment about
someone we may know by reputation, but not in person.
As I understand Steve Kent's plans within BBN, he intends
to set up a rather flat hierarchy that would include
O=BBN, OU=Employee, CN=<name>. That type of scheme
would also work for GTE Labs, which is of modest size
(less than 500 employees). This kind of structure
would allow OU=Resident Visitor, OU=Guest, OU=Contractor,
etc., with some implications as to trust.
Such a scheme might not be such a good idea for the
University of Michigan, which has something on the order
of 100,000 students. There it may be more appropriate
to organize students into colleges, or perhaps by campus
and then college. But OU=Freshman, etc., would probably
be the worst approach, because of the instability that
would introduce each year.
But these are nice problems to have to solve, after an
organization has made a decision to go forward on such a
basis. In the meantime, you may want to just pick a name
and try using it.
Without being too disingenuous, unless your institution
has a rule or a policy that effecively says that everything
that is not specifically allowed is forbidden, maybe you
should just try it, and see what happens. You could always
claim ignorance! :-)
One last possibility that might help to get you going
immediately is to use the RSA Persona Certification
Email Responder. If you missed the 2/11 message from Steve
Dusse announcing the Low Assurance Hierarchy Policy,
the text is available via anonymous FTP to rsa.com,
in the pub/low_assurance_pca directory.
The advantages of the Persona CA are that:
1. It's free.
2. No one is going to question you about the form of the
name on a Persona certificate, so if you say
C=US, O=RSA Data Security, Inc.,
OU=Persona Certificate,
CN="Weatherley, Rhys <rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>"
no one is going to quibble.
In fact, you could try to outdo Peter Williams, and say
something like
C=US, O=RSA Data Security, Inc.,
OU=Persona Certificate,
CN="CN=Rhys Weatherley,
OU=Faculty of Information Technology,
O=Queensland University of Technology,
L=Brisbane,
C=AU,
RM=<rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>"
3. It's free.
4. It should not require any changes to _anything_ to make
it work.
5. It's free.
6. It works via a responder, so the response should be
almost immediate.
7. It's free.
8. No one is going to try to hold you liable for something
that was signed using a Persona certificate, so there
is a very low risk.
9. It's free!
What a deal!
Your only problem would seem to be that you will have to
scan for the RM, rather than having a specific attribute
jump out at you, but that is the price you pay for the
convenience of not having to change PEM (or X.500).
Bob