pem-dev
[Top] [All Lists]

DNs (Re: Residential CAs and DN subordination)

1993-09-21 15:35:00

Subject: Distinguished Names (DN) as used in PEM

I may be misunderstanding RFC 1422, however, I do not believe that the
RFC requires the DN of individual users to be "subordinate" to their
issuing CA's DN.  And I think it should not.  However, the Certificate
hierarchy can, as it does, impose "subordinate naming" restrictions
for the DNs used to identify the CAs in the hierarchy (except PCAs).

        I quote from RFC1422: Section 3.3.4 on Subject Name
        ... A distinguished name is an X.500 directory system
        concept and if a user is already registered in an X.500
        directory, his distinguished name is defined via that
        registration. ...

What are the chances that if I am already registered with X.500, my DN
will include some CA's DN (e.g. ...O=RSA-DSI-CA) ?  Not likely.

You can tell which CA I am registered under by looking at the "Issuer
Name" field in my certificate.  You don't need my DN to have an
attribute for my issuer CA.

I think that CAs should not become "Name Registers".  It is not their
business to manage uniqueness of DNs.  It is their business to verify
(as good as their policy states) that a user is really who s/he claims
to be and bind their identity to their public key by signing their
certificate.

Warning: From this point on, the discussion generalizes a bit away
-------- from PEM as PEM doesn't require a structure to users' DN.
--------
I was reading recent discussion on this group and with what I have
thought into the DN issue, I have not heard an ideal solution yet for
choosing a DN for individual users. This could be ok since we are not
in an ideal world.

I think acceptance and use of DNs are very much dependent on us coming
up with, and accepting, a global Name Registration mechanism which
ensures uniqueness *independent* of the format of the DN string
itself.  Any attempt to bind the DN format back to the Registration
Authority would be less than perfect because it would allow for the
existence of multiple DNs for a single individual which, to me, does
not make sense.  The mechanism should allow for multiple Registration
Authorities for practical purposes which must coordinate together to
ensure uniqueness of a single DN for each individual.

Even then, the DN format should not allow use of attributes that can
change or in any way imply the capabilities a user may have (not even
an organizational affiliation, to avoid its use for access control and
authorization).  Much less having the DN of a CA (as a name registration
authority) included in the  DN of users.  It would be nice if we
could separate the DN itself from the name registration auithority. 
There are several problems that are raised if one uses DN semantic to
make access control decisions or any thing else DNs are not meant for.
As i understand it, a DN is simply a unique way of identifying an
entity.

The *ideal* solution would be to have *one* name registry mechanism for
the planet earth and even then I think we may have problems when the
scientists discover the habitants of the planet Mars. :-)


**********************************
Let me ask these questions of you:
**********************************
Why should I (as one individual in planet Earth) have several DNs?  
Why should I not be able to use any one of my DNs to identify myself
wherever I need to do so?  If a single DN is truely Distinguished,
what is the need for more than one?



Verifying a DN is a separate issue. That is the question of looking
at a given DN and becoming certain that it refers to a particular
entity.  I don't know how the current string based DNs would provide a
good mechanism to verify a DN is valid/true.


*Disclaimer*
I do not speak for anyone but myself.  I apologize if I use the terms
'should' and 'must'.  I am only expressing an opinion.  I do not claim
to be an expert in all the standards related to X.500 DNs and PEM
RFCs.  Take my word as a conclusion based on what I know and read from
the messages passed back and forth on this group since 1993.  Please
feel free to correct me if you think I am wrong or am misunderstanding
an issue.  Constructive criticism is welcomed. 

_______________________________________________________________________
Alireza Bahreman                          E-Mail: 
bahreman(_at_)bellcore(_dot_)com
Bellcore, Room RRC-1K221                  Phone : +1 908 699 7398
444 Hoes Lane, Piscataway, NJ 08854       Fax   : +1 908 336 2943 

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