Steve,
From: Stephen D Crocker <crocker(_at_)tis(_dot_)com>
To: pem-dev(_at_)tis(_dot_)com
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE
kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh
HbGVud29vZA==,03
MIC-Info: RSA-MD5,RSA,J6tn1R723rn6oOukG0uvbhCnavKAr27USL/sfQzOOzP
Usx6vDEqKSUVcvfOkC+FQ7rjpn072zusH73gwWAqNnAI2AxOn8IO6ow7ADYwq7d0
rxQh6bQ68cg8C1wGnz2Jt
The attached exchange between anish(_at_)ctt(_dot_)bellcore(_dot_)com and
Jueneman(_at_)gte(_dot_)com is focused on the handling of nicknames. However,
the underlying assumption is that email addresses are the basic form
of identity used in the Internet.
RFC-822 email address are the basic form of identification for network
entities. If anything they are becoming more and more dominant.
X.400 addresses has proven so impractical that there are proposals to
just adopt RFC-822 names as valid X.400 names.
In my view, the introduction of X.500 distinguished names has been a
very troublesome venture, and I see no evidence that things will get
better. Quite a lot has to happen before X.500 names are genuinely
useful as the basis for identity on the net.
DNs are hopeless. Anyone reading the tens of thousands of lines of
pedantic disputation re DN diddle-shit that have gone by on this
mailing list would be forced to that conclusion but it is also
derivable from principles. Yes, you can construct an unambiguous name
from naturally occuring names such as country, organization, person
name, street address, etc., etc., etc. but to guarantee uniqueness you
end up with something so long and complex it is useless for human
beings and has to include so much junk that part of the DN will change
so often that, for many applications, it just does not have the
stability required for a useful "name".
The way to go is a "resigtration" system with first come first serve
allocation of hierarchial names. The DNS plus "user names" does this
and always has. Although I don't want to go into too much detail here
I have never seen any validity in the claims that we are "running out"
of DNS names or that there will be serious problems due to name
"conflicts".
No problem I can forsee with email addresses could compare with the
nightmare of puzzling your way through the morasses of ployglot X.500
stuff. Like most OSI "protocols" X.500 is so complex and allows so
many options that its really just a way to claim there is a world wide
directory standard but still give each directory authority so much
freedom to go its own way that actually dealing with the resulting
"world wide directory" will be an enormously difficuly artificial
intelligence problem at best.
The existence of local alias systems has no relavence at all to this.
They are fine for personal abbrevations for freqeuntly used names but
are no excuse for having impractial names to start with.
Directories are relevant. A good directory scheme would be great. It
could map from lots of attributes to the true name for an entity. You
could use it to map to someting gross and useless like DNs. Or you
could use it to map to something useful and reasonably susinct like an
email address. Or both. Maybe whois++, which I have not looked at,
or its successor can fill the need for a good directory.
Given the very serious difficulties of deploying PEM using X.500
distinguished names, perhaps it's time to ask the question directly.
Do we want to shift over toward using email addresses in place of the
current regime of distinguished names?
If we want to shift over toward using email names, then certificates
would bind email addresses to keys. There might exist directories
that map email addresses to more detailed information, but the email
address would be the principal handle by which keys would be
associated with people.
email addresses are currently encodable in the DNS. You just replace
the "@" with a "." and put a "\" before any "."s in the user name.
certificates, keys, DNs, and other attributes can be added to the DNS
under the email address as a name. See the DNS security draft I will
be posting shortly.
Steve
Donald
You seem to want to tie a certificate to an e-mail address, whereas
I would prefer to tie BOTH to a locally-known name or nickname,
regardless of how it gets delivered (i.e., to which one of several
possible mail boxes.)
I agree totally with this point. However, I believe it would be the
responsibility of the user agent to handle nickname-to-emailname aliasing.
The responder should only have to know email addresses, since that's the
generally accepted name scheme used in the mail world. Nicknames should be
defined locally - can you imagine how large an alias file would get if a
repository had to keep local aliases for all potential users?
You'd still be able to use your nicknames, but they would have to be
resolved into email names at the UA, the same way that email-to-DN mapping
would have to be resolved prior to accessing the certificate.
-----END PRIVACY-ENHANCED MESSAGE-----