Steve,
I understand that you are catching up on a lot of back email,
and you may have skimmed over some of the discussion.
After lots of discussion as to whether or not a DN could contain
another DN, and how one could tell the difference between
a role name and a common name in an X.509 certificate if
roleOccupant is not specified, I came to several conclusions:
1. The organizationalRole concept within X.521 is either incomplete
or badly formed, and does not serve the purpose we have been
discussing. That is not to say that it may not serve a useful
purpose in a DIRECTORY. I could reasonably ask "Who are
all of the Purchasing Agents for Acme Corp?" But what we
need to know is what role a given individual is filling, and it
would be difficult to search through all of the organizational roles
to determine whether a given person has that particular role
(or others).
2. I am much closer to Tom Jones' thinking along these lines than I am
to yours. Whenever I think about an organizationalRole without
a roleOccupant being specified, the only example that comes to
mind is a little tag that says "These pajamas were inspected with
pride by Inspector # 7." If he had so much pride, why not sign
his name? Roles without occupants would seem to be useful only
for automata such as a trusted time server, and maybe not even then.
2. I concluded that what we need is something that is a lot closer
to Title in its syntax and semantics, i.e., an ATTRIBUTE, not an
object class, which denotes the particular role or function which
that individual is playing at that time. I agree with Tom here, also.
It is the INDIVIDUAL'S name that is of paramount importance with
respect to a SIGNATURE. Role based authorizations
performed by machines may be OK, and I can see the ANSI X9F1
certificates evolving in that direction, but if something is SIGNED,
I think the signature should be legible or the name printed
underneath, so I can identify the PERSON who signed it.
3. I don't have any problem with the use of additional attribute
certificates or authorization-granting certificates or Kerberos tickets
or capability-based tickets, etc. May their tribe increase, and may the
subject experts in those particular fields define the contents of those
certificates with excrutiating care so that we don't have the problems with
them that we presently have with X.509. BUT X.509 is all that we have
available at present, and we can't wait. PEM is beginning to proliferate,
and Apple's Open Collaboration Environment is expected to give rise to
requests for 1000's, perhaps 10,000's, of certificates per month. We
simply
don't have the luxury of waiting for CCITT or ANSI X9F1 to standardize
on another certificate format.
4. In offline discussions with Richard Ankney on this subject, he pointed out
that ECMA already has another "role" atribute, but that one is supposed
to be associated with a system or application, e.g., system administrator,
power user, guest, etc. He therefore suggested the attributes roleName
and agentName for the internal and external organizational role names,
respectively, with both having the same syntax as Title. We will review
and
discuss this notion at the ABA workshop on Notarization and Nonrepudiation
next week, but unless something changes drastically I believe it is his
intent to propose these two attributes at the OIW meeting to be held at
NIST in another week or two. I certainly endorse that position, and if we
cannot drive something like that through NIST I would be willing to
consider registering GTE with ANSI so we could register such an attribute
under our OID.
4. The use of the Title, roleName, agentName, and Serial attributes all involve
simple printable character strings, so issues of whether a DN can be a
component of an RDN won't arise. (BTW, I liked Tom Jone's observation
that roleOccupant is a PURPORTED DN, since even its existance, much
less its accuracy, is not confirmed by the directory.) Even if existing
PEM
implementations do not currently support these attributes (clearly they
won't
support roleName and agentName, since the attribute IDs haven't been
defined
yet), if they merely print the attribute ID in hex and display the
printable string,
the necessary information will be conveyed.
5. I hope that there won't be any serious issue with the use of a
multi-valued
RDN as part of a DN. This clearly seems preferable to adding additional
nodes to the DN just to convey the information necessary to disambiguate
the reference. Serial is necessary to distinguish between different
individuals
within the same organization, particularly over time. Title is clearly
important
in understanding who a person IS, at least in an organizational and even
in a
social sense. RoleName is almost exactly equivalent to Title in a
functional
or matrix management type of setting, and for individuals who are not
Managers
in the Personnel sense but may Project Managers in a functional
organization
the roleName may be even more important. And agentName is certainly very
important when dealings between companies, at least until EDI is
completely
matured and there are other types of certificates available to define
such
roles and priviliges more precisely.
We therefore plan to create certificates along the lines of:
C=US, O="GTE", OU="GTE Laboratories Incorporated",
{CN="Robert R. Jueneman" + Serial="22934" + Title="Mgr., Secure Systems"}
(The use of the curly braces and the + sign is intended to indicate that this
is a multi-valued RDN. I don't know what the actual presentation syntax will
be.)
We are in the process of coding this up using the PKCS version of TIPEM, and
will
have a PEM version when the new beta version of TIPEM arrives. Any volunteers
to
see what blows up?
Bob