Bob,
Peter (Williams, not Churchyard) responded to your message and
I agree with many of his points, but let me provide my own responses.
I don't think that we know well enough at this time to say exactly
what attributes will be required for the various purposes for which
PEM may ultimately be used. I would therefore insist that the IANA
specify a MINIMUM required set of attributes necessary to support a
reasonable amount of interoperability, but that no constraints be
placed on an implementation that chooses to support additional
attributes. Instead, as the RFCs say currently, a compliant PEM UA
should be required to display any attribute type that it does not
understand as best it can, whether as a printable string or in hex.
In particular, PEM should not be limited to the set of attributes
specified in X.521, but should be guided more by the NIST stable
implementors agreements (at least for US use).
The intent in establishing an IANA list of approved attributes is to
enable a PEM UA to display a DN in a fashion that will be readily
understandable by the user. The hex fallback is an escape for UAs that
are not completely up to date. I recently had forwarded to me a note
from the last X.500 committee meeting which they reaffirmed that X.509
certificates are designed for identification in support of
authentication and that the inclusion of attributes to support other
security services was actively discouraged. I wholeheartedly agree with
this position and I think Peter was making a similar point. One can
imagine lots of applications in which additional attributes could be
useful, but PEM is a first and foremost an email security system and the
purpose of the certificates is to descripitively identify communicants.
Also, as Peter pointed out, we are operating in the international IP
environment, so the IANA is exactly the right registration authority for
these attributes. By the way, the OIS-DS WG has just issued a document
on how to structure naming schema that might prove helpful in our
discussion on what does and does not make a good distinguished
attribute. I have not yet read it but hope it will provide useful
guidance.
Point 2) is so judgemental in its nature that it conveys little
useful information. "Effective organization of a Directory
Information Tree" -- effective using whose particular
implementation? "as represented by a nominated set of competent
schema specifications" -- nominated by whom? Competent in whose
judgement? CCITT's? One or more PTTs? NIST? Individual Private
Directory Service Providers providing service to multiple users,
e.g., AT&T or GE Information Services, or perhaps GTE? Truely
Private Directory Servers Providers, such as IBM or the University
of Michigan?
The X.500 directory system is far from perfect and yet is painfully
flexible in many respects. However, constraints on how to effectively
organize the structure are dictated in part by the overall geopolitical
and organizational nature of the directory model and the fact that the
database is hierarchic, e.g., not relational. So, in fact, your
options for organization are not completely flexible. However, I think
this is somewhat of a digression.
Point 3) requires an "algorithmic relationship" between the DN
contained in the X.509 certificate and the DN of the X.500 entry.
Does this include subsets or supersets? In other words, can I
include multiple X.509 certificates in the entry for a given
"individual," perhaps to support multiple algorithms, different
uses, etc? Or must a lower level DN be created in the directory that
is equivalent to the DN of the certificate? Likewise, can I create
multiple entries under multiple directory DNs, each of which would
contain identical certificates? I should think so, in both cases.
Bob, the basic model is that a certificate stored in a directory entry
is a certificate for that entry, and thus will have exactly the DN
that uniquely identifies that entry. Yes, you could create object
classes with entries that hold other certificates as well, but the
pre-defined object calsses you find in X.500 follow a simple model for
which this question just doesn't make much sense. Note that different
entries have, by definition, different DNs. There is a one-to-one
correspondence here. (Well, alias entries have NO contents, including
certificates, they are just pointers to real entries with different
DNs, but I don't think that's what you had in mind.) The directory is
a database with a tree structure that determines the DN of each record
(entry). You can put lots of things in the records, but for common
types of entries (people, organizations, role in roganizations, CAs,
...) you would usually expect to find one certificate and it would
contain (in its subject field) the DN of the entry.
Example:
Suppose that the DN that is used to search the directory is
C=US,O=GTE,OU=GTE Labs,CN=Robert Jueneman. Can I create multiple
X.509 certificates and file them under that directory DN, including
one with C=US,O=GTE,OU=GTE Labs,CN=Robert Jueneman,Description="For
Personal and Confidential Mail Only"?
Likewise, suppose that I have a certificate containing a DN of
C=US,O=GTE,OU=GTE Labs,CN=Robert Jueneman. Is there any reason that
I cannot file that certificate under several directory DNs,
including C=US,O=GTE,OU=GTE Labs,CN=Robert R. Jueneman,Title=Mgr.,
Secure Systems, C=US,O=GTE,OU=GTE Labs,CN=Bob Jueneman, and
C=US,S=Massachusetts,L=Acton,Address=10 Stoneymeade Way, CN=Robert
Jueneman? (Note that these may or may not be aliases of each other,
for I may wish to associate different mailboxes, telephone numbers,
etc. with each one.)
You are using the ter, "alias" in a fashion not consistent with the
directory defintion of the term. The model presented in the directory
is that I noted above, so in general, no, you would not expect to put
these certificates in entries that have different DNs. I'm not saying
you could not do that, syntactically, or that the DSA would
necessarily check and reject such certificates. However, to the
extent the the directory expects to find a certificate in an entry for
its own use in authenticating a user in support of identity-based
access control, I think that many of your exmaples would result in
access being denied. Note that this is absed on your storing these
certificates in the attribute type defined for certificate storage in
X.521. If you want to make up new attributes for storing certificates
that is possible, but do try to understand the semantic implications
of doing so, not just the syntactic feasibility.
Many of these issues are presently being explored by the NADF and
individual service providers, and presumably by other such
organizations in other countries. I therefore think it would be
highly presumptious of the IETF to try to prejudge or foreclose
potentially useful attribute options and/or directory structure
conventions at this time.
The attributes that go into a DN are the subject of continuing work,
but, frankly, that work has not veered off in the directions you
advocate when you try to fit attributes into a certificate to support
authorization.
Instead, we should allow a relatively rich set of attributes, taking
into account the fact that many, perhaps most, PEM users may not
have access to a commercial-quality X.500 directory server for some
number of years. That should not hinder the deployment of PEM or
its use outside of an X.500 environment.
We have made a number of design decisions in PEM to accommodate the
dearth of DSAs in the world. Abandoning the naming principles that
underly X.500 does not help pave the way for folks to stroe
certificates in DSAs when they do become available. If anything, the
continuing discussion on this list about what attributes belong in a
DN make me thankful for directory schema, and wishful that more
stringent guidelines had been built into the base standard, instead of
waiting for profiles to emegre.
As users make up certificates which contain information which they
think is necessary or at least useful, they will find out from their
correspondents and/or their directory service provider whether those
attributes are understood or useful. The users will then be free to
negotiate with their directory service provider and/or PEM UA
provider for the support they feel they need, and that is how it
should be.
Making up certificates without an understanding of directory naming
principles, and a clear separation between naming and authorization
attributes, will almost certainly lead to chaos and it will definately
lead to structures that are not supportable in the global directory
system. I don't mean to suggest that X.500 is perfect, either as a
naming system or a directoy system. If you want to design a new
system for providing these facilities, be prepared for a long and
tedious series of discussions on a wide range of topics which have
only peripheral relevance to secure email. Don't plan on making any
progress on a wolrd wide certification system while the debate ensues.
Also, don't think that you can "change a little here and a little
there" and not undermine some of the directory concepts that are not
apparent if one focuses only on the syntax of names, rather than an
understaning of how directiory systems work.
Steve