On Wed, 8 Feb 1995 Jueneman(_at_)gte(_dot_)com wrote:
IF the directory is only to be used to look up the certificate, and the
asumption is made that the e-mail package already knows the precise rfc822
name
(probably without the "Mr Rhys Weatherly" prefix), AND if there is only one
certificate associated with that particular DN, then a simple Read operation
is
sufficient and straight-forward.
Is this all of the functionality that people think would be necessary, useful,
or desirable? Or would they like to have the ability to look up the e-mail
name
as well, based on some other search index such as surname?
Ultimately both would be required. It is good to separate two issues:
(a) Finding a person and their e-mail address in the first place.
(b) Finding a person's certificate or bare public key.
Issue (a) definitely requires browsing capabilities, but I don't see it as
important to PEM at this time. Most communications occur in an
environment where the e-mail address is already known or is easily
discovered, even without directory services. Issue (b) is very important
to PEM as having up to date copies of a person's certificate or key, plus
any applicable CRL's, is necessary for PEM's functionality. Very little
browsing capability is necessary for (b). Either an e-mail address or a
DN is already available for a direct lookup.
Eventually, I'd like to see (a) adopted in MUA's, even those that don't
support PEM, but I think we've got some way to go yet before that happens
and it isn't appropriate for this working group. Issue (b) has to be done
for PEM even if (a) isn't. Whether it is done with X.500, a flat file
database, finger, or some new protocol we concoct, it needs to be done.
(For scalability, it might be a good idea to parse the rfc822 name and
separate
the final root, so that COM, ORG, MIL, EDU, and US are all located under the
country=US arc, unless the ISOC wants to include the entire world under some
global root. But the DUA interface could manage those details.)
The various RFC's on using X.500 with the Internet seem to indicate that
domain names and e-mail addresses can be represented in the directory as,
for example:
DC=au, DC=edu, DC=qut, DC=fit
DC=au, DC=edy, DC=qut, DC=fit, DC=rhys
DC=com, DC=gte
DC=com, DC=gte, DC=Jueneman
Where "DC" is "domainComponent". Personally, I think the "DC=rhys" should
use a different attribute type ("rfc822Mailbox"?) to distinguish the
e-mail address rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au from the domain name
rhys.fit.qut.edu.au, but the above is what the RFC's currently say. A
question for X.500 gurus: does this encoding hang off the root of the
directory or does it hang under some other DN, like the Internet
Society's?
Note: the above would usually be for alias purposes. I'd probably have a
"real" DN like:
C=AU, O=Queensland University of Technology,
OU=Faculty of Information Technology,
CN=Rhys Weatherley
But I'd still like an alias from the DC form of my e-mail address to the
real form, as lookups by my e-mail address are likely to be more common
than lookups by my "real" DN.
Since the Internet Society is the official name registration authority for for
rfc822 names, it doesn't have to share that name space with any other
organization. So unlike the case of residential persons and personas, where
competing directory service providers may end up fighting over how to
subdivide
the various states and cities,
Personally, I think the strict name subordination rules of PEM will
eventually have to go to allow for multiple ceritification paths. But,
let's leave that aside for now as we've got other things to worry about
implementing first. You are certainly correct that e-mail addresses are
unambiguous (which is why I've argued for their use all this time :-) ).
Speaking of access control and perhaps accounting (a dirty word, implying that
someday there might be a charge for this service), would it be a good idea to
bite that bullet now, and incorporate a signed request for the certificate?
Maybe not straight away, but the mechanism we choose should be extensible
to do it IMHO. There are two kinds of signed requests: access control for
certificate generation purposes which Bob is thinking of charging for, and
a "login" operation for certificate lookup purposes (e.g. a company that
uses e-mail internally may not want to publish all of its e-mail addresses
and certificates to the whole world, but does want internal users to be
able to retrieve certificates after logging into the company's CA server).
I'd like to hear from other PEM software authors. Once we get the
MIME/PEM documents out the door, would it be appropriate to look at
creating a standard lightweight CA server protocol for use in PEM? I've
been giving it a lot of thought, including access control measures and how
to gateway into the existing X.500 directory. Just say the word and I'll
post a draft.
Cheers,
Rhys.
--
Rhys Weatherley, Queensland University of Technology, Brisbane, Australia.
E-mail: rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au "net.maturity is knowing
when NOT to followup"