Rhys and Steve,
With all due respect to the effort you have put into
trying to map e-mail names to DNs, I still think you are
trying too hard to solve the wrong problem.
Let me begin with part of the Introduction to the I-D:
However, it will be quite some time before the X.500 naming
authorities and directory servers are wide-spread enough on the
Internet to make the process of a user obtaining a DN fairly
painless. In the mean-time, organisations are left making a "best
guess" as to what their DN would be with the attendant problems of
namespace collision.
In addition, one of the biggest growth areas of the Internet at the
moment is on the fringes, where small public access setups are
expanding the Internet to the public at large. In many cases, these
setups are private individuals who do not have an organisation name
that could be transformed into a suitable DN. Residential CA
hierarchies are not wide-spread enough internationally to be useful
to these individuals at present.
This situation will change over time, but currently PEM deployment is
suffering because of a lack of DN authorities, and because of a lack
of an established mapping between DN's and e-mail addresses.
I have fairly serious reservations about the "facts" as stated, and if
the motivation for this effort is not well grounded, the results probably
won't either.
I understand Rhys' problem regarding X.500 naming authorities being set up
in Australia. "Official" naming authorities are being set up very slowly in the
US,
as well, but I cannot accept the conclusion that "organizations are left
making a "best guess" as to what their DN would be with the attendant
problems of namespace collision."
I'm certainly no authority on Australian law or business practices, but I would
bet a sizable amount of money that they have a procedure for registering
corporations and organizations within geopolitical boundaries, even at the
equivalent of the local town hall, in order to ensure uniqueness and minimize
confusion. Surely there are Tax ID numbers or other unique identifiers that
could
be used. But even if there were two Queensland University of Technology's
somewhere, it would certainly be possible to qualify the organizational name
with a locality and street address, even if it is overkill. I don't want to go
to
far down the path of saying that DNs are "discovered" rather than assigned,
but there is a lot of truth to that. And once the parent organization has been
named, it can control the various OUs and common names registered within
it. Again, there may be occasional collision problems, but we will all face that
problem.
The major point is that no one, either in the US or Australia or elsewhere,
needs to wait for the equivalent of ANSI to be set up and start handing out
organizational OIDs in order to create a DN to be included in an X.509
certificate.
So the organizational DN should be a non-issue.
In addition, one of the biggest growth areas of the Internet at the
moment is on the fringes, where small public access setups are
expanding the Internet to the public at large. In many cases, these
setups are private individuals who do not have an organisation name
that could be transformed into a suitable DN. Residential CA
hierarchies are not wide-spread enough internationally to be useful
to these individuals at present.
This is true, and many of those users will have names that are NOT mnemonic
nor easily usable for identification purposes. For example, the e-mail
address for the US Joint Registration Authority Registrar is
70752(_dot_)16(_at_)compuserve(_dot_)com(_dot_) Now that's descriptive, and
easily remembered!
E-mail names are therefore not obviously suited for such DN purposes either.
But Rhys' real point is that "Residential CA hierarchies are not wide-spread
enough internationally to be useful to these individuals at present." In
particular,
he doesn't want to have to comply with the RSA Commercial Hierarchy's
requirments to send in a notarized statement, etc. OK, so what? Steve Crocker
already said that they would be willing to operate a low assurance PCA, where
a "claim" of a "right to use" a name could be provided by a simple e-mail
assertion, with signed certificates being returned by an automatic responder.
We don't have to wait for the California, or Queensland, or the Federated
Islands
of Micronesia to establish formal registration procedures to prevent name
collisions.
That's one of the functions the IPRA was supposed to perform in any case.
So the possible problem is that someone might claim that they are Waltzing
Matilda,
and that they live at 123 Billabong St., but they don't really. So what? This
would
be a low assurance PCA anyway, so caveat emptor is the rule of the day.
Establish
your out of band contacts with your correspondents, and you will quickly learn
which twin is the phoney. Likewise, what happens if two people claim the same
name, and do not adequately qualify their residential name with a street
address,
causing a name collision if and when we get X.500 up and running and
loaded with all those names. Well, some confusion might arise, just as it does
today. It isn't the end of the world, and the certificates will expire in a
year or two
in any case.
This situation will change over time, but currently PEM deployment is
suffering because of a lack of DN authorities, and because of a lack
of an established mapping between DN's and e-mail addresses.
I'm sorry, but I really don't believe that either of those statements is
correct.
I do believe that people within organizations that have a certain amount of
bureaucracy built in to them will have some problem in granting their users
the right to use the organization's name, because of possible perceived
liability
and/or contractual obligation issues.
I also don't believe that there is a serious problem of not being able to
map between DNs and e-mail addresses. In fact, I think those two issues
should be kept separate, just as X.400 addresses are independent of the
DN. I may very well want to use my certificate at work, at home, and on the
road, and my e-mail mailbox may vary accordingly. In particular, why should
it make any difference whether I use my office PC (wotan%gte.com -- an ugly
artifact
of our firewall system), or whether I log on to my Unix mail server as
rrj0(_at_)bunny(_dot_)gte(_dot_)com, or whether I send and receive mail using
Compuserve or AOL,
there is no reason why my certificate should change.
Let's consider how we send and receive certificates, and for what purpose.
If I receive a signed message, I will want to validate it using the originator's
certificate. Eventually, it would be nice to have a way of caching or looking up
these certificates, just to cut back on the bandwidth, but for the moment it
is perfectly feasible and in fact the encouraged practice for the originator to
include
his entire chain of certificates within each message. So we really don't have a
practical problem with certificates on incoming messages.
In the case of encrypted messages, we have two cases -- one where the message is
a reply to another message that is at least signed, and one where a new message
thread is initiated. In the case of a reply, the certificates are already in
front of our
nose, so to speak, so using them to encrypt the reply should be no great
problem.
The real issue seems to be how to file incoming certificates so that the user
can
later retrieve them, and how to coordinate the certificate with the e-mail
address for encrypted mail.
Steve Crocker has argued that he believes that the e-mail name is all-important,
but I think that this may be a point of view that reflects the experience of
relatively
long-time Internet users who either work for small companies or got in early
and can
still use short, almost "vanity-plate" mailbox names.
Sure, (assuming that people can remember how to spell Jueneman,)
Jueneman(_at_)gte(_dot_)com or Crocker(_at_)tis(_dot_)com, or
Kent(_at_)bbn(_dot_)com is short and
easy to remember. But Christian Huitema
<Christian(_dot_)Huitema(_at_)sophia(_dot_)inria(_dot_)fr>
and Mr Rhys Weatherley
<rhys(_at_)fitmail(_dot_)fit(_dot_)qut(_dot_)edu(_dot_)au> and Frank Sudia
<p00561(_at_)psilink(_dot_)com> simply strain my brain. I called Rhys
"Weatherby", which
is the name of a fine brand of rifles and shotguns, and Lord knows how
many times I have mangled Anish Bhimani
<anish(_at_)ctt(_dot_)bellcore(_dot_)com>. Wish
we all had names like Kent(_at_)bbn(_dot_)com!
Maybe it's Alzheimers (what was I saying?), but I have to look up such names,
and I don't look them up by their e-mail name. Instead, my pretty brain-dead
mailer allows me to store names like
"Huitema, Christian"
<Christian(_dot_)Huitema(_at_)sophia(_dot_)inria(_dot_)fr>
and that is they way I look up even people who work for me -- by last name
(because
we tend to assign mailbox names based on initials, and then allow users to set
up
aliases if they wish.)
My FAX mailer is organized the same way. Neither is as smart as my Wizard,
which allows me to search for any portion of the string (in case I can remember
"Christian" or even "Christ" easier than Huitema. and neither are as friendly
as Quicken, which attempts to guess what I am going to type based on the
first several characters. But I can live with thes limitations, and I suspect
that
most users could. I have almost 300 entries in my Wizard's Rolodex, and I don't
send mail to nearly that many people.
Note that I am NOT arguing that instead of thinking of me as
Jueneman(_at_)GTE(_dot_)COM, that Steve should be thinking of me as C=US,
O=GTE Laboratories Incorporated, CN=Robert R. Jueneman. He is correct,
little if any of the software available is organized like that, and perhaps none
should be. Instead, he should probably think of me as just "Bob", with further
qualifiaction depending on how many Bobs are in his list of correspondents;
or alternately as "Jueneman," with the same proviso.
Once the user has made a stab at the name, his mailer/PEM/Directory user agent
ought to finish the job, and present both the proposed e-mail address and
certificate for his review and confirmation. Depending on the use that is
intended,
a different e-mail address or different certificate might be selected.
In a previous message, Steve Crocker said
I've come to believe this point is fundamental. Various of us have
spent time and energy facilitating the use of PEM by designing
makeshift techniques for splicing PEM into the mail systems. The
"state of the art" is this. When a new certificate arrives, my system
either proposes the likely EN to DN correspondence or asks me for the
EN side of the correspondence. This requires manual operation each
user's part, is subject to error, and has no traceability. From a
security analysis point of view, this is not a great design. It also
fails on human factors and scalability grounds.
I don't have any objection to introducing distinguished names which
are descriptive if they're an adjunct to ENs, but I think it's
essential that we reorient PEM to use ENs as the base.
While I respect his judgment and opinion, I disagree with him on this. If his
system requires him to file a certificate under a user's e-mail address
instead of a nickname or other more friendly index, I think that is his
systems's fault, and he ought to go get another one. Even if he likes using
e-mail names as an index to certificates, his system ought to be able to use
the From: or Reply-To: address as the e-mail address under which to file it.
Marshall Rose made a very good point in one of his tutorials on X.500. He said
something to the effect that "user friendliness" should be a property of the
Directory User Agent, and not necessarily of the Distinguished Names themselves.
The local UA should have the responsibility for turning user-friendly nicknames
into DNs, and then looking up e-mail addresses and certificates. X.500
is not required for this purpose, and the correspondence between the DN in the
X.509 certificate and the DN of the user's entry need not be particularly
strong.
With regard to the security analyst's point of view, I would hope that the user
is
examining the entire contents of the X.509 certificate before deciding whether
to spill his guts in an encrypted message which is sent to the wrong person. If
you are basing such decisions on the user's mailbox name, you have a pretty
shaky
assumption. I can't evaluate the human factors aspect of his argument, for I
don't
know how the information is being presented. But we had a decent interface
for such functions up and running several years ago.
I don't buy the scalability argument at all. Most users only correspond with a
few dozen users at most, so almost any means of storing those certificates will
work. Now if you want to find someone's certificate in the Manhattan phone book
because you want to send an encrypted order for take-out-Chinese and you have
never order from that particular store before, that is a different problem. But
I don't
believe that is what is holding PEM back from a wider success.
Having said all this, I don't mean to imply that having the ability to put an
e-mail name
in a certificate would be of no value. Of course it would, as would lots of
other
non-DN attributes. But so far I am not convinced that changing PEM and the
various certificate generation programs would be worthwhile at this time.
If you can convince the IETF to sponsor a revision to X.509, as I tried to
without
success within the last month, more power to you. The same goes for adding ANY
new attribute, whether domainComponent, rfc822Mailbox, or whatever -- the DUAs
and PEM programs won't support them.
For the short term, pragmatic solution, therefore, if you want to have some
additional
level of assurance regarding the binding of the user's mailbox to his name and
to his public key, I would suggest that you not worry so much about making it
machine parseable, but simply include it as a human recognizable string within
the
common name.
With this scheme, the DN in my X.509 certificate would read
C=US,O=GTE Laboratories Incorporated,
CN="Jueneman, Robert R."<Jueneman(_at_)GTE(_dot_)COM>
Frank Sudia's DN might be
C=US, S=New York, O=Bankers Trust Co.,
CN="Sudia, Frank" <p00561(_at_)psilink(_dot_)com>
and Rhys Weatherly's DN might be
C=AU,
stateOrProvince=Queensland, [Is Queensland a state, province, territory,
or what?}
l=Brisbane,
O=Queensland University of Technology,
OU=Gardens Point Campus, [optional]
CN="Weatherley, Rhys" <rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>
Or, if Queensland University of Technology doesn't want to sponsor or register
Rhys,
he could use a quasi-residential address:
C=AU,
l=Brisbane,
streetAddress="c/o School of Computing Science,
Gardens Point Campus,
Queensland University of Technology
2 George Street
GPO Box 2434"
postalcode="4001",
commonName=" ""Weatherley, Rhys""
<rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au> "
(Note that the c/o (care of) does not imply that he works for or has any
authority
within the School of Computing Science. A monkey in a cage could be addressed
this way, without any expectation of liability on the part of the institution
if the
monkey signed something.)
Assuming he sends a certificate containing that DN to a low-assurance PCA
operated by TIS, RSA, COST, or anyone else, and that they certify him as a
residential person, he is up and running. If and when he wants to enjoy the
presumed benefits of something closer to an open-EDI architecture and have
his signed statements viewed with the same authority as a personal check,
he will probably have to join up under a higher assurance PCA, or find some
more than usually trusting individual to "cash" his electronic check.
Sorry this was so long winded, but I really think that we would be going down
the
wrong track for the wrong reasons if we adopted the use of e-mail names
INSTEAD of the more traditional civil authority DNs for use within PEM
certificates,
(except for Persona certificates, where it doesn't matter). If we can
incorporate them
in ADDITION to the "normal" DNs, that would be great.
Comments, rejoinders, or miscellaneous flames? (BTW, I hope it was obvious
that I was not attacking either Rhys or Steve personnaly. They've done some
excellent work, and I respect that. I just disagree with their proposed
direction.)
Bob