John,
[What follows is a justification for a proposed new X.509 certificate format.
Those who only want to know what, rather than why, can skip to the
next message.]
Your message was short and to the point, and I think I can respond
to it and make some of my points more cogently than if I tried to
respond to Steve Crocker's reply first.
You presented a good argument for the use of a Directory in
general, and I agree with you on most of them. But I want to draw
some finer distinctions in a few cases.
Here is the vision, the architecture, what is desired as opposed
to what is available ...
1) All mail recipients are addressed solely by their DN except
when all other means of contact have failed. The MTA
performs directory lookups to find the ORAddress. Distributions
lists consist of a single DN.
a) I can now change my ORAddress when I need to, even
for the weekend or vacation period so that mail can
be sent to my location or secretary.
b) I can change affiliation (BBN to GTE for example) and not
change my DN but only my ORAddress.
So far, I certainly agree. Assuming that a DN is at least relatively stable and
not
unnecessarily over-constrained or over-specified, we should be able to use the
Directory to access the latest information. Regarding your para (b), however,
I would agree ONLY if your DN were that of a residential person, not an
organizational
person, and you just found it more convenient to read your mail via your
terminal
at work than to log on to CompuServe, for example. If I am sending encrypted
mail to someone, or carrying out that person's request, I would certainly want
to know
if that person changed employeers, for that might signficantly affect my
decision.
2) All my public key certificates are present in my Directory entry.
These include my SDNS, Mosaic, PEM, and foomail certificates.
Anyone who needs to communicate with me securely can find
a certificate to match their needs.
I certainly agree. I occasionally wonder how we will match up the right kind of
certificate with the appropriate algorithm/e-mail package, but presumably that
can
eventually be handled by negotiation with a smart UA.
3) Anyone needing to, can VALIDATE my certificates because since the
DN of the CAs was used in the X.509 certificates, they can
obtain
the necessary certificate and associated CRL from the CA's
directory
entry.
Ah ha! Good point, and one that I had neglected so far. In fact, certificates
contain
TWO DNs, one for the user, and one for the CA. In all of my comments over the
last
several days, I was only thinking about the DN of the user. The DN for the CA is
generally much more straight forward.
Actually, you have three points in that paragraph. The second is that you can
obtain
the certificate of the CA from the directory, and the third is that you could
obtain the
CA's CRL from the directory as well. Of course, we have alternate methods of
doing both, such as including the certificate in the message itself (admitedly
undesirable in the long run, and obtaining the CRLs from my PCA (may be faster
and
cheaper than from the Directory, but who knows?)
4) Those desiring to can also fetch and validate any AUTHORIZATION
information and validate that information because they have
my DN. (a la X9.30 perhaps) Note that X9.30 also uses DNs ...
This is an interesting point. Your assumption is that any authorization
certificates
would be independent of the identification certificate (X.509), and that both
would
be needed. That isn't particularly obvious to me, since any authorization
certificate
would almost surely include the user's name, probably in DN format.
5) Since the Directory is global, anyone on the planet can fetch
my certificate and engage in secure communication with me.>
Yes.
But notice that only your point 4 dealt with the specific question of whether,
and why,
the content of the user-level information in an X.509 certificate has to be in
the
particular format of a X.500 Distinguished Name (as opposed to a less structured
conglomeration of potentially useful information), and what the relationship
should be
between that information and the structure and content of the Directory tree.
In particular, if we were to adopt the parochial view that only PEM mattered,
rather than a more general public-key infrastructure, we would come to the
conclusion that the the only reason why we have a DN in the X.509 certificate is
to support attribute certificates which PEM doesn't support!!!
Let's consider the information that we would like to have associated with a user
in the certificate, then discuss the syntax of the various elements,
and finally the schema by which certain elements are allowed to inter-relate.
First the content:
1. If we assume a relatively high-assurance PCA domain for messages, mail, and
other
applications that are intended for business purposes, then at least the kind of
information that is normally included on a business card should be included. If
we are to be reasonably sure that the name is globally unique, then various
elements
of the name should be qualified by either geopolitical boundaries or by
organizational
scope, or both. Because I may wish to validate the origin of a message some
length
of time after it was sent, we should include some means of making sure that an
individual's name is qualified with something like a monotonically increasing
employee
ID or serial. IN the case of a residential person, again assuming a business
context,
I would want to know the state, locality, and street address, so that I can
physically
locate him if necessary.
2. If, on the other hand, we want a system primarily to support privacy, with
authentication limited to simple attribution, then a much more casual approach
could be taken. In particular, an Internet e-mail address satisfies the global
uniqueness
criteria that is the essence of the requirement for a Distinguished Name. It
isn't very
descriptive, especially if it is something like
123456(_at_)Compuserve(_dot_)com(_dot_) But it
can be fully qualified and unique. To skip ahead a bit, it would also satisfy
the
DIT schema and structure requirements, but only if the Internet address domain
were registered at the root of the ITU DIT. This approach would certainly
suffice
for Persona certificates, and perhaps for some medium assurance system.
If a common name were desired, the little endian format would be
CN="Bob Jueneman", internetEmailAddress="Jueneman(_at_)GTE(_dot_)COM"
(I'm not going to dwell on this point, but since the certificate is signed, the
CA
would presumably be responsible for at least some level of diligence in
verifying that
I "owned" that mailbox. How much diligence is a function of the PCA's policy.)
Next let's consider the syntax of the various elements.
If we are to have a multiplicity of different kinds of addressing information,
it
would certainly be nice to know the syntax and perhaps the semantics associated
with each different kind of element. This implies the need for an ASN.1
syntactical
description of the element, together with a unique OID so that it is possible to
differentiate between a postalCode and the continuation of a streetAddress.
This will facilitate sorting and searching, and a more user friendly display.
In addition, in some cases it will be useful to impose or derive a sequence
for the various elements or attribute values, if only to indicate the preferred
sequence when displaying the information. Thus the country code comes first,
then the state or province, then the locality, then the street address, and
last the
common name. However, the telephone number, FAX number, cellular or
beepe number, Internet e-mail address, public-key, etc. do not have to be
presented in any particular order, and IF we were to deal with various
authorization
attributes, it isn't clear that they would have to be ordered either.
Finally, let's consider the structure and the schema that should be applied to
this
informatin. If only to prevent errors, it would be nice to support some kinds
of
information type checking, so that someone doesn't specify Country as being
subordinate to street address, etc.
However, this now has to take into account the specific Directory Information
Tree
structure(s) and schema(s) being considered by the various Directory Service
Providers. Even at a national level, where there may be multiple Administrative
Management Domains (e.g., AT&T, MCI, Sprint, and perhaps CompuServe, Prodigy,
Cellular One, and GE Information Sevices), it is not clear exactly how this
structure and schema will evolve over time. At an international level, the
situation is even less clear. Perhaps the NADF will coordinate
all of the various ADMDs within North America, but what the Bundespost might
decide to do is another matter.
If I am using the terminolgy of X.500 '93 correctly, some of the various
attributes
we might like to use will fall into the category of structural object classes,
and
others will be considered auxiliary object classes. Only structural object
classes
may be used to define names within the DIT, and the structure rules will define
which attributes may be superior or inferior to other attributes.
Unfortunately, at least as I understand it, we don't have a complete list of all
of the structural object class attributes, and at least some, such as roleName,
are not yet internationally standardized.
Now to get to the heart of my argument. I am assuming that when X.509 says
that the certificate contains the user's DN (and the issuer, but that is a
separate
matter), the meaning of that statement is defined by the second paragraph of
section 9.2 of X.501 ("93):
"An object can be assigned a distinguished name without being represented by
an entry in the Directory, but this name is then the name is object entry would
have
had were it represented in the Directory."
The implication, therefore, is that all of the structure rules and schema that
will
eventually apply to names that are entered into the DIT would apply to the
DN that is listed the certificate.
This, in turn, implies that information that may be useful and probably ought
to
be signed, including descriptive attributes (5' 2", eyes of blue), roleNames
(United Way Coordinator, Purchasing Agent, CFO, etc.), or even e-mail
addresses cannot be included in the DN as presently defined, because
those attributes are not of the structural object class and are not appropriate
for the DIT.
That is how I interpret the specification, so if I'm incorrect it would
invalidate some
of the rest of my argument.
But I am suggesting that there an urgent requirement to include information
that may
not ultimately go into the DIT, in particular the e-mail address and perhaps
some
role information, without the DN that is being used to look up additional
information
(enventually - when X.500 is up and running with X.509 certificates and CRLs)
being overconstrained or in violation of the structure rules.
For the benefit of those who may not have waded through all of the reasons
why, I will post a proposed syntax for the new certificate type in the next
message.
Bob