Steve,
I'll try to respond to your message, in the context of my detailed
responses to John Lowry.
My two messages last Friday may have seemed more than
usually schizophrenic, but after I sent the first one that
strongly rejected the use of anything but a convention,
fully descriptive DN in the X.509 certificate, I realized that
I was primarily talking about relatively high-assurance PCA
dopmains intended for business uses, not for the more
casual e-mail users.
One of the tricky challenges in dealing with Internet issues is
gauging how fast things will grow, get adopted, etc. PEM has been
slow to take off. Despite appearances, I've been fairly passive about
the design of PEM. If it had all taken off like gangbusters, I'd have
no objection. However, it seems pretty clear that it's not taking off
very rapidly.
Is it too early to tell? Am I reacting to quickly? Shall we stay the
course? I'm afraid everything we know about the Internet says
otherwise. If there isn't a way to make use of a service fairly
easily within the existing framework, it's time to re-examine the design.
Examination of PEM reveals multiple problems. Christian listed his
analysis. Others have stated theirs. The use of X.500 names keeps
coming to the top of the list.
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:
Good. This is a very useful exercise.
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.)
Well, this is a broad statement, and I'm not sure it's precise enough
to tell whether we could agree on the general statement, but disagree
on its application. Test question: In what way would the use of email
names fail to meet this criterion?
Test answer: Although there are some differences in the mappings of
email addresses (mail boxes) to users, in general e-mail addresses would
appear to satisfy this requirement. The only problem would be in the case
where multiple users shared a mail box -- the results wouldn't be unambiguous.
But we will probably have that problem anyway. the real problem from the
X.500 standpoint is that Internet addresses aren't in the directory schema,
any more than X.400 ORAs. You are supposed to look them up, not use
them as the search argument. The same thing goes for international
telephone numbers, or even for the use of the public key (or a hash thereof)
as a distinguished name. Yes, it is distinguished (i.e., unambiguous), but
it just isn't a very good name!
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.
Ah. Now we're cooking. And in plain language, I think this is plain
wrong. It's perfectly fine to want to know this much about a person,
but that doesn't mean that the PEM certificate hierarchy should
provide it to you.
Ah ha! It seems to me that this is the crux of the arguments that have been
carried on for many months. I plead guilty to too often thinking about
various business uses, and it is clear from the TIS PCA's policy statement
that your mental model is somewhat different.
1. Perhaps another assumption of mine that should be made explicit
is that I don't believe that the country (or the world) can afford to have
too many divergent views of what constitutes a reasonable public-key
infrastructure. While I strongly support the use of PEM, I also want to
support non-PEM uses, ranging from signing software releases to protect
against viruses to using it for completely open architecture EDI. (At the
personal level, as a user, potential CA administrator, and de facto guru
and trend setter (designated spear-catcher, really) within my organization,
I can't tolerate and won't put up with independent and conflicting
certificate hierarchies. If PEM can't get its act together to support a
national public key infrastructure, I will recommend that we abandon any
further consideration of PEM and move to PKCS or AOCE, or X9.30, or
whatever.
2. I don't insist that the PEM hierarchy has to necessarily provide all
of this information, especially to those users who may not have a need for
it. But I do insist that the PEM certificate hierarchy have the ability to
provide
this information to those who DO need it.
The Internet makes progress incrementally. PEM, RIPEM and PGP all
provide a mechanism for protecting the confidentiality, authenticity
and integrity of email. However, you're asking that PEM also give you
a entirely new naming infrastructure, and you're asking that PEM
messages give you a much more rigorous foundation for legal actions.
That goes way too far. Those are major social changes, not pure
technical innovations. The inclusion of these social changes is not
much different from the Government's Clipper initiative: We'll give
you high grade cryptography, but we insist on imposing certain
policies on you in exchange for this gift.
No, I disagree. I'm not asking that PEM give me an entirely new naming
infrastructure, unless you are referring to the X.500 structure as new.
Likewise, I am not so much requesting that PEM messages give a much
more rigorous foundation for legal actions as I am recognizing that
in so far as a digital signature provides an increased level of confidence
in the degree to which a given utterance can be attributed to an individual,
that individual must and will bear and increased level of risk if he says
something stupid. This is only a matter of degree. If someone defames me on
the Internet, or promises to sell me the Brooklyn bridge and later reneges,
I can go after that person in court. Without a digital signature, I have
a somewhat more difficult time proving that the individual in question actually
wrote the message, but this is certainly not impossible. Whether my belief
that the offer to sell the bridge was well placed without having exercised
due diligence is another matter, as well.
PEM has available a wide range of options available to balance the privacy
vs. responsibility aspects. As the operator of a PCA, you have chosen to
offer a particular standard of care, as described in your PCA policy statement.
Other policies along the spectrum from complete anonymity to complete
FBI/CIA/Treasury vetting of your identiy, loyalty, and financial standing
are also possible. As I said in my follow-up message, I don't have a problem
if you wish to offer a PCA policy domain that insists on "real" e-mail
names as distinguished names. but if you use $12345(_at_)compuserve(_dot_)com,
I may choose not to do business with you, any more than if you said
that you were Santa Claus. I might or might not communicate with you in
private, depending on how incriminating or embarrassing the information
might be if it were disclosed to the "wrong" person.
Also note that the use of state, locality, and street address is probably
necessary just to ensure a well-qualified, unambiguous name in the case
of a residential person.
There are other ways to achieve your goals. One that comes to mind is
to shift the focus toward the use of the existing infrastructure of
email addresses, and then build separate directory mechanisms for
listing the legal and other descriptive information you have in mind.
This approach also satisfies your criterion above of separating the
issues and making incremental changes.
WHAT existing infrastructure of email addresses? There isn't one, and
that is one of the primary problems. Several people have suggested
including e-mail addresses in the certificate, presumably so that if they
solve the database problem for storing certificates, they will simultaneously
solve the problem of looking up e-mail addresses.
At this point, I would settle for a means of entering (or not entering, as
appropriate) the necessary information into an X.509 certificate, whether or
not an X.500 directory ever comes about.
I'll skip some of your arguments regarding the threat orf misdirection
between e-mail addresses and DNs. I think that user's better pay attention
to some of these details, but lets continue the examination of the basic
mechanism first.
As you should have seen by now in my specific proposal for a new
X.509 certificate format, I was suggesting that the DN be kept approximately
as it is today, using the civil naming structure WITHOUT all of the various
hacks that I have proposed from time to time. But instead of the single
attribute subjectUniqueIdentifier, we would allow a SEQUENCE of
attributes that do not belong in the DN. These attributes could
include the X.400 ORA, Internet e-mail addresses, modem and FAX numbers,
etc. -- whatever the user's find to be useful and can get a CA to sign.
Now you can have your cake and eat it too. If you don't have an X.500
directory available yet, fill out the certificate and store it on your
your local database or cache. I would suggest at least three values to be
used for potential indexing purposes, i.e., DN, e-mail name, and nickname.
but unless you have thousands of individual correspondents, a very simple
string-matching search such as is built into my Wizard should be sufficient.
At present I have 296 entries in my telephone number list, which includes
names, addresses, phone numbers, e-mail addresses, cellular numbers,
occupations, etc. I don't communicate via e-mail with more than a few dozen
of those individuals, but yet I can find the appropriate entry in less than 1
second in most cases, just by typing in a few characters of any one of these
various fields and searching them all. Surely any decent UA running on a 386
or faster could find the information almost instantaneously.
Note that I am not saying that PEM (the architecture) has to solve the
problem of finding someone's email address. I'm merely saying that a
reasonable PEM and/or e-mail UA ought to be able to do so, whether the
original information is retrieved from whois, finger, X.500, or my Rolodex of
business cards.
Are we converging yet?
Bob