FBCA Prototype Test Results

Technical Interoperability Report for

VERSION

DRAFT PREPARED BY PROTIVITI GOVERNMENT SERVICES FOR GENERAL SERVICES ADMINISTRATION DRAFT 2 Table of Contents

1. BACKGROUND...... 3 1.1 TEST PLAN 3 2. DEMONSTRATION...... 3 3. TEST RESULTS...... 12 4. RECOMMENDATION...... 12

List of Tables

Table 1. CA Demonstration Results...... 4

Table 2. LDAP Directory Interoperability Demonstration Results...... 7

Table 3. X.500 Directory Interoperability Demonstration Results...... 10

DRAFT 1. Background The General Services Administration (GSA), as the Federal Public Key Infrastructure Management Authority (FPKIMA), has contracted with Protiviti Government Services to perform cross-certification testing using the FPKI Community Interoperability Test Environment (CITE) to: 1) identify and resolve potential incompatibilities between the Public Key Infrastructure (PKI) technologies of the Federal Bridge Certification Authority (FBCA) and applicant products, and 2) to minimize the risk of introducing incompatibilities with Certification Authorities (CAs) already in the Production FPKI. The Federal PKI Policy Authority (FPKIPA) authorized the FPKIMA to initiate testing with on . On , reached out to the FPKIMA Lab and a kickoff meeting was held on . performed two-way cross-certification of their prototype CA (DN: ) with the test FBCA. The directory product for this test was 1.1 Test Plan Operational requirements contained in the FBCA Certificate Policy were extracted and used as testing requirements. The following tables were developed to document test results and comments :

 Error: Reference source not found.

 Error: Reference source not found

 Table 3 - Error: Reference source not found

2. Demonstration

DRAFT Table 1. CA Demonstration Results

No. Requirement Description Test Description Test Results Comments

Certificates are compliant to the Generate X.509 v3 RFC2459 profile; certificates in compliance 1 verification using with attached certificate ListCertDetails profile. button in the Cert section.

FBCA CP OIDs may Assert, in the be specified in the certificatePolicies extension field policyMapping field [at least the certificate in the CertPolicy.file 2 policy ObjectIdentifier (OID) using Cert Policy being mapped to the FBCA button, so they are certificate policy OIDs]. included as certificate extension.

Map entity-specific levels of Agency-specific CPs assurance to the levels of (certificate policies assurance present in the OIDs) may be certificatePolicies extension mapped to the 3 field; that mapping will be corresponding FBCA expressed in the CPs using multiple policyMappings extension entries in the [of the cross-certificate policyMapping issued to the FBCA]. extension.

forwardCertificate, Export, at a minimum, the backwardCertificate reverse element [cross- and 4 certificates it has crossCertificatePair signed/issued] in DER are created during encoding. cross certification procedure.

CRLs are compliant to the RFC3280 Generate x.509v2 profile; verification 5 CARL/CRL in compliance using MS Cert with attached profile. Wizard (double click CRL.crl file).

DRAFT No. Requirement Description Test Description Test Results Comments

Support off-line posting to an X.500 LDAP v2 or better directory: Self-signed certificates 6 [Export self-signed certificates to a file as a DER-encoded object or in an LDIF file].

Support off-line posting to an X.500 LDAP v2 or better directory: All cross certificate 7 pairs generated [Export cross certificate pairs to files as DER-encoded objects or as an LDIF file].

Support off-line posting to an X.500 LDAP v2 or better directory: An Authority Revocation List (ARL) or Certificate Revocation Lists 8 (CRLs) covering certificates revoked. [Export Authority Revocation Lists (ARL) or Certificate Revocation Lists (CRLs) as DER-encoded objects or as an LDIF file.].

Generate and sign certificates All certificates have contain X.500 DN [where the DNs which includes 9 issuer DN consists of the C, O, and OU X.520 following X.520 naming attributes. elements: C; O; and OU].

All certificates have Generate and sign certificates DNs which in contain X.500 DCN elements addition to C, O, and [where the subject DN OU X.520 attributes contains X.520 naming contain also CN 10 elements (at least C, O, and attribute which may OU), the domain component be used for the naming element (dc), or a common name or combination of the two]. domain component name.

nameConstraints Generate and sign certificates extension is specifid 11 that have name constraints in the CertPolicy.file asserted. and included in the certificate.

Certificates are Revoke a certificate by revoked either placing its serial number and manually (Revoke reason for revocation on a function) or CARL/CRL. Revoked automatically when 12 certificates shall be included generating new on all new publications of the CertRequests. They certificate status information are included in all until the certificates expire. new CRLs until their expiration.

Certificate requests Receive the FBCA request in can be exported / 13 a secure, out-of-band fashion imported, thus to effect certificate issuance. transfer it in a secure out–of–band fashion.

Exchange PKCS7/10 certificate request/response messaging formats: generate CertRequests are PKCS7/10 certificate created and exported requests and responses and as PKCS10 files and 14 export them to other CAs as certificate replies (cert files; and import and process chains) are created as PKCS7/10 certificate PKCS7 files requests and responses received as files from other CAs.

All certificates issued by the FBCA shall use at least 1024 RSA with SHA-1 bit RSA or DSA, with Secure 15 required for initial Hash Algorithm version 1 test. (SHA-1) (or better), in accordance with FIPS 186.

Public key parameters prescribed in the Digital Not required for 16 Signature Standard (DSS) initial test. shall be generated in accordance with FIPS 186.

CAs that generate certificates and CRLs under this policy shall use SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 hash algorithm 17 when generating digital signatures. Signatures on certificates and CRLs that are issued after 12/31/2010 shall be generated using, at a minimum, SHA-224.

Public key parameters prescribed in the Digital 18 Signature Standard (DSS) shall be generated in accordance with FIPS 186.

Table 2. LDAP Directory Interoperability Demonstration Results

No. Requirement Description Test Description Test Results Comments

cACertificate attribute shall be used to store and include all Verify that more self-issued certificates (if any) than one value can 1 and certificates issued to this be stored in the CA by CAs in the same realm attribute. as this CA.

Forward elements of the Verify that more crossCertificatePair attribute of than one value can 2 a CA's directory shall be used be stored in the to store all, except self-issued attribute. certificates issued to this CA.

The reverse elements of the Verify that more crossCertificatePair attribute of than one value can 3 a CA's directory entry must be stored in the contain a subset of certificates attribute. issued by this CA to other CAs.

When both the forward and reverse elements are present in a single attribute value, issue name in one certificate shall match subject name in the other 4 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.

CA certificates shall NOT include a basicConstraints 5 extension with the cA value set to FALSE.

CA entries shall be made up of entrustCA is used to 6 the following object classes: support Entrust - pkiCA OR entrustCA. implementations.

An entity's directory service must conform to the following 7 requirements: - Must support LDAP v3 referrals.

Any LDAP directory shall provide all CA certificates and 8 CRLs within its domain or provide references to these.

Directories are required to 9 support authentication for LDAP communications.

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

The LDAP service shall provide at minimum a Lightweight Directory Access 11 Protocol (LDAP) interface at the port 389, supporting both LDAP versions 2 and 3.

The directory service shall provide an average three Request a certificate second response time (or less) that is contained in 12 from the time the directory the directory to receives the request until it check response time. delivers the response to the network.

authorityRevocationList Shall include all CRLs issued by the provider’s CA containing the 13 Issuing Distribution Point (IDP) extension with onlyContainsCACert set to TRUE.

certificateRevocationList shall include all CRLs issued by the provider’s CA that are not 14 required to be in the authorityRevocationList attribute.

DRAFT Table 3. X.500 Directory Interoperability Demonstration Results

Test Description No. Requirement Description Test Results Comments 1 At a minimum, the directories are required to store and disseminate the following PKI related attributes:

- commonName OR organizational Unitname - caCertificate - certificateRevocationList - authorityRevocationList - crossCertificatePair - userCertificate - rfc822Mailbox 2 CA Certificate attribute shall be issued to store self-issued certificates (if any) and certificates issued to this CA by CAs in the same realm as this CA 3 Forward elements of the crossCertificatePair attribute of a CA’s directory shall be used to store all, except self- issued certificates issued to this CA. 4 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 5 When both the forward and reverse elements are present in a single attribute value, issue name in one certificate shall match 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

DRAFT Test Description No. Requirement Description Test Results Comments 6 The CA relative distinguished name (RDN) shall consist of either the commonName attribute type and value or the organizationalUnitName 7 CA entries shall be made up of the following object classes:

- pkiCA OR entrustCA - person - organizationalPerson - inetOrgPerson - organizationalUnit 8 An entity’s directory service must conform to the following requirements:

- Information must conform to the X.500 information model and X.509 - Information must conform to one of the namespace strategies (X.500 or DNS) - Must support X.500 chained operations, X.500 referrals, or LDAP v3 referrals 9 If the entity chooses to use X.500-based directory services, its directories must conform to the name space: c=US, o=U.S. Government 10 X.500 and LDAP allow for multi-value attributes, so commonName attribute could contain more than one RDN 11 The DSA will support the traditional X.500 DIT…the “de-facto” Internet DNS directory structure, as well as the hybrid DITs… 12 For agencies that use X.500 DSAs for their directory service…Each entity border directory will be chained to the FBCA directory via DSP chaining

DRAFT Test Description No. Requirement Description Test Results Comments 13 Directories are required to support simple authentication for LDAP and DSP communications [this document proposes that for DSP no authentication be used] 14 FPKI directory clients that read the FPKI directory (read, list, search directory operations) require no authentication (i.e…., anonymous bind to the directory is acceptable)

3. Test Results

4. Recommendation The FPKIMA recommends that upon approval for cross certification with the FBCA, the FPKI Directory be configured to chain to the Directory.