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.
I don't care much one way or the other. Ned, at least, has expressed the
opinion that PEM, MIME, and e-mail are all likely to be integrated in a single
application, and if that is the direction that developers are likely to take
then developing a separate protocol that wouldn't support browsing might not be
worth while. On the other hand, I like having the ability of finding someone's
certificate independent of an e-mail package.
For certificate retrieval only, I'm happy directly looking up either an e-mail
name type of DN or a "regular" DN without browsing. My SUGGESTION would be that
we use an e-mail based retrieval mechanisms rather that a direct socket
approach, just so we can support the significant number of users that do have
email but don't have TCP/IP, but I won't arm wrestle anyone over this.
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?
One of the principles recognized early on in the NADF is that users should list
their names in those directories where they want to be found. I would therefore
argue that there is nothing wrong with saying
c=US, rfc822=<rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>
(or c=US, domainName="fit.qut.edu.au", rfc822Mailbox="Rhys")
If Rhys corresponds often with users in the US, listing his address there would
make sense. When someone sets up a master directory for Australia, he can also
list his address there, as c=AU,
rfc822=<rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>.
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.
At this time, I believe that it would be necessary to have aliases listed in
both of the serving directories. It MIGHT be possible to have an alias in the
US master directory (implemented though the NADF's CAN procedures) point to an
entry in a DSA in another country, but I'm not certain about that -- certainly
not yet. Again, this is a detail we can sweat later.
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 :-) ).
This particular issue doesn't have anything to do with the name subordination
requirement. If you assume, as Ned and others have suggested and I am beginning
to believe, that commonName is not particularly useful as a serach index and is
not guaranteed to be unique within a given locality in any case, then the only
obvious way to guarantee a uniuqe residential person DN would be either to
include the street address or a uninformative uniqueID field. many people
wouldn't want to include their street address in the DN, because that forces it
to be in the public name space.
At least in those countries where the PTT does not exercise a monoply over
these functions, it has to be assumed that there will be multiple directory
services suppliers, and that there will not necessarily be any neat division of
"turf" by geographical boundaries. Even in the case the last remaining (and
soon disappearing) monoplies, the local exchange (telephone) carrier, their
service boundaries do not always correspond to geopolitical boundaries.
This isn't an issue in the case of Internet names, because the NIC effectively
acts as a monoply and only assigns unique names. (Unique doesn't imply
unambigous, however, because the mapping of e-mail addresses to users, or even
user roles, isn't one-to-one, which is why I've argued against them. :-)
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).
Actually, I was thinking of accounting for directory services, even if it is
only a penny per lookup. Unless we can get the various governments to pay for
these services, or charge for them as a "tax" on the Internet access lines,
sooner or later the bill is going to have to be paid by the users of the
service. I don't immediately see how certificate generation enters into this,
but your second point, about wishing to facilitate controlling access to
internal corporate directories is very valid. There is a lot that I don't
understand in how effecgive access controls will be set up, but I would prefer
to provide a basis for strong authentication now, rather than having to redo it
later on.
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.
I think we are moving on the right track. The main question that I have for
PCAs and CAs, as well as for potential PEM, MIME/PEM, MOSS, etc., etc.,
developers is whether retrieving CRLs by this same mechanism would be
worthwhile. I.e., would the PCAs be willing to post their CRLs into this
directory, or should a separate protocol be developed to retrieve them? (Maybe
that's what Rhys meant.)
Another alternative to retrieving CRLs is to simply query the CA (or PCA) for
an instataneous ruling as to the current validity of a particular certificate.
If this is done by submitting the signature portion of a document in question,
the signed response can provide nonrepudiation for the document.
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-282