# Federal PKI Directory Interoperability Agency Requirements

This document is based on the discussion at the Nov 14 TWG meting and
summarizes our understanding of the requirements for FPKI directory
interoperability in an environment where some agencies use \"X.500
directory service agent\" servers and others use \"LDAP\" servers.

# Classes of Directory Server Products

Roughly speaking all current directory server products implement LDAP v3
as the normal means of accessing the directories, and all PKI clients
expect to use LDAP to access objects; for PKI those are certificates and
CRLs. However two classes of directory servers exist:

-   *X.500 Directory Service Agent (DSA)*: X.500 DSAs support LDAP
    access and also support the X.519 Directory Services Protocol (DSP)
    for chaining DSA\'s together, so that a directory can directly
    access data in another directory server for a client. This is
    transparent to the client and the client doesn\'t know what DSA the
    data comes from;

-   *LDAP server*: An LDAP server, like the X.500 DSA, implements LDAP
    access, but, if it implements chaining, the LDAP server does so by a
    proprietary protocol only to other servers from the same
    manufacturer, or by "chaining" additional LDAP queries. The normal
    paradigm for LDAP servers is that, when they are sent a query they
    cannot satisfy, they may return an LDAP v3 referral to another
    server (possibly a Registry of Directories) to the client, which
    then may repeat the query to the referred server.

# Making Agency Certificates and CRLs available

To cross-certify with the Federal Bridge CA, an Agency or other entity
must make, at a minimum, its CA certificates and CRLs available to the
Federal Bridge Directory so that they can be accessed by all members of
the Federal PKI and cross-certified entities. Agencies may optionally
choose to make end entity certificates as well. There are two ways
agencies can choose to make certificates and CRLs available:

-   *X.500 DSA realm*: chain an X.500 DSA that contains the needed
    certificates and CRLs to the Federal Bridge DSA using the X.519 DSP
    protocol[^1], or ;

```{=html}
<!-- -->
```
-   *LDAP server realm:* make an LDAP server that contains the
    certificates and CRLs to be made public openly accessible from the
    Internet.

There are many variations on how to configure X.500 DSAs and LDAP
servers for FBCA interoperability, involving the placement of the
servers with respect to firewalls and internal servers. We expect that
most agencies will choose to use a \"border\" directory server in either
case above, that contains or makes available only some subset of the
contents of the internal directory, but separate border directories and
their placement with respect to firewalls is an agency security policy
decision and not a requirement for FBCA interoperability.

# Agency Client Access to Certificates and CRLs

The issue of how relying party clients then access the directory is a
separate one, but it is at least indirectly related to the choice of how
agencies make certificates externally available. All clients that are to
make use of the FBCA as relying parties must be capable of using LDAP v3
queries to find and process complex certification paths through the
bridge from certificates and CRLs in a directory.

We expect that the normal paradigm for agencies in the X.500 DSA realm
will be for clients to query (via LDAP v3) the X.500 DSA that is chained
to the FBCA directory. While the bridge DSA might theoretically return
an LDAP referral through the chaining process to the client, we assume
here that the client is either returned the set of certificates (or
CRLs) that satisfy the query, or a failure. This then imposes additional
requirements on the FBCA directory server itself.

In the LDAP server realm, we expect that the most common arrangement
would be for a client to query its internal directory and, if it is not
an internal certificate or CRL, that server would return a referral to
the client to either a \"directory of directories\" or the FBCA
directory server, which the client would then query. Some agencies in
the LDAP server realm might not wish to allow their desktops to do
unrestricted LDAP queries and might choose to interpose a single proxy
for these queries, but this does not change the basic model.

# FBCA Directory Requirements

The FBCA Directory is currently an X.500 DSA, chained to the four X.500
DSA realms of the agencies that have cross-certified with the FBCA.
Today, there are no LDAP server realms that have cross-certified with
the bridge, but we believe that there are a number of LDAP server
oriented agencies that would prefer to use an LDAP server as a border
directory. At the moment, there is no external access to the FBCA DSA
except through the chained directories, or, indeed, to any of the border
directories. The overall FBCA directory is now effectively a \"closed
club\" to which only the current four agencies belong, because only
those with access to the four agency border DSAs can access the FBCA
directory. However we wish to cast the FBCA net as widely as practical
and to cross-certify with agencies and non-Federal entities such as the
Higher Education Bridge CA that are LDAP server realms and do not use
X.500 DSA.

To enable access to certificates and CRLs from LDAP realms, the FBCA DSA
must be chained to a bridge border DSA, outside the bridge firewall, or
be moved itself outside the firewall, or the contents of the entire
X.500 server realm must be mirrored by an externally available server,
so that LDAP queries from those outside the X.500 DSA realm are
possible. This will allow LDAP server realm clients to obtain
certificates and CRLs from the X.500 Realm.

We expect that most, if not all, PKI clients that can build and process
certification paths can also handle LDAP v3 referrals, however we do not
think that we can assume that all or most of the X.500 servers (DSA\'s)
in the X.500 DSA realm, that are chained via DSP to the Bridge DSA, are
capable of passing an LDAP v3 referral back from the FBCA DSA to an LDAP
client. Moreover, a great deal of testing and experimentation would be
needed to verify that all of the different makes and models of DSAs in
use in agencies that use X.500 DSP chaining can return LDAP V3
referrals. And finally, although the clients may be capable of
processing referrals, the default installation where an X.500 directory
is used is often to turn off referrals, so many existing clients that
could do referrals will require manual reconfiguration to enable the
feature.

Therefore, in order to allow X.500 realm relying party clients to find
certificates and CRLs held in the LDAP servers realm, the FBCA directory
must add a capability for bridging between DSP and LDAP, and at least
two such solutions have putatively been identified:

-   the current FBCA X.500 DSA connected to the NEXOR DSP-LDAP connector
    in conjunction with the MaXware LDAP gateway;

-   alternatively FBCA DSA could be replaced or augmented by an X.500
    DSA with a built in LDAP connector such as the Authera Safe Pages,
    and similar products offered by Critical Path and Syntegra.
    \[Others\]

These or similar products would enable conversion of a chained DSP query
to an LDAP query and allow clients in X.500 realms to access
certificates and CRLs in the LDAP realms.

At the moment there are no LDAP realms in the Federal PKI. We need to
cross-certify an LDAP realm and to create a test scenario to demonstrate
bilateral interoperability across the two realms. Although we may
discover by testing that all X.500 DSAs currently in use by cross
certified Agencies can pass LDAP v3 referrals back to clients, we do not
presume that, and tentatively expect to use an LDAP connector or X.500
DSA with an integral connector for this purpose. A logical first
candidate for an LDAP realm cross-certification is the Higher Ed PKI,
which is entirely LDAP based, however any agency that wishes to do an
LDAP server border directory is welcome to participate, if we can
identity an agency LDAP adaptor pioneer. NIST will arrange a small
working meeting to discuss this in detail (probably the 2^nd^ or 3rd
week of January).

[^1]: Note that an agency that chains an X.500 border directory to the
    FBCA DSA might actually use an LDAP server internally, what matters
    here is how certificates are made available to FPKI relying parties
    outside the agency.