>From: sead(_at_)dsv(_dot_)su(_dot_)se (Sead Muftic)
>Subject: Re: IPRA Functions
>Date: Tue, 07 Feb 1995 12:11:11 +0100
>
>Dear Peter:
>
>Here is an ATTEMPT to answer/clarify your questions, keeping in mind
>that our first, fully operational PEM/CMS (Certificate Management System)
>is (hopefully) (a) PEM RFC compliant and (b) open for suggestions and
>improvements.
>>Our CA operates (already) in multiple PCA domains, each with a separate
>>key pair and CA certificate; the user certificates are already issued. (i
>>doubt we would incur the costs of reissuing certificates)
>
>
>How do you provide/guarantee the uniqueness of DNs ? Does your CA
>has two separate DNs under each PCA or ...
Here is some practical experience of doing it. its the
centralized database solution.
The CA has a single unambiguous DN; there is only 1 CA, representing
just one organizational unit; it exists to vouch for the identities of
local affiliated entities. Why would it have more than one DN?
(rhetorical question).
Under PEM rules, obviously, to satisfy the services PEM 142* users are
guaranteed, any CA we operate which directly signs up to a PCA has a
separate key pair and CA certificate to any other CA certificate it
holds.
Local procedures for CA proofing ofDN uniqueness are very simple to
implement, being guaranteed by a conformant implementation of X.500 DAP
responder we procured, and operate in a non-distributed fashion. We
register users in the Directory, as an outgrowth of std personel
procedures. (The personel maintained database automatically updates the
X.500 registration DIB periodically, creating, deleting and modifying
entities appropriately).
This is an authoritiative and protected source of information, which
provides the DN of the entries which describe registered entities. We
know that the (X.500 conformant) DSA service cannot start if there are
two entries of identical name in the DIB. So, if the service is
present, the entry names are unambiguous, and locally unique.
The CA hit the directory with a minimal read, which transforms the Name
of the user, based on identifying attributes he/she cares to nominate
to the CMS representative in his/her workgroup) into the
directory-registered distinguished Name. The result of this transaction
is authenticated strongly, or the operation fails. The notary passes
any signed result to the CMS as proof of having been named AND
registered by the organizational Naming Authority (operated by
personel, and proofed by the on-line naming authorization result
provided by the registration DSA.)
Though the CMS is directory independent - knowing little of OSI or
X.500 - its simple to implement a proof validation process based on the
signed read result, which ensures that the origin is authorized to be a
NA/DSA for this CMS, and authenicated, and the user Name bytes are
easily identified, and can be trusted to be DER encoded. The BBN box,
or local equivalent hardware CSU, does the rest of the hard work to
sign a simple-to-encode certificate.
Having the minimal read transfer of DAP operations over TCP/IP,
including the signature for the results, isnt hard - the so-called mdap
protocol. Personally speaking, rather than as a NASA contractor, in
collaboration with an NSA program, we have done the secure mdap
experimentally to obtain the required lighter weight design of the
access protocol. The service is the same, providing the properties
desired for this important function.o
Basciallu it comes down to X.500, without the OSI.
Peter.