OK, here's the longer reply to Bob's message that I promised.
On Tue, 8 Mar 1994 jueneman%wotan(_at_)gte(_dot_)com wrote:
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.
The Introduction is mainly a collection of weasel words anyway, and
probably a few are lacking or reflect my political viewpoint a bit too
much. :-)
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.
There certainly are such registration procedures in Australia, but that
is really beside the point. Take my organisation, QUT, for example. As
one of the many workers here, if I wanted to use PEM with a "real" DN,
what would it be? I'm not the "keeper of names" for this organisation,
so if I want to get up and running with PEM quickly, in the face of admin
personnel that are willing to sit back and watch developments, this
leaves me with a choice I shouldn't be making. Let's analyse the
possible DN's for me here:
Since my name is fairly unique in this organisation:
<{C=AU}, {O="Queensland University of Technology"},
{CN="Rhys Weatherley"}>
But, that could cause problems, so I'll add the faculty:
<{C=AU}, {O="Queensland University of Technology"},
{OU="Faculty of Information Technology"},
{CN="Rhys Weatherley"}>
But, around here, the school names are more usual:
<{C=AU}, {O="Queensland University of Technology"},
{OU="Faculty of Information Technology"},
{OU="School of Computing Science"},
{CN="Rhys Weatherley"}>
But, I'm also associated with a particular group within that school:
<{C=AU}, {O="Queensland University of Technology"},
{OU="Faculty of Information Technology"},
{OU="School of Computing Science"},
{OU="Computer Architecture for Secure Systems Group"},
{CN="Rhys Weatherley"}>
I think you get the idea. Factor in {S="Queensland"} for the
geopolitical entity that QUT resides in, postal addresses, etc, etc, etc,
and the DN starts to get very long. But, the length really isn't the
issue. Any of the above names would be valid for me, but at this point
in time (as far as I know) there is no standard X.500 naming strategy set
down by the QUT powers that be. Hence, if I choose some "obvious" DN for
myself now, it may bear very little resemblance to what the people in the
admin block at this uni feel is the right naming strategy. I can't
simply ask them though: "What's X.500? Never heard of it" or "Why bother
with X.500? No one seriously uses it at the moment anyway".
On the other hand, the e-mail address system adopted here is already well
established and supported by the admins. Choosing a name based on that
is safe.
Admins (I'm talking about the beaurocrat types here, not the computer
types) can be very picky as to what names should be used for an
organisation. At my last place of employment, the official name was "The
University of Queensland". Leave out that "The" and the vice-chancellor
would come down on top of you like a ton of bricks. But, he was
perfectly happy with the abbreviated "uq" used in the e-mail addresses
there. The serfs, who _will_ be the first to make use of PEM, are not
the correct people to be deciding what is the right name to use. Once
PEM becomes popular at an organisation and the admins are familiar with
it, that is the time to go official and use the proper name.
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.
<{DC=com}, {DC=compuserve}, {RM="70752.16", CN="US Joint Registration
Authority Registrar"}> ?? The CN attribute certainly seems descriptive
enough for me, which is why I included it in my proposal. The
compuserve.com example is bogus is my estimation anyway, because
CompuServe should long ago have changed over to real names. That's their
own internal silliness manifesting itself, not any inherent weakness in
DNS names as identifying values.
If your argument is that e-mail addresses are ugly compared with "real
names", then you'll have few who disagree with you, but in terms of
speeding up PEM deployment, we need a way to lever off the existing
naming structure used on the Internet.
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.
Many people would rather not release their home address to the whole wide
world. Then where are they? Persona CA's perhaps, but then we're back
to "Where the hell are the Persona CA's?". You are I know about RSA
and TIS, but what about the unwashed masses? I'll kindly redirect all
requests from my users for "someone to sign my key" to you, how about
that Bob? :-)
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.
You could equally claim that about e-mail addresses. Just because they're
terse doesn't make it any less apparent that the individual is using the
organisation's name. Those little disclaimers "I do not talk for my
company" in signatures are not there for nothing.
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.
X.400 is separate from the DN more by accident than by design. The DN
names, or something similar, should have been the addresses used by X.400
in the first place, but the X.400 committee got a little confused about
the difference between naming and routing. In any case, X.400 now looks
like moving towards using Internet e-mail addresses as standard. Back to
Internet addresses again.
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.
If you want to have a single certificate for all of those addresses, I am
certainly not stopping you. You can either use a traditional DN or
choose one of your e-mail addresses as the canonical one. Then the
mapping between your other addresses and your certificate will need to be
established "out of band".
One of the main benefits that Steve seems to be pushing is that for your
canonical address, no out of band means are needed to establish a
binding between your e-mail address and your key. With traditional DN's,
we currently always have to do out of band checking.
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.
OK, I'll send you the full source code for my Windows news/mail reader
and you add it huh? :-) I am in the process of a _complete_ redesign of
my program to accomodate both MIME and PEM. I'm lucky in that it needed
to be redesigned anyway ( :-) ). Most authors want to add the new features
quickly and cleanly, and then worry about redesigning the program
over time. If they can't do that, it doesn't get added.
Supporting PEM is not just about gluing a better address book in and
adding the code for privacy enhancements either. I'm finding that I need
to go over every inch of my design to make sure that none of the original
message is left in memory or on disk so that snoops could use that
information against the author. In the process I am also investigating
encryption of mailboxes, better security features, etc, to make sure I do
the whole system "properly". This is not a trivial task and not all
programmers are going to attempt it for quite a while.
This is why we need a stepping stone to get us further up the ladder
towards the ideal PEM implementation, while at the same time drastically
increasing the number of people who know about and use PEM.
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.
Users are notorious for believing everything the computer tells them.
The X.509 certificate is just yet another piece of gobbledegook that they
need to have lying around. They want to know "press button X, type in
address Y and your private key password and you can send encrypted mail".
If
you are basing such decisions on the user's mailbox name, you have a pretty
shaky
assumption.
If you are basing such decisions on the user's DN, you have a pretty
shaky assumption. A DN, like an e-mail address, is a mechanism for
identification. DN's are just as easy to forge as e-mail addresses
(well, not quite as easy: you need to write a program to grok ASN.1
encodings :-) ). A CA system based on domain names would be just as
effective as one based on "real names" (i.e. not at all until we have
enough users to make a CA system wide-spread enough to be useful).
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.
Sure, presenting the information in a nifty fashion is not difficult.
But it is just as spoofable as certificate information based on e-mail
addresses.
I don't buy the scalability argument at all. Most users only correspond with
a
few dozen users at most,
I don't know whether you'd class me in the "most users" category, but I
have hundreds of correspondents in the average month, because I am the
author of a number of packages and am constantly having to solve user's
problems. These communications are in the clear at present, but as
encryption becomes common, I'll need to keep track of keys for all these
people. This is where scalability is very important. A handful of keys
with "ask Rhys if he believes it before adding to the cache" will work ok,
but hundreds? If the From or Reply-To line matches the signed value in
the certificate, 99% of the work has been done for me. The other 1% is
finding a valid certificate chain back to something I trust.
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.
You can keep the old certificate generation programs. I am not trying to
completely replace the traditional DN system, merely augment it with a
way to leverage off the existing Internet naming system. If you want a
traditional DN, more power to you, but for me an e-mail address DN is a
lot more convenient and practical and will get me in less trouble with
the local naming authorities for usurping their power.
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.
I think you should probably ask the PEM implementors whether they would
implement an e-mail address mapping scheme or not. :-) As for DUA's,
those two attributes come direct from the Internet X.500 Schema stuff
developed by OSI guru Steve Kille. If DUA authors aren't implementing
them now, then there's nothing much that can be done. If DC and RM are a
problem for you, I can easily go back to O and OU, but you objected to
that because you didn't want to be associated with the Internet Society.
Which will it be?
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.
This works, up to a point. That point is the certification authorities
themselves. You are a great fan of letting RSA and TIS do all the
signing. I'm a great fan of setting up CA's out in the boondocks as the
necessity arises. Your scheme would work great with existing CA
hierarchies, but is not scalable to future CA hierarchies that in all
likelihood will be based on domain names.
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> "
Yuk. Try this on for size (based on my home e-mail address):
DC=au, DC=org, DC=brisnet, DC=meteor, RM=rhys
For X.500 purists, this is:
C=AU, O=BrisNet, OU=meteor, CN="Rhys Weatherley"
In fact, that is exactly what BrisNet's DN would probably be (since I'm
the president of BrisNet, I'm the "powers that be" in this case :-) ).
Now, what's the difference? Absolutely zip. DNS names are not as far
away from the real world as you'll have us believe. Some are, but the
majority aren't.
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.
I think you know my opinion on having to get a signature from _anyone_
before starting to make use of PEM. In this case, will TIS/RSA/COST look
kindly on him "borrowing" their hierarchy so he has a name somewhere in
the X.500 universe?
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.
Finally! That's all I'm asking, and that's what I tried to make clear in
the draft. You can have your traditional DN's if you want, but let's
have e-mail address DN's as well. There are two fundamental mechanisms in
my draft: a way to encode an e-mail address in the absence of a
traditional DN, and a way to add an e-mail address to an existing DN.
But, if you want an ordinary DN, I'm not going to stop you.
Cheers,
Rhys.