pem-dev
[Top] [All Lists]

Re: DMS RFP Bids

1994-07-13 02:17:00


   >From: Dave Crocker <dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu>
   >Subject: Re: DMS RFP Bids 
   >Date: Tue, 12 Jul 94 15:07:35 -0700

   >Steve,
   >
   >    ---- Included message:
   >
   >            We will have an opportunity to test my claim on a larger scale
   >    over the next couple of years, in that the DMS will have a fairly
   >    large number of subscribers who will make use of certificates with
   >    DNs.  The DoD has a fairly wide range of members, with different
   >
   >Not sure that the military communications environment constitutes a valid
   >sample for testing human factors 'naturalness' for global utility.
   >
   >My comment about short-vs-long was perhaps too simplistic.  The 
attribute/value
   >sequencing model also seems to carry specification complexity (notational
   >complexity) that is a pain for users.  The DNS syntax is simpler in ways 
that
   >seem to have better human factors characteristics.


By comparing X.500 DNs with DNS names are you actually comparing like
with like? 

The DNS name "foo.com" is esentially a key into a database, that
returns a less friendly form (123.456.789.123) of address.  This
numeric form is then used by the communications sub-system.
This is pretty much hidden from the user.

I'd like to suggest that the attribute/value model of DNs is
equivalent to the numeric form of IP address.  What is required is a
"DNS like" key onto the DN.  

Such a scheme has been proposed in RFC 1484 "Using the OSI Directory
to achieve User Friendly Naming (UFN)".  In this scheme the attribute type
information is esentially droped.  Then a mechanism, using the
directory, for resolving these type less names into typed names is
proposed.

For example, my DN in the PARADISE X.500 pilot is

        commonName=Colin Robbins, organizationName=NEXOR Ltd, countryName=GB

which is a bit of a long thing to type.  However, in UFN
representation this could be

        Robbins, NEXOR, GB

This is not that far dirrerent from robbins(_at_)nexor(_dot_)co(_dot_)uk - 
infact
simpler, because the 'co' bit is dropped, and I don't have to think
whether a '@' or '.' seperator is required between components!

So in my opinion, in certificates as used by the security sub-system
DNs are fine, provided that when interacting with users, the UFN form
is used.
I believe this is exactly what the GDM PEM implementaion Steve
metioned does.


Colin

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