Steve, Theodore, Peter, Donald, Carl, Steve, Tom, Anish, Christian, John,
Russ, Ned, William, et al:
It must be late on a Friday afternoon, for this thread is going downhill
rapidly! Before we all go totally bonkers, let's see if we can restore a
semblence of sanity and reason to the discussion.
Yes, Steve Crocker, I agree that there are some very serious problems
with the current structure of X.509, in particular its inability to handle
any user-related attributes except by stuffing them into a DN.
Yes, Christian and others, I will accept that there may be serious
difficulties with the existing IMPLEMENTATIONS of X.500, and in
particular the alleged difficulty of adding attributes to the structure,
conveniently and globally. In particular, I accept that adding attributes
which are supposed to be used as a part of a DN may continue to
be troublesome, becasue it impacts the directory schema. (I take this
on faith, having no personal experience in trying to do so.)
No, EMPHATICALLY NO, Steve Crocker, I do NOT agree that we should
even consider the use of Internet e-mail names in place of some form
of distinguished name in the X.509 certificate, at least if we every hope
to have this system grow up and be useful for something more than
adolescents to use to communicate their private giggles and conspiracies
securely across the Internet.
That does NOT mean that I think we should accept the limitations imposed
by the current X.520 attributes, attribute syntax definitions, and
directory schema. We need to do our thing, and let the X.500 people
do their thing, and hopefully we will eventually converge. But one of the
primary reasons for having layered architectures to to avoid having to
change everything all at once, for that becomes impossible.
I have been consistant (to the point of being irritatingly dogmatic, I'm sure)
in urging two desiderata for naming criteria for digital signature certificates:
1. The names created, assigned, or "discovered" must be sufficiently well-
qualified by geopolitical, organizational, or other implicit or explicit
"naming authorities" as to ensure that the entity that is so named
is unambiguously identified. (Note that unambiguously identified
does not mean uniquely identified, for individuals will typically have
multiple names that are distinct, but which refer to the same
metaphysical person, but perhaps in different locations or in different
roles. Naming is generally a many-to-one mapping.)
2. The distinguished names that are so created should contain a sufficient
amount of physical universe descriptive information as to allow
the legal service of process against that person to compel performance or
seek redress, at least if this distinguished name is to be used in a
certificate
is to be used for any nontrivial purpose. In plain language, I want to
know where to send the sheriff if I need to sue you. I can't send the
the posse out into cyberspace, for the Force be not with me. And I
don't want to have to subpoena the records of CompuServe, etc.,
to find this information, for I think that would cause more privacy harm
than social good.
Over and above those two requirements, it would be "nice" if the DN were
more or less human readable and not deliberately misleading, but that
is primarily a UA presentation function.
Further, because the more positively you attribute an utterance to me,
the more difficult time I (or my company) may have in repudiating
something that I might wish that I hadn't said or wasn't authorized to say,
I would like to have some means (PCA policy statment or caveat in the
certificate) of saying what I agree to be bound to and what is considered
to be excessive -- like requiring two signatures on a check for more than $1000.
Those authorization and/or caveat attributes are absolutely going to be
required, probably sooner than later, if digital signatures are going to
take off in any meaningful way, IMHO. However, although those attributes
need to be included in the certificate so that they can be signed by
a Certification Authority as being authorized, they DO NOT need to be,
and probably shouldn't be, included in the Distinguished Name, except
as necessary to uniquely identify a title or role.
Similarly, in order to help cope with the problem of readily distinguishing
between two sufficiently well-qualified but insufficiently descriptive DN,
it would be quite useful to add additional information, e.g., the 5' 2" good
looking blond, or the Bob Jueneman who is NOT the horse thief, to
the information in the directory, and potentially to the certificate, but as
attributes that are not part of the DN.
Finally, no one has yet advanced a compelling argument as to why
the most useful content of the X.509 has to be in Distinguished Name format
in any case, nor what the correlation should be between that DN and the DN
(any DN) in the X.500 directory itself. No other X.500 attribute that I am aware
of contains a DN itself (except for the obvious cases of aliases and seeAlsos,
etc.), so this seems rather strange.
Granted that it may be useful to impose an OID structure and ASN.1 syntax
description on the elements of the name contained within the certificate,
so that we can easily tell the difference between an organization name
and a street address, why does the name in the certificate have to be a
DISTINGUISHED name? (I am assuming that it is generally desirable
if not required for a DN to define a minimal spanning tree, rather than being
burdened with unnecessary leaf nodes. But this is not necessarily true
for the information content of a certificate.)
Note that my desiderata didn't say anything at all about whether you could use
this information to send electronic mail to that person. That might be a happy
coincidence, and I would have no objection to incuding the users X.400
address, Internet address, CompuServe account, or even his Swiss bank
account number as additional attributes in the certificate, but that information
is not needed in the DN. (The only reason for including this information in
the certificate would be for the convenience of retrieving that auxiliary
information from the archive, and also to allow the CA to confirm the
accuracy of the information. Or if X.500 never comes to fruition and we use
a database of certificates in lieu of X.500.)
Instead, I assume that a user's UA will keep a short address book of nicknames
that are referenced frequently, and a somewhat longer list of less than fully
qualified names of correspondents, and that BOTH of these lists will reference
that correspondent's fully qualified DN in the directory to find the latest
information available. (Not routing information, for the Directory aways
returns
the same information regardless of the source of the inquiry (neglecting
synchronization problems) and therefore isn't well suited for containing
routing information.)
(Many uses of the certificate infrastructure won't make use of e-mail at
all. They might use sockets or other protocols like DCE, or just be used
to sign programs distributed on CD-ROM as a means of authenticating them.)
If X.500 weren't available, the user could equally well keep this information
in
any kind of a database he chooses to use. It just becomes a little harder to
look up people he hasn't corresponded with so far, but we have that problem
now. And at least in the e-mail environment you can include your certificate
in your first signed message, and your correspondent can do the same,
and so you never need a global directory at all - just a local cache.
SO:
If anyone is still in the mood to even consider the kinds of drastic changes
that have been proposed in this recent thread, I'll make my suggestion:
RESOLVED, that the PEM community should unilaterally take steps to
suitably enhance the current X.509 certificate, perhaps calling it X.509 V3
to distinguish it from the 1993 version (V2), and establish that certificate
as the initial de facto standard for a national public-key infrastructure.
If X.500 adopts it in the 1996 version, all will be well and good. If they
don't,
we will just have yet another attribute that was not defined in X.520 to
add to the stack, along with ANSI X9F1, X12, authorization certificates,
etc. In any case, it should be no more difficult to disseminate this kind of a
certificate via an X.500 directory server than it will any other kind of
attribute
like the QUIPU "Favorite Drink" attribute. And if by 1996 it is still that
difficult
to add attributes to X.500, the entire directory structure will collapse and
we'll
start using some other kind of system, such as GOPHER.
The key to this entire proposal is to have the ability to sign information
(attributes) that are contained in a certificate without having to add those
attributes to the DN itself. Thus, Warwick Ford's caName attribute would
NOT be in the DN, but would be signed. I haven't thought through all of
the name subordination requirements, but I suspect that they shouldn't
be impacted too much.
By now I'm sure that Steve Kent has set up the stake, laid the kindling,
found his lighter fluid and Zippo, and is looking for rope. As they say at
the start of the Olympics, "Let the flames begin!"
Q. When did the British burn Washington?
A. The British didn't burn Washington. Joan of Arc, yes, but not
Washington!
TGIF,
Bob