NSA

Bridge Certification Authority Demonstration

Phase II

Directory Requirements

and

Architecture

### 

### 

14 April 2000

![](media/image1.png){width="4.147916666666666in"
height="0.9666666666666667in"}

Prepared by Entegrity Solutions

[1. Overview 2](#overview)

[2. Directory Protocols 2](#directory-protocols)

[2.1 Directory Client Protocols 2](#directory-client-protocols)

[2.2 Directory Server Protocols 2](#directory-server-protocols)

[3. Authentication Requirements 2](#authentication-requirements)

[3.1 Client Authentication 2](#client-authentication)

[3.2 Server Authentication 3](#server-authentication)

[4. DIT Layout 3](#dit-layout)

[5. Schema Requirments 3](#schema-requirments)

[5.1 End Entities 4](#end-entities)

[5.3.1 Attributes 4](#attributes)

[5.3.2 Object Classes 4](#object-classes)

[5.2 Ceritification Authorities 5](#ceritification-authorities)

[5.3.1 Attributes 5](#attributes-1)

[5.3.2 Object Classes 5](#object-classes-1)

[5.3 Attribute Authorities 6](#attribute-authorities)

[5.3.1 Attributes 6](#attributes-2)

[5.3.2 Object Classes 6](#object-classes-2)

[6. DSA Diagram 7](#dsa-diagram)

# 1. Overview

This document defines the directory schema and requirements of Phase II
of the BCA Pilot.

The Bridge Certification Authority (BCA) Pilot Phase II will use
directories to facilitate storage and retrieval of end entity
certificates, certification authority (CA) certificates, certificate
revocation lists (CRLs), attribute certificates, and security policy
information files (SPIFs). Standard profiles from the IETF Public-Key
Infrastructure (PKIX) Working Group and the ITU X.500 series of
recommendations will be required to promote interoperability among the
directory products used in this pilot.

# 2. Directory Protocols

## 2.1 Directory Client Protocols

Clients will access the pilot directories via Lightweight Directory
Access Protocol (LDAP) V2 and LDAP V3 \[RFC1777 and RFC 2251
respectively\]. The LDAP standard is currently being extended beyond
Version II to support new features, some of which are required for the
successful operation of a public key infrastructure (PKI). Where
applicable, these new features will be incorporated into the Bridge CA
pilot. For example, a standard way to post and retrieve binary objects,
such as certificates, is now available in LDAP V3. Support for binary
transmission of attributes is required for this demonstration. Also
required is adherence to RFC 2559 ( "Internet X.509 Public Key
Infrastructure Operational Protocols - LDAPv2").

## 2.2 Directory Server Protocols

The directory servers shall support LDAP V2 and LDAP V3 client access.
Optionally, the server may support the X.500 Directory Access Protocol
(DAP) for client access.

Support for ITU X.518 (1993) is required for server to server
communication (chaining). This standard defines procedures for
distributed operations through the Directory System Protocol (DSP). DSP
will be used for all server-to-server communications.

\<Protocol Diagram TBD\>

# 3. Authentication Requirements

## 3.1 Client Authentication

BCA directory clients that update the internal service and agency
directories are required to support either LDAP simple authentication or
X.509 Strong Authentication.

BCA directory clients that read the directory (read, list, search
directory operations) require no authentication (i.e. anonymous bind to
the directory is acceptable).

For purposes of security, the BCA border directories shall require X.509
strong authentication for update. The only client agents that will be
modifying the BCA border directories are the meta directory agents
(synchronizers) that publish data from the internal service or agency
directory out to the border directory.

## 3.2 Server Authentication

BCA directories are required to support simple authentication for LDAP
and X.500 DAP client access.

BCA directories are required to support simple authentication for server
to server chaining (X.518 DSP) communications.

\<Authentication Diagram TBD\>

# 4. DIT Layout

\<DIT Layout Diagram TBD\>

# 5. Schema Requirments

The schema required to support this demonstration is a mixture of
Entrust, ACP120, X.500, and the Internet X.509 Public Key Infrastructure
LDAPv2 Schema. The required attributes associated with each schema are
consistent with respect to syntax and semantics. If an interoperability
issue arises, the LDAPv2 schema shall be used to resolve it.

The following PKI related attributes are common to each of the schemas:

-   cACertificate

-   authorityRevocationList

-   crossCertificatePair

-   userCertificate

-   certificateRevocationList

-   userPassword

-   rfc822Mailbox

The cACertificate and crossCertificatePair attributes require special
attention when accessing the directory to build the certificate path.
Neither the PKIX specification nor the X.509 standards explicitly
provide an algorithm that may be used to construct a certificate path.
The PKIX LDAP-V2-schema provides guidance on what can be stored in the
specific attributes. The draft states the following about the
cACertificate attribute and the crossCertificatePair attribute:

> The cACertificate attribute of a CA\'s directory entry shall be used
> to store self-issued certificates (if any) and certificates issued to
> this CA by CAs in the same realm as this CA.
>
> The forward elements of the crossCertificatePair attribute of a CA\'s
> directory entry shall be used to store all, except self-issued
> certificates issued to this CA. Optionally, the reverse elements of
> the crossCertificatePair attribute, of a CA\'s directory entry may
> contain a subset of certificates issued by this CA to other CAs. When
> both the forward and the reverse elements are present in a single
> attribute value, issuer name in one certificate shall match the
> subject name in the other and vice versa, and the subject public key
> in one certificate shall be capable of verifying the digital signature
> on the other certificate and vice versa.
>
> When a reverse element is present, the forward element value and the
> reverse element value need not be stored in the same attribute value;
> in other words, they can be stored in either a single attribute value
> or two attribute values.
>
> In the case of V3 certificates, none of the above CA certificates
> shall include a basicConstraints extension with the cA value set to
> FALSE.

Based on the above statements, a path development algorithm must
consider that the CA's certificate must be stored in the
crossCertificatePair attribute, but the algorithm may consult the
cACertificate attribute first for performance reasons.

## 5.1 End Entities

### 5.3.1 Attributes

BCA end entity (EE) entries in the directory shall contain, as a
minimum, the following attributes:

1.  ***userCertificate*** as defined in 1997 X.509 (OID: 2.5.4.36)

2.  ***attributeCertificate*** as defined in 1997 X.509 (OID: 2.5.4.58)

3.  ***commonName*** as defined in 1997 X.521 (OID: 2..5.4.3)

4.  ***surname*** as defined in 1997 X.521 (OID: 2..5.4.4)

**NOTE:** The EE relative distinguished name (RDN) shall consist of the
***commonName*** attribute type and value. For example: cn=John Smith

### 5.3.2 Object Classes

BCA EE entries shall be made up of the following object classes:

1.  ***person*** as defined in 1997 X.521 (OID: 2.5.6.6)

2.  ***pkiUser*** as defined in RFC 2587: LDAPv2 Schema (OID: 2.5.6.21)
    for non-Entrust EEs \-- OR \-- ***entrustUser*** as defined in
    "Entrust Directory Schema Requirements" version 1.0, dated August,
    1998 (OID: 1.2.840.113533.7.67.0) for Entrust EEs.

3.  ***securePKIUser*** as defined in ACP 120 dated April 1999 (OID:
    2.16.840.1.101.2.2.3.66). This auxillary object class includes
    ***attributeCertificate*** and ***supportedAlgorithms*** as optional
    attribute types.

Optionally, BCA EEs may include the following object classes:

1.  ***organizationalPerson*** as defined in 1997 X.521 (OID: 2.5.6.7)

2.  ***inetOrgPerson*** as defined in IETF draft:
    draft-smith-ldap-inetorgperson-04.txt, dated 31 January 2000 (OID:
    2.16.840.1.113730.3.2.2)

## 5.2 Ceritification Authorities

### 5.3.1 Attributes

BCA CA (including PCAs and PAAs) entries in the directory shall contain
at a minimum the following attributes:

1.  ***commonName*** OR ***organizationalUnit*** as defined in 1997
    X.509 (OIDs: 2.5.4.3 and 2.5.4.11 respectively).

2.  ***cACertificate*** as defined in 1997 X.509 (OID: 2.5.4.37). As per
    the LDAPv2 Schema (RFC 2587), the cACertificate attribute shall be
    populated as follows:

> "The cACertificate attribute of a CA\'s directory entry shall be used
> to store self-issued certificates (if any) and certificates issued to
> this CA by CAs in the same realm as this CA."

3.  ***certificateRevocationList*** as defined in 1997 X.509 (OID:
    2.5.4.39)

4.  ***crossCertificatePair*** as defined in 1997 X.509 (OID: 2.5.4.40).
    As per the LDAPv2 Schema (RFC 2587), the crossCertificatePair shall
    be populated as follows:

> "The forward elements of the crossCertificatePair attribute of a CA\'s
> directory entry shall be used to store all, except self-issued
> certificates issued to this CA. Optionally, the reverse elements of
> the crossCertificatePair attribute, of a CA\'s directory entry may
> contain a subset of certificates issued by this CA to other CAs. When
> both the forward and the reverse elements are present in a single
> attribute value, issuer name in one certificate shall match the
> subject name in the other and vice versa, and the subject public key
> in one certificate shall be capable of verifying the digital signature
> on the other certificate and vice versa.
>
> "When a reverse element is present, the forward element value and the
> reverse element value need not be stored in the same attribute value;
> in other words, they can be stored in either a single attribute value
> or two attribute values."
>
> CAs entries in the directory may optionally contain the
> ***authorityRevocationList*** attribute as defined in 1997 X.509 (OID:
> 2.5.4.38).

**NOTE:** The CA relative distinguished name (RDN) shall consist of
either the ***commonName*** attribute type and value or the
***organizationalUnit*** attribute type and value. For example: cn=NSA
CA \-- OR \-- ou=ECA1

### 5.3.2 Object Classes

BCA CA entries shall be made up of the following object classes:

1.  ***pkiCA*** as defined in RFC 2587: LDAPv2 Schema (OID: 2.5.6.22)
    for non-Entrust CAs \-- OR \-- ***entrustCA*** as defined in
    "Entrust Directory Schema Requirements" version 1.0, dated August,
    1998 (OID: 1.2.840.113533.7.67.1) for Entrust CAs.

The base object class of BCA CAs shall be one (or more) of the
following:

1.  ***person*** as defined in 1997 X.521 (OID: 2.5.6.6)

2.  ***organizationalPerson*** as defined in 1997 X.521 (OID: 2.5.6.7)

3.  ***inetOrgPerson*** as defined in IETF draft:
    draft-smith-ldap-inetorgperson-04.txt, dated 31 January 2000 (OID:
    2.16.840.1.113730.3.2.2)

4.  ***organizationalUnit*** as defined in 1997 X.521 (OID: 2.5.6.5)

## 5.3 Attribute Authorities

### 5.3.1 Attributes

BCA attribute authority (AA) entries in the directory shall contain at a
minimum the following attribute(s):

1.  ***userCertificate*** as defined in 1997 X.509 (OID: 2.5.4.36)

2.  **spif** as defined in Rev C of SDN.702, dated 12 May 1999 (OID:
    2.16.840.1.101.2.1.5).

3.  ***commonName*** as defined in 1997 X.521 (OID: 2..5.4.3)

4.  ***surname*** as defined in 1997 X.521 (OID: 2..5.4.4)

For this phase of the BCA demonstration the
***attributeCertificateRevocationList*** (as defined in 1997 X.509; OID:
2.5.4.59) is not required. Attribute cerfificates shall be short lived
and therefore revocation is not an issue for this demo.

**NOTE:** The AA relative distinguished name (RDN) shall consist of the
***commonName*** attribute type and value. For example: cn=NSA Attribute
Authority

### 5.3.2 Object Classes

BCA AA entries shall be made up of the following object classes:

1.  ***person*** as defined in 1997 X.521 (OID: 2.5.6.6)

2.  ***pkiUser*** as defined in RFC 2587: LDAPv2 Schema (OID: 2.5.6.21)
    for non-Entrust EEs \-- OR \-- ***entrustUser*** as defined in
    "Entrust Directory Schema Requirements" version 1.0, dated August,
    1998 (OID: 1.2.840.113533.7.67.0) for Entrust EEs.

3.  ***organizationalRole*** as defined in 1997 X.521 (OID: 2.5.6.8)

Optionally, BCA EEs may include the following object classes:

1.  ***organizationalPerson*** as defined in 1997 X.521 (OID: 2.5.6.7)

2.  ***inetOrgPerson*** as defined in IETF draft:
    draft-smith-ldap-inetorgperson-04.txt, dated 31 January 2000 (OID:
    2.16.840.1.113730.3.2.2)

> **NOTE:** BCA Directory Servers containing AA entries shall implement
> the dMSOrganizationalRoleRule Content Rule (which is based on the
> organziationalRole structural object class) as defined in ACP 120
> dated April 1999. This content rule includes ***spif*** as an optional
> attribute type.

# 6. DSA Diagram

##