pem-dev
[Top] [All Lists]

The X.500 is a poor paradigm

1993-08-16 14:54:00

Tom,

        I guess then I am just too much of an capitalist to ever believe any
        of this stuff about rigid rules for X.500 directories.  If I have a
        name in a directory or in a CA, and some new directory server tells
        me, the customer, that I must change my name to accommodate his
        particular weird rules, all I will think is just how I should tell him
        where his directory should be placed?

Call NYNEX and tell them you don't like the way you are listed in the
white pages and would they please adopt your preferred format and
include the info you would like to see in the telephone book next year
when it is reprinted.  Don't hold your breath.  The analogy isn't
perfect, but I think you get the point.  We'll just have to wait and
see.


        You must try to read messages a little better before you respond to
        them.  My comment was about the CA hierarchy.  Now tell me - was it
        the intent that the trust hierarchy rooted in the IPRA was required if
        X.500 directories already were in place?

My response was accurate.  The intent to have a singley rooted
certification hierarchy, with the IPRA serving that role, is not a
transient feature.  Only some of the functions servied by the IPRA can
go away when we have more X.500 service, i.e., the central DN
clearinghouse facility and the global CRL database.  I thought these
features were called out as interim in 1422, but maybe the wording was
not clear enough.


        For better, or for worse, PEM has a default definition of a DN, it is
        that thing which I must have in order to have a public key
        certificate.  There is no other reason for me to get a DN.  It may be
        that X.500 was standardized prior to PEM, but PEM is here and X.500 is
        not, so lets get real.  By the way just what are those other mailing
        lists??  -- the person who mentioned them before suddenly can't think
        of any!

I believe there are on the order of 1 million users registered in
X.500 DSAs today, which makes the population somewhat larger than the
deployed PEM user base.  That sounds reasonably real to me.  Remember,
X.500 is not a replacement for DNS, it provides a different set of
services that the DNS does not offer.  So the relative size of DNS and
X.500 populations is not the issue here.  As for pointers to the other
mailing lists, let me suggest you contact CNRI and check out the WG
lists, which will lead you to the mailing list for the OSI Directory
Services (OSIDS is the WG abbreviation).


        One more time, if the DN is the primary search key, it had better
        distinguish between distinct entries.  And you can be quite sure that
        the level of assurance that I get in creating a private message will
        be a consideration in where (which mail box) to send a message!

Tom, the point is not whether a DN is, in fact distinguished (which it
always is) but conversely, whether any way of syntactically
distinguishing between to names constitutes a basis for forming a DN
(which it does not).  More goes into the question of what constitutes
a reasonable DN.  Think of it like language.  There are lots of ways
to construct syntactically correct sentences (DNs) from a list of
nouns, verbs, adverbs, etc. (analogous to attributes).  However, many
of the constructed sentences would not make sense given a larger
semantic context.  

        If you really believe that assurance level is far fetched, how can you
        justify using PEM at all?

PCAs are a creation of the Internet certification system (they do not
exist in X.500) and they provide a means of relating assurance
information about user and organization certification.  That is the
means adopted by PEM for encopding assurance information into a
certification path without impinging on an organization's freedom to
structure DNs.  You were suggesting a syntactic means of conveying
assurance information way that would intefere with DN structure.

Steve

<Prev in Thread] Current Thread [Next in Thread>