pem-dev
[Top] [All Lists]

"Eternal" DNs and uniqueIDs

1993-07-27 12:36:00
I've recently tried to get caught up on my PEM-DEV mail, and have
several questions regarding DNs that I haven't seen asked or an-
swered. (In case it isn't obvious, my primary concern is with validating
messages, including archived messages, rather than being concerned
with sending my encrypted mail to the right person.)

When, and for how long, must a Distinguished Name be globally
unique?

       1. At the moment it is assigned, and for as long as the
          operator of the X.500 directory service chooses to
          provide the listing, e.g., for as long as the individ-
          ual is a customer of the utility?
       2. For the duration of the current X.509 certificate (if
          any)?
       3. For as long as the individual is an employee or
          affiliate of the organization?
       4. Until the expiration of the statute of limitations for
          (pick your crime)?
       5. For 120 years after the birth of the individual in
          question?
       6. For 50 years after the death of the individual in
          question?
       7. Forever, or at least for the duration of the CA whose
          name forms part of that user's name under the name
          subordination rules?

What happens if two people have exactly the same name, and either
live at the same address or work within the same organization and
organizational unit, i.e., there is no reasonable qualifier that
can be used to distinguish between them. (Obviously this becomes
more of an issue as the duration of distinguished name uniqueness
becomes longer.)

       1. Force the individual to change his name, perhaps by
          adding a nickname.
       2. Arbitrarily invent a new qualifier to be applied to one
          of the other relative attributes, such as " L=123 Main
          St., upstairs bedroom," or "OU=Employee #123456"?

The 1993 version of X.500/X.509 allows the specification of a
uniqueID attribute, but it appears that no semantics have been
proposed. Does anyone know if the NADF is addressing this issue?

       1. Suppose that I register with both the Post Office and
          with GE Information Services, using my locality and
          street address for qualification. (I might want to do
          this because the Post Office and GEIS might operate
          under the auspices of two different PCAs, each with
          different policies.) Since I am the same person in both
          cases, shouldn't my DN, or at least the RDN component
          below the level of my CA's name, be the same in both
          cases? Who picks the uniqueID in this case? Will they
          be the same?
       2. Suppose that I change my name, whether through marriage
          or otherwise. What happens to the old name? Is there
          any way of correlating these two names to identify the
          same person (assuming that I want to, e.g., because I
          don't trust someone regardless of whether he or she has
          a new name?)

It may be too late, but I published a paper on integrity in 1988
that addressed the requirement for separation of duties and the
need for Discretionary Access Controls at the B3 level to exclude
particular individuals, and proposed a form of unique identifier
that would have solved all of these problems. I'll recast this
proposal using current terminology:

      1. Require the user who wishes to be certified to present
          his birth certificate to the Certification Authority
          (except in the case of persona certificates, where you
          can claim to be anyone you choose to be).
       2. The CA would extract the user's full legal name at
          birth, the mother's name, and the date, time, and place
          of birth from the birth certificate. (The implicit as-
          sumption is that this string would be guaranteed to be
          globally unique.)
       3. This information would be canonicalized in some speci-
          fied fashion (including the handling of foreign
          character sets and idiographs) to form an ASCII string.
       4. A standard hash algorithm such as MD5 would be applied
          to this string to reduce it to a convenient 128 bit
          uniqueID. 

As a result of this process, the unique ID would remain constant,
even across name changes. Any CA would be able to generate the
same unique ID for a given individual.  (There are some problems
that would have to be worked out with sealed adoption records,
the federal Witness Protection Program, and cases where the
original records don't exist or have been lost or destroyed. But
these could be solved by court order, if necessary.)

The probability that any two people born anywhere in the world
and at any time in recorded history would have the  same unique
ID can be computed using the Birthday Problem in statistics, but
it would still be less than 50% even  after 2^64 or 10**19 people
have been born. That should suffice until the next revision of
the standards, anyway.

I'd like to suggest that PEM adopt the use of the 1993 X.509 type
of unique ID qualifier as soon as possible, and that considera-
tion be given to using the above approach to generating them.

Robert R. Jueneman
Manager, Secure Systems
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
617/466-2603 FAX

<Prev in Thread] Current Thread [Next in Thread>
  • "Eternal" DNs and uniqueIDs, jueneman%wotan <=