Steve,
To follow up on the previous message, it occurs to me that the current
RFCs may have gone in the wrong direction as far as avoiding definitions
ofthe various mandatory/allowable attributes in DNs, etc.
Although GTE is not yet a member of the NADF, we are considering
joining just to help understand all these issues and to try to evolve a
a common format, whether or not we ever become involved in providing
an X.500 directory service. But even if the PEM community were
to mandate the use of whatever the NADF comes up with on a worldwide
basis (and we surely couldn't), it will almost surely be too little, too late
for the current crop of PEM implementors and users.
In addition, as I understand it, there is so far very little attempt to
define a common worldwide directory schema. The various PTTs will
almost surely define whatever they like to fit their particular view
of their customer's needs, and the various private organizations
(some of which will undoubtedly be much more oriented towards
distributed computing and DCE-like concepts than traditional POTS
and X.400 telecommunications) may define their own views as well.
In the meantime, PEM has staked out an international role for itself that
is less ambitious but more immediately useful than the grand scheme of
a fully integrated global X.500 directory. PEM should properly be compatible
with X.500, (at least to the extent that we can determine what that means)
but it is not and should not be dependent upon it.
In particular, we absolutely cannot wait for a concensus to emerge as to
what style of Distinguished Names, what attributes, etc., can be used for
what purposes before we can start using PEM. And I would submit,
based on the last few days worth of email, that we are far from having a
universal understanding as to how to encode even relatively simple
constructs into a PEM certificate.
I would therefore suggest that we either:
1. Role back some of the changes to RFC 1422 to their previous
contents, and try to define a common set of DN attributes, numbers
of allowable subattributes such as OUs, etc., or,
2. Begin writing yet another RFC that would serve as a stable
implementor's agreement as to what attributes must be supported,
what are recommended, and how to display attributes that
one implementation may support but another may not.
I hate to make the existing code become the standard, but maybe
we are at that point. Hence my various questions as to what the
different implementations support, or at least think they support.
If I put on my user's hat, I could care less about strict X.500 compatibility
right now, because the certificates we will be generating will only
last for a year, and it is fairly unlikely that we will have a distributed
X.500 database that is integrated with the rest of the world before then.
Compatibility with an as yet undefined national or global directory schema is
even less important, at least for the next year or so.
As far as I am concerned, I am more than willing to defer to your technical
judgment in these particular areas. I certainly don't have the time or the
desire to become a subject matter expert on these issues. In addition,
you seem to be at least reasonably sympathetic to what I am trying to
accomplish.
So I encourage you to go ahead and speak ex cathedra on these issues,
but please, do so from the standpoint of articulating here-and-now
engineering solutions to these problems and not just theoretical
concerns, as Pete Churchyard has suggested. I reserve the right to
argue, but ultimately I just want someone to make some decisions so
we can get on with the show.
To reiterate the problem, I think we need to:
1. Address the issue of incorporating some sort of a Disclaimer attribute
somewhere in the DN, where it will be bound to the user's public key
by the CA.
2. Address the issue of providing some sort of an employee number
qualification in the DN in the event that, over time, two individuals
have the same name within the same organization.
I suspect that there are issues of having named individuals as role
occupants and/or using titles to identity individuals who can pehaps
be presumed to be able to perform certain functions, although I am
somewhat uncomfortable about the "push" access control implications
of this and need to think some more about it. I don't want to try to
define what a "Manager" does, much less try to encode it within an
X.509 certificate, but I would like to know that whatever those privileges
are, this person has them.
Bob
P.S. Is there an overall plan as to when and how PEM should adopt
the 1993 version of X.500, once it becomes official?