**FPKI CPWG Mapping Comparison Matrix**

**Citizen & Commerce Certificate Policy (C4)**

**Requirements**

**Mapping Matrix For Cross Certification**

Version 6.0 March 2008

Table of Contents

[1.0 INTRODUCTION 3](#introduction)

[2.0 PKI SUMMARIES 3](#pki-summaries)

[3.0 ASSESSMENT 5](#assessment)

[4.0 DETAILED ASSESSMENT 6](#detailed-assessment)

[5.0 REFERENCES 9](#references)

[6.0 CONTACT DETAILS 9](#contact-details)

# 

# 

#  

# **1.0 INTRODUCTION**

The purposes of this certificate policy comparison, in relation to the
comparison study conducted with the ENTITY CP \[2\] and the C4 CP \[3\],
are:

> 1\) To identify at a high-level the areas of inconsistency and/or
> similarity between the contents of these two Certificate Policy (CP)
> documents to cross certify at a Basic Level of Assurance, and
>
> 2\) To recommend appropriate changes, if required, to the ENTITY CP
> \[2\] that would make it more consistent with the C4 CP \[3\].

This document is organized to achieve these purposes in the following
sections:

> 1\) **PKI SUMMARIES**, which provides a high-level overview of the
> PKIs represented by the Certificate Policies being compared in this
> analysis; and
>
> 2\) **DETAILED ASSESSMENT**, which presents a detailed breakdown of
> the requirements in the C4 CP, section by section, and categorizes the
> degree of similarity of the ENTITY CP to the C4 CP. Comments to
> explain the rationale for the degree of similarity are also provided,
> where necessary. The topical and organizational framework used as a
> basis for this comparison is Request for Comments (RFC) 3647, the
> Internet X.509 Public Key Infrastructure Certificate Policy and
> Certification Practices Framework \[1\].

# **2.0 PKI SUMMARIES**

The Citizen and Commerce Class Common Certificate Policy defines
requirements for certificates accepted by the U.S. Federal Government
for the purpose of authenticating citizens and commercial enterprises
for many electronic services.

The General Services Administration (GSA), under the auspices of the
Federal Public Key Infrastructure Policy Authority (FPKIPA) operates the
C4CA. In order to promote interoperability and the appropriate use of
certificate policies, the C4CA has issued a minimum set of operational
requirements that support trust path creation and verification of
digital certificates. The C4CA will issue cross-certificates to other
autonomous Principal CAs, and then only when authorized by the FPKIPA.
Initially, autonomous CA's that operate in trust domains that meet the
requirements established by the FPKIPA will be eligible to cross-certify
with the C4CA.

When the Applicant is determining whether to rely on a certificate
issued by another agency or party, it is not required to use the mapping
expressed in the C4 certificates. The Applicant, at its sole discretion,
may choose to use a separate mapping for certain transactions or for all
transactions.

The ENTITY CP operates a PKI to provide security for its electronic
information. The ENTITY CP consists of products and services that
provide and manage X.509v3 certificates for public-key cryptography. An
ENTITY CP digital certificate identifies the individual named in the
certificate requestor/holder, and binds that person to a unique
public/private key pair.

Programs that carry out or support ENTITY CP missions may require the
type of security services provided by a PKI such as authentication,
confidentiality, encryption, non-repudiation, and access control. These
services are met with an array of network security components such as
web servers, guards, firewalls, routers, and trusted database servers.
The operation of these components is supported and complemented by use
of public-key cryptography. As a system solution, the components share
the burden of the total system security. The use of public key
certificates does not add any security services in a poorly designed or
implemented system. The reliability of the public-key cryptography
portion of the security solution is a direct result of the secure and
trustworthy operation of an established PKI, including equipment,
facilities, personnel, and procedures.

The ENTITY CP Certificate Policy (CP) follows and complies with the
Internet Engineering Task Force (IETF) Request for Comment (RFC) 3647,
X.509 PKI CP and Certification Practices Framework. The ENTITY CP
defines the primary obligations and operational responsibilities of all
ENTITY CP program participants, and defines the creation, management and
use of X.509 Version 3 digital certificates. The ENTITY CP defines the
applicability of assurance levels for the protection of information
based on its value or sensitivity, the risk and the consequences of
loss, disclosure or modification.

#  

# **3.0** **ASSESSMENT**

The following seven evaluation terms and their definitions, listed in
order of degree of conformity, were used to assess the ENTITY CP
alignment to the C4 CP elements:

1)  **Exceeds** - The ENTITY CP policy provides a higher level of
    assurance/security than the C4 CP requirement

2)  **Equivalent** - The ENTITY CP policy provides exactly the same
    assurance/security as the C4 CP requirement.

3)  **Comparable** - The ENTITY CP contains dissimilar policy contents,
    but provides a comparable level of assurance to meet the security to
    the C4 CP requirement.

4)  **Partial** - The ENTITY CP contains policy that is comparable, but
    it does not address the entire C4 CP requirement.

5)  **Not Comparable** - The ENTITY CP contains dissimilar policy
    contents, which provides a lower level of assurance/security than
    the C4 CP requirement.

6)  **Missing** - The ENTITY CP does not contain policy contents that
    can be compared to the C4 CP requirement in any way.

7)  **N/A** -- Not Applicable to ENTITY CP or required for C4 cross
    certification.

# **4.0 DETAILED ASSESSMENT**

This section of the report presents the mapping comparison results for
the C4 CP and the ENTITY CP. The following tables contain the specific
requirements for mapping to the C4 CP. The mapping comparison is
characterized using the evaluation terms listed in the
[ASSESSMENT](#section-3).

The detailed mapping results provide the C4 CP requirements to be
mapped, the applicable policy text from the ENTITY CP, the overall
evaluation result for each requirement element addressed by the ENTITY
CP, as well as comments that will clarify the evaluation result and
suggest recommendations for improvement of that particular section in
the ENTITY CP. By default, the evaluation results listed in the "Overall
Match" field indicates all results when multiple policy elements from
the ENTITY CP are mapped to a particular C4 CP requirement.

+-----+--------------+-------------------------------------------------+
| Ta  | **CP         | Mapping Phrase                                  |
| ble | Section**    |                                                 |
| No. |              |                                                 |
+=====+==============+=================================================+
| 1   | **C4 CP:**   | Entities must designate the person or           |
| .   |              | organization that asserts that their CPS(s)     |
|     | **1.5.3**    | conforms to their CP(s).                        |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      | Comments:                                       |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 2   | **C4 CP:**   | Entity PKIs are responsible for operation of    |
| .   |              | repositories to support their PKI operations    |
|     | **2.1**      |                                                 |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      |                                                 |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 3   | **C4 CP:**   | At a minimum, the Entity repositories shall     |
| .   |              | make CA certificates and CRLs issued by the     |
|     | **2.4**      | Entity PKI and CA certificates issued to the    |
|     |              | Entity PKI available to Federal relying         |
|     |              | parties.                                        |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      |                                                 |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 4   | **C4 CP:**   | The CA is responsible for ensuring the          |
| .   |              | uniqueness of certificate subject names for all |
|     | **3.1**      | certificates issued by that CA. Under no        |
|     |              | circumstances shall additional certificates     |
|     |              | containing the same subject name be issued to a |
|     |              | different subscriber (person, role, or          |
|     |              | organization).                                  |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      |                                                 |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 5   | **C4 CP:**   | The identity may be established in any of the   |
| .   |              | following manners:                              |
|     | **3.2**      |                                                 |
|     |              | 1\. The identity may be established through     |
|     |              | in-person appearance at the credential          |
|     |              | provider, or its agent, with physical           |
|     |              | credentials (e.g., driver\'s license or birth   |
|     |              | certificate).                                   |
|     |              |                                                 |
|     |              | 2\. The identity may be established using       |
|     |              | procedures similar to those used when applying  |
|     |              | for consumer credit and authenticated through   |
|     |              | information in consumer credit databases or     |
|     |              | government records, such as:                    |
|     |              |                                                 |
|     |              | \- the ability to place calls from or receive   |
|     |              | phone calls at a given number; or               |
|     |              |                                                 |
|     |              | \- the ability to obtain mail sent to a known   |
|     |              | physical address.                               |
|     |              |                                                 |
|     |              | 3\. Where an ongoing business relationship with |
|     |              | the credential provider or a partner company    |
|     |              | (e.g., a financial institution, airline, or     |
|     |              | retail company) exists, the identity may be     |
|     |              | authenticated through information derived from  |
|     |              | the business relationship such as:              |
|     |              |                                                 |
|     |              | \- the ability to obtain mail at the billing    |
|     |              | address used in the business relationship; or   |
|     |              |                                                 |
|     |              | \- verification of information established in   |
|     |              | previous transactions (e.g., previous order     |
|     |              | number); or                                     |
|     |              |                                                 |
|     |              | \- the ability to place calls from or receive   |
|     |              | phone calls at a phone number used in previous  |
|     |              | business transactions.                          |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      |                                                 |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 6   | **C4 CP:**   | When a request to revoke a certificate is       |
| .   |              | received, the CA is responsible for             |
|     | **3.4**      | authenticating the identity of the requester.   |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      |                                                 |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 7   | **C4 CP:**   | This policy requires CAs to maintain and        |
| .   |              | distribute certificate status information until |
|     | **4.9**      | certificate expiration. When a certificate\'s   |
|     |              | status changes, the new status must be          |
|     |              | available to relying parties within 72 hours.   |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      |                                                 |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 8   | **C4 CP:**   | Certificate status information must be          |
| .   |              | distributed using at least one of the following |
|     | **4.9**      | mechanisms: X.509 CRLs; or the Online           |
|     |              | Certificate Status Protocol (OCSP). If a        |
|     |              | certificate is not covered by an X.509 CRL, the |
|     |              | certificate must explicitly specify the         |
|     |              | authoritative OCSP server using the Authority   |
|     |              | Information Access extension.                   |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      |                                                 |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 9   | **C4 CP:**   | CA private keys are never escrowed.             |
| .   |              |                                                 |
|     | **4.12**     |                                                 |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      |                                                 |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 1   | **C4 CP:**   | The CA shall take adequate measures to ensure   |
| 0.  |              | the security of its operations.                 |
|     | **5.0**      |                                                 |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      |                                                 |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 1   | **C4 CP:**   | CAs and CSSes shall generate private keys used  |
| 1.  |              | to sign certificates and certificate status     |
|     | **6.1.1**    | information in cryptographic modules validated  |
|     |              | against FIPS 140 Level 2 (or higher).           |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | [Overall     | Comments:                                       |
|     | Ma           |                                                 |
|     | tch:]{.mark} |                                                 |
+-----+--------------+-------------------------------------------------+
| 1   | **C4 CP:**   | CAs and CSSes that generate certificates, CRLs, |
| 2.  |              | and other status information (e.g., OCSP        |
|     | **6.1.5**    | responses) under this policy shall use          |
|     |              | signature keys of at least 1024 bits for RSA or |
|     |              | DSA, and at least 160 bits for ECDSA.           |
|     |              | Certificates, CRLs, and other status            |
|     |              | information that expire after 12/31/2011 shall  |
|     |              | be generated with at least a 2048 bit RSA or    |
|     |              | DSA key, or at least 224 bits for ECDSA.        |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      | Comments:                                       |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 1   | **C4 CP:**   | CAs and CSSes that generate certificates, CRLs, |
| 3.  |              | and other status information under this policy  |
|     | **6.1.5**    | shall use the SHA-1, SHA-224, SHA-256, SHA-384, |
|     |              | or SHA-512 hash algorithm when generating       |
|     |              | digital signatures. Signatures on certificates, |
|     |              | CRLs, and other status information issued after |
|     |              | 12/31/2011 shall be generated using, at a       |
|     |              | minimum, SHA-224.                               |
+-----+--------------+-------------------------------------------------+
|     | []{.mark}    |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      | Comments:                                       |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 1   | **C4 CP:**   | End entity certificates that expire before      |
| 4.  |              | 12/31/2013 shall contain public keys that are   |
| []{ | **6.1.5**    | at least 1024 bits for RSA, DSA, or             |
| .ma |              | Diffie-Hellman, or 160 bits for elliptic curve  |
| rk} |              | algorithms. End entity certificates that expire |
|     |              | on or after 12/31/2013 shall contain public     |
|     |              | keys that are at least 2048 bits for RSA, DSA,  |
|     |              | or Diffie-Hellman, or 224 bits for elliptic     |
|     |              | curve algorithms.                               |
+-----+--------------+-------------------------------------------------+
|     | []{.mark}    |                                                 |
+-----+--------------+-------------------------------------------------+
|     | Overall      | Comments: :                                     |
|     | Match:       |                                                 |
+-----+--------------+-------------------------------------------------+
| 1   | **C4 CP:**   | CA certificates issued under this policy are    |
| 5.  |              | required to include the key usage extension.    |
|     | **6.1.7**    | Certificates containing CA public keys that are |
|     |              | used to verify certificates shall assert        |
|     |              | keyCertSign; certificates containing            |
|     |              |                                                 |
|     |              | CA public keys that are used to verify CRLs     |
|     |              | shall assert cRLSign.                           |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | [Overall     | []{.mark}                                       |
|     | Ma           |                                                 |
|     | tch:]{.mark} |                                                 |
+-----+--------------+-------------------------------------------------+
| 1   | **C4 CP:**   | CA and CSS private keys used to sign            |
| 6.  |              | certificates and certificate status information |
| []{ | **6.2**      | shall be maintained in cryptographic modules    |
| .ma |              | validated against FIPS 140 Level 2 (or higher). |
| rk} |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | [Overall     | []{.mark}                                       |
|     | Ma           |                                                 |
|     | tch:]{.mark} |                                                 |
+-----+--------------+-------------------------------------------------+
| 1   | **C4 CP:**   | This policy requires issuance of X.509 version  |
| 7.  |              | 3 certificates.                                 |
| []{ | **7.0**      |                                                 |
| .ma |              |                                                 |
| rk} |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | [Overall     | Comments:                                       |
|     | Ma           |                                                 |
|     | tch:]{.mark} |                                                 |
+-----+--------------+-------------------------------------------------+
| 1   | **C4 CP:**   | This policy requires subscribers to inform the  |
| 8.  |              | CA if they believe their private key(s) have    |
|     | **9.6.3**    | been compromised, stolen, or lost.              |
+-----+--------------+-------------------------------------------------+
|     |              |                                                 |
+-----+--------------+-------------------------------------------------+
|     | [Overall     | Comments:                                       |
|     | Ma           |                                                 |
|     | tch:]{.mark} |                                                 |
+-----+--------------+-------------------------------------------------+

# 

# **5.0 REFERENCES**

\[1\] Request for Comments (RFC): 3647; Internet X.509 Public Key
Infrastructure Certificate Policy and Certification Practices Framework.

\[2\] X.509 Certificate Policy For the Entity CA XX, Version XX, dated
XX

\[3\] Citizen and Commerce Class Common Certificate Policy (C4CA),
<http://www.cio.gov/fpkipa/documents/citizen_commerce_cp.pdf>

# **6.0 CONTACT DETAILS**

Comments about this document may be sent to the following people:

Brant Petrick 202-208-4673 <brant.petrick@gsa.gov>