RAPIDPIV-I Credential Service Certification Practice Statement Redacted

(1)

RAPIDPIV-I™ Credential Service

Certification Practice Statement -

Redacted

Key Information:

Formal title: Eid Passport, Inc. RAPIDPIV-I™ Credential Issuing and Management Service X.509 Certification Practice Statement - Redacted

Principal Policy OID: 1.3.6.1.4.1.38948.2.1.1

{ iso (1) org (3) dod (6) internet (1) private (4) enterprise (1)

eidPassportInc (38948) eidPMA (2) eidPolicies (1) eidRAPIDPIV-I (1) }

URL http://www.eidpassport.com/about-us/policies

Filename Eid Passport RAPIDPIV-I CPS v1.2-Redacted.PDF Responsible authority: Eid Passport Policy Management Authority (EPMA)

Version: Redacted Release; v 1.2

James D.

Campbell

James D. Campbell

DN: c=US, cn=James

D. Campbell

Date: 2014.06.18

10:45:03 -07'00'

(2)

Effective date: April 2014; Classification /

Distribution Company confidential / Hosting on Eid Passport website for public release Point-of-Contact: Eid Passport

Eid Policy Management Authority 5800 NW Pinefarm Pl,

Hillsboro, OR 97124 United States of America email: [email protected] phone: +1 503-924-5373

(3)

(4)

APPROVALS

Each formal release of this Certification Practice Statement (CPS) requires approval by the Eid Passport Policy Management Authority.

Approval control:

Version identification has three levels requiring the approval authority identified below according to level. Version identification is a simple integer sequencing at each level.

Version: A formal release of this CPS which has a significant policy change requiring a vote by the EPMA to approve;

Sub-version: A formal release of this CPS which has a no significant policy change and therefore does NOT require a vote by the EPMA to approve;

Draft: A draft of this CPS intended for review and/or recommendation as the next formal release.

When the identification at a given level is incremented all subordinate levels revert to zero. Only the first two levels need be shown in formal releases (level three is by default zero in any formal release). During the drafting of revisions this record records all draft versions and their approvals until such time as a formal release is approved. Records of ALL past drafting releases are preserved within the EPMA for archival purposes.

On its effective date a formal version of this CPS becomes the applicable version of the policy for all operational purposes and supersedes all previous versions which thereby become redundant. The EPMA preserves records of all past versions.

Approval authorities:

Top-level: Eid Passport PMA; Second level: As top-level;

Third level: Author / Editor – for informal PMA member and development / editorial team review.

Approval record:

Version Approval date Summary of Changes

0.0.1 2012-07-24 Initial Rough Draft

0.0.2 2012-08-24 Draft Ready for Compliance Audit 0.0.6 2012-10-1 Final Compliance Audit Draft 1.0 2012-10-24 Official Version

1.1 2013-07-26 Draft to update minor details 1.2 2014-04-16 Sync with updated CP

(5)

1 INTRODUCTION

This document is Eid Passport’s Certification Practice Statement (CPS) for its RAPIDPIV-I Credential Issuance and Management Service Public Key Infrastructure (hereafter ‘RAPIDPIV-I PKI’). As such, the practices found in this CPS is used along with the RAPIDPIV-I Certificate Policy (CP) (hereafter known as the ‘CP’) to govern and run the RAPIDPIV-I PKI. The policies in the CP represent five different assurance levels:

• Medium • Medium-CBP • PIV-I

• Medium-Hardware • Medium-CBP-Hardware

This CPS conforms to the Internet Engineering Task Force’s (IETF) RFC 3647, “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practice Statement Framework” of 2003-11 RFC 3647. The structure of sections 1 to 9 inclusive of this CPS follow the Outline of a Set of Provisions defined in section 6 of RFC 3647 and additional sections are appended thereafter in order to convey additional necessary information.

1.1 Overview

1.1.1 Certificate Policy

The RAPIDPIV-I certificate policy object identifiers (OIDs) correspond to specific assurance levels established by the RAPIDPIV-I CP, and are available to Relying Parties. Certificates issued under the policies in the CP assert the appropriate level of assurance. The RAPIDPIV-I PKI encompasses the entire lifecycle of certificate issuance including Subscriber registration, credential issuance and credential revocation, and this CPS gives the high level practices for managing and operating this PKI.

1.1.2 Relationship between this CPS and the CP

This CPS documents the practices for certificate assurance policies stated in the RAPIDPIV-I CP, thus giving any Relying Party confidence that the certificate they are presented with may be trusted. This RAPIDPIV-I CPS puts in practice the policy requirements stated in the CP.

1.1.3 Scope

The RAPIDPIV-I PKI is a Trust network that its Subscribers and Relying Parties may use to provide interoperability with Federal Government entities. The RAPIDPIV-I CA issues PIV-I certificates only to properly identified and vetted Subscribers. The certificates issued by the RAPIDPIV-I CA meet all requirements of PIV-I laid out in FIPS 201 and the ‘Personal Identity Verification Interoperability For Non-Federal Issuers’ (Issued by the Non-Federal CIO Council in May 2009), as well as the CertiPath X.509 Certificate Policy v3.24 November 19, 2013. This CPS documents the specific practices the RAPIDPIV-I PKI follows when issuing those certificates.

1.2 Document Name and Identification

1.2.1 Certificate Policy Name

This document adopts the ‘Formal name’ given on the cover page. It is also be referred-to by citing any OID from section 1.2.2 in the CP or by being called by the specific policy title in that Section, in which case the applicable policy is only the scope of that one explicitly identified.

1.2.2 Object Identifiers (OIDs)

OIDs defined within the CP are subordinate to Eid Passport’s IANA-registered Private Enterprise Number (IANA-PEN-arc) and are found in section 1.2.2 of the RAPIDPIV-I CP.

(15)

IANA-PEN-arc ::= { iso (1) org (3) dod (6) internet (1) private (4) enterprise (1) } _1.3.6.1.4.1. eidPassport-Inc ::= { IANA-PEN-arc 38948 } 1.3.6.1.4.1.38948

Ref. http://www.iana.org/assignments/enterprise-numbers) eidPMA ::= { EID-Passport-Inc 2 } _{1.3.6.1.4.1.38948.2}

OIDs defined in the RAPIDPIV-I CP follow.

eidRootCA ::= { eidPMA 0 } 1.3.6.1.4.1.38948.2.0 eidPMA-Policies ::= { eidPMA 1 } 1.3.6.1.4.1.38948.2.1 eidRAPIDPIV-I ::= { eidPMA-Policies 1 } 1.3.6.1.4.1.38948.2.1.1 eidMediumSw ::= { eidRAPIDPIV-I 1 } 1.3.6.1.4.1.38948.2.1.1.1 eidMediumHw ::= { eidRAPIPIV-I 2 } 1.3.6.1.4.1. 38948.2.1.1.2 eidMediumCBPSw ::= { eidRAPIDPIV-I 4 } 1.3.6.1.4.1.38948.2.1.1.4 eidMediumCBPHw ::= { eidRAPIDPIV-I 5 } 1.3.6.1.4.1.38948.2.1.1.5 eidPIV-I-hw ::= { eidRAPIDPIV-I 7 } 1.3.6.1.4.1.38948.2.1.1.7 eidPIV-I-cardAuthn ::= { eidRAPIDPIV-I 8 } 1.3.6.1.4.1.38948.2.1.1.8 eidPIV-I-contSign ::= { eidRAPIDPIV-I 9 } 1.3.6.1.4.1.38948.2.1.1.9

(16)

Unless otherwise stated, a requirement stated in the CP applies to all Assurance Levels. The following page shows these OIDs in a hierarchical manner.

(17)

(18)

1.3 PKI Participants

This section documents the requirements for the various roles used in the RAPIDPIV-I PKI. Throughout this CPS when the CPS refers to the term ‘RAPIDPIV-I PKI’ generally the components alluded to in this label include the CA(s) CSA and CMS. Where the term has more limited scope, the specific components will be called out.

1.3.1 PKI Authorities

1.3.1.1 Eid Passport Policy Management Authority

The EPMA has the following general responsibilities, in accordance with the further terms of the EPMA Charter:

• Maintenance and Approval of the RAPIDPIV-I CP, its associated (this) CPS, its Key Recovery Practice Statement (KRPS), its Registration Authority Practice Statement (RPS), various Standard Operating Procedures (SOP), other associated documentation, and any revisions to these documents; and • Maintaining Cross-Certification compliance with the CertiPath Bridge CA (CBCA)

A complete description of EPMA roles and responsibilities is provided in the EPMA Charter. 1.3.1.2 Eid Passport Operational Authority (OA)

The Eid Passport OA is responsible for operating the RAPIDPIV-I CAs in a manner commensurate with the practices in this CPS. This work includes the following:

a. Issuing certificates; b. Revoking certificates;

c. Issuing periodic Certificate Revocation Lists (CRL);

d. Making CRLs available by Lightweight Directory Access Protocol (LDAP) and/or Hypertext Transfer Protocol (HTTP) as directed in later sections of this CPS; and

e. Managing the Key Escrow Database (KED) and requests for escrowed private keys. 1.3.1.2.1 Eid Passport Operational Authority Manager

The Eid Passport PKI Program Manager is also the Operational Authority Manager and is the individual within Eid Passport who has principal responsibility for overseeing the proper operation of the RAPIDPIV-I CAs including the RAPIDPIV-I PKI Repository, as well as the Card Management System (CMS) and who oversees appointment of the Operational Authority Staff.

1.3.1.3 RAPIDPIV-I Root CA

The RAPIDPIV-I eidRootCA is the Root CA that issues a self-signed certificate and exchanges certificates with the CBCA, as well as issues certificates to the RAPIDPIV-I PKI CAs.

1.3.1.4 RAPIDPIV-I Signing CA

The Signing CA associated with the CP is the Eid RAPIDPIV-I CA. It only issues certificates to End-Entities; it does not issue certificates to other CAs.

As operated by the OA, the RAPIDPIV-I CAis responsible for all aspects of the issuance and management of end-entity certificates as required by the CP, including the following:

a. Control over the registration process;

(19)

c. The certificate manufacturing process; d. The publication of certificates;

e. The revocation of certificates; and

f. Ensuring that all aspects of the services, operations, and infrastructure related to certificates issued under the CP are performed in accordance with the requirements, representations, and warranties of the CP.

1.3.1.5 Principal Certification Authority (PCA)

A PCA is a CA within a PKI that has been designated to interoperate directly with an external domain CA (i.e., through the exchange of Cross-Certificates) and perform the role of certifying CA applications for cross-certification as per 4.1, as applicable.

The eidRootCA is the Eid Passport Root CA and the only PCA in the RAPIDPIV-I PKI. Its sole PCA functions is to enable cross-certification with the CertiPath Bridge Certification Authority (CBCA) and sign the RAPIDPIV-I CA certificate.

As operated by the RAPIDPIV-I OA, the eidRootCA (in its PCA capacity) is responsible for all aspects of the issuance and management of Cross-Certificates issued to the CBCA, including the following:

a. Control over the registration process;

b. The identification and authentication process; c. The Cross-Certificate manufacturing process; d. The publication of Cross-Certificates;

e. The revocation of Cross-Certificates; and

f. Ensuring that all aspects of the services, operations, and infrastructure related to Cross-Certificates issued under the CP are performed in accordance with the requirements, representations, and warranties of the CP.

1.3.1.6 Certificate Status Authority (CSA)

A CSA is an authority that provides status of certificates or certification paths. CSAs can be operated in conjunction with the CAs or independent of the CAs. Examples of CSAs include the following:

a. Online Certificate Status Protocol (OCSP) Responders that provide revocation status of certificates; or

b. Simple Certificate Validation Protocol (SCVP) Servers that validate certification paths or provide revocation status checking services.

OCSP Responders that are keyless and simply repeat responses signed by other Responders and SCVP Servers that do not provide certificate validation services adhere to the same security requirements as Repositories. As the RAPIDPIV-I CA issues certificates at the eidPIV-I Assurance Levels, it provides an OCSP Responder. Furthermore, this OCSP Responder is issued a CA-delegated certificate in order to ensure interoperability with Relying Parties.

The eidRootCA does not provide certificate Status information via OCSP, and therefore does not provide an OCSP Responder.

1.3.1.7 Eid Passport Card Management System (CMS)

A CMS is responsible for managing smart card token content. In the context of this CPS, the Eid Passport CMS requirements are mandatory for all Assurance Levels. The RAPIDPIV-I EPMA bears the responsibility for

(20)

ensuring that the RAPIDPIV-I CMS meets the practices described in this CPS, including the practices in section 1.4.1.

1.3.2 Registration Authority (RA)

An RA is the entity that collects and verifies each Subscriber's identity and information that are to be entered into his or her public key certificate. An RA interacts with the CA to enter and approve the Subscriber certificate request information. The RAPIDPIV-I OA acts as the RA for the eidRootCA and RAPIDPIV-I CA. It performs its function in accordance with this CPS approved by the EPMA.

1.3.3 Subscribers

A Subscriber is the entity whose name appears as the subject in an end-entity certificate, agrees to use its key and certificate in accordance with the certificate policy asserted in the certificate, and does not itself issue certificates. CAs are sometimes technically considered “subscribers” in a PKI. However, the term “Subscriber” as used in this document refers only to those entities or persons who request certificates for uses other than signing and issuing certificates or certificate status information. These proper uses include applying a digital signature to a document, encrypting documents, card authentication, and other uses. Other properly designated Subscribers include servers and devices that have a human Sponsor that bears responsibility for the certificate issued to the server or device.

1.3.3.1 Organizational Affiliation

Subscriber certificates may be issued in conjunction with an organization that has a relationship with the Subscriber; this is termed affiliation. The organizational affiliation is indicated in a relative distinguished name in the subject field in the certificate, and the certificate is revoked in accordance with Section 4.9.1 when affiliation is terminated.

1.3.4 Relying Parties

A Relying Party is the entity that relies on the validity of the binding of the Subscriber's name to a public key. The Relying Party is responsible for deciding whether and how to check the validity of the certificate by checking the appropriate certificate status information. The Relying Party can use the certificate to verify the integrity of a digitally signed message, to identify the creator of a message, or to establish confidential communications with the holder of the certificate. A Relying Party may use information in the certificate (such as certificate Policy identifiers) to determine the suitability of the certificate for a particular use. 1.3.5 Other Participants

1.3.5.1 Related Authorities

The RAPIDPIV-I CA operating under this CPS require the services of other security, community, and application authorities, such as compliance auditors and attribute authorities. This CPS identifies the parties responsible for providing such services, and the mechanisms used to support these services.

1.3.5.2 Trusted Agent (TA)

A TA is a person who verifies Subscriber identity and information on behalf of an RA. A TA does not have privileges on the CA to issue and revoke certificates.

1.3.6 Applicability

The sensitivity of the information processed or protected using certificates issued by the RAPIDPIV-I CA varies. Entities must evaluate the environment and the associated threats and vulnerabilities and determine the level of risk they are willing to accept based on the sensitivity or significance of the information. This evaluation is done by each Entity for each application and is not controlled by this CPS.

The certificate levels of assurance contained in this CPS as in section 1.2 are set forth below, as well as a brief and non-binding description of the applicability for applications suited to each level.

(21)

eidPIV-I-cardAuth This level is relevant to environments where risks and consequences of data compromise are moderate. This includes contactless smart card readers where use of an activation PIN is not practical.

hardware or

medium-hardware CBP This level is relevant to environments where risks and consequences of data compromise are moderate. These certificates are issued to devices and servers. Private Keys are stored in hardware at this Assurance Level.

eidPIV-I-hardware or eidPIV-I-contentSigning

This level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial.

eidPIV-I-contentSigning is only issued to the CMS. eidPIV-I-hardware Subscriber

Private Keys are stored in hardware at this Assurance Level.

software or

medium-software CBP This level is relevant to environments where risks and consequences of data compromise are moderate. These certificates are issued to devices and servers. Private Keys are stored in software at this Assurance Level.

1.3.6.1 Factors in Determining Usage

The Relying Party must first determine the level of assurance required for an application, and then select the certificate appropriate for meeting the needs of that application.

This is determined by evaluating the various risk factors including the value of the information, the threat environment, and the existing protection of the information environment. These determinations are made by the Relying Party and are not controlled by the EPMA or OA. Nonetheless, this CPS contains some helpful guidance, set forth herein, which Relying Parties may consider in making their decisions.

1.3.6.2 Obtaining Certificates

There are two groups of persons or entities who need access to certificates issued by the Eid Passport RAPIDPIV-I PKI. Subscribers follow the requirements in section 3 below. Relying Parties follow the requirements in section 2.

1.4 Certificate Usage

1.4.1 Appropriate Certificate Uses No Stipulation

1.4.2 Prohibited Certificate Uses No stipulation.

1.5 Policy Administration

1.5.1 Organization Administering this Document The EPMA is responsible for all aspects of this CPS. 1.5.2 Contact Person

Questions regarding this CPS are to be directed to the Point of Contact defined on the cover page of this CPS. 1.5.3 Person Determining CPS Suitability for the Policy

The EPMA approves the Eid RAPIDPIV-I CPS and commission an analysis to determine whether this CPS conforms to the Eid RAPIDPIV-I CP. Information regarding this compliance analysis is found in section 8.

(22)

1.5.4 Eid Passport RAPIDPIV-I PKI CPS Approval Procedures

By its very name, a CPS details “how” to implement the policies in the CP. Just as the EPMA is responsible for approving the CP, the EPMA is also responsible for this RAPIDPIV-I CPS.

1.5.5 Waivers

There are no waivers to this CPS.

1.6 Definitions and Acronyms

(23)

2 PUBLICATION AND PKI REPOSITORY RESPONSIBILITIES

2.1 PKI Repositories

The Eid Passport RAPIDPIV-I PKI makes its PKI Repositories available to Relying Parties over the Internet. These Repositories provide the appropriate information, including but not limited to, CA certificates, CRLs, and Authority Revocation Lists (ARLs).

2.1.1 Repository Obligations

The RAPIDPIV-I OA use a variety of mechanisms for posting information into the repositories as required by this CPS. These mechanisms, at a minimum include the following:

a. Unrestricted read-only access to the certificates and certificate status information in the RAPIDPIV-I repositories is given to Relying Parties; and

b. Access control mechanisms when needed to protect repository information as described in later sections.

2.2 Publication of Certificate Information

2.2.1 Publication of CA Information

The Operational Authority publishes information concerning the Eid Passport RAPIDPIV-I CAs necessary to support their use and operation.

All CAs post CA certificates and CRLs to the Eid Passport PKI Repositories.

The PKI Repositories containing certificates and certificate status information is deployed so as to provide 24 hour per day/365 day per year availability. Eid Passport has implemented features to provide high levels of PKI Repository reliability (99% availability).

2.2.2 Interoperability See section 2.1

2.3 Time or Frequency of Publication

Certificates and certificate status information are published according to the stipulations of section 4 of this CPS.

2.4 Access Controls on PKI Repositories

Any PKI Repository information not intended for public dissemination or modification is protected against unauthorized access. Public keys and certificate status information in the RAPIDPIV-I PKI Repository is publicly available as per section 2.1.

Any certificates that contain a UUID (i.e., Subscriber Identity and Card Authentication certificates), are not be distributed by the RAPIDPIV-I PKI Repositories.

(24)

3 IDENTIFICATION AND AUTHENTICATION

3.1 Naming

3.1.1 Types of Names

The RAPIDPIV-I CAs generate and issue certificates with a unique and non-null X.500 Distinguished Name (DN) in the Issuer and Subject fields, and the certificates may include additional names via the subjectAltName extension, provided it is marked noncritical, and is in accordance with the profiles in section 10.

The base DN are in this format:

c=US, o=[organization], ou=[department], ou=[agency], ou=[optional]For certificates issued to human Subscribers, the subject DN contains the value ‘Unaffiliated’ in the last organizational unit (ou) attribute or contains the affiliated organization name in an appropriate relative distinguished name attribute (i.e., organization (o), organizational unit (ou), or domain component (dc) attribute).

For certificates issued to humans under eidPIV-I-hardware the certificate includes:

{BaseDN}, ou=[affiliated organization name], cn=Subscriber’s full nameeidPIV-I-contentSigning certificates clearly indicates Eid Passport as the organization administering the CMS in the following form:

{BaseDN}, ou=[CMS organization name], cn=CMS name

eidPIV-I-cardAuth certificate’s subject DN does not contain the common name (cn). Instead, the DN populates the serialNumber attribute with the Universally Unique Identifier (UUID) associated with the card. {BaseDN}, ou=[affiliated organization name], serialNumber=UUID

For eidPIV-I-cardAuth certificates, the subject DN either contains the value ‘Unaffiliated’ in the last organizational unit (ou) attribute or contains the affiliated organization name in an appropriate relative distinguished name attribute (i.e., organization (o), organizational unit (ou), or domain component (dc) attribute).

When issuing any eidPIV-I certificate to unaffiliated individuals, the DN shall include ‘ou=unaffiliated, o=Eid Passport’ along with any other required DN attributes for the DN written for the specific individual. An example DN for unaffiliated would look like this:

cn=John Doe, ou=unaffiliated, o=Eid Passport, c=US 3.1.2 Need for Names to be Meaningful

The certificates issued pursuant to this CPS are meaningful only if the names that appear in the certificates can be understood and used by Relying Parties. Names used in the certificates must identify the person or object to which they are assigned in a meaningful way. Additionally, all DNs must be unique to prevent accidental or deliberate reuse of DNs. See section 3.1.5 for more details on name uniqueness.

Appropriate DNs with a Common Name (CN) that is understandable for humans areused in Identity, Signature, Encryption, and Device certificates. Legal names are appropriate for humans, while IP address, Fully Qualified Doman Name (FQDN), or model name and serial number may be used for devices and other equipment. Here are some examples:

For human subscribers follow the convention cn=firstname initial. lastname

For a subscriber that is an entity, such as a cross-certified CA, follow this convention: cn=CA name

All DNs accurately reflect the organization with whom the Subject is affiliated. When User Principal Name (UPN) is used it accurately reflects an organizational structure.

(25)

3.1.3 Anonymity or Pseudonymity of Subscribers

CA certificates does not contain anonymous or pseudonymous identities.

DNs in certificates issued to Subscribers and devices may contain a pseudonym to meet local privacy regulations as long as name space uniqueness requirements are met and as long as such name is unique and traceable to the actual entity.

3.1.4 Rules for Interpreting Various Name Forms

Rules for interpreting name forms are contained in the applicable certificate profile. Rules for interpreting UUIDs are specified in RFC 4122.

3.1.5 Uniqueness of Names

Name uniqueness are enforced in certificates issued by the RAPIDPIV-I CA. The CMS enforces name uniqueness within the X.500 name space, in which they have been authorized.

The OA is responsible for ensuring name uniqueness in certificates issued by the RAPIDPIV-I PKI. This CPS defines the following:

• The name forms used in the architecture

• How the RAPIDPIV-I CA allocates names within the Subscriber community to guarantee name uniqueness among current and past Subscribers or between the subscribers of two different organizations, (e.g., if “Jane Doe” leaves a CA’s community of Subscribers, and a new, different “Jane Doe” enters the community of Subscribers) a unique name shall be provided in the Subject DN belonging to the second person.

• The name space used for all Subject DNs is indicated in section 7.1.4.

Additionally, the Eid Passport CMS checks for name uniqueness and notifies the RA when there is a name collision, offering suggested name alternatives.

3.1.6 Recognition, Authentication, and Role of Trademarks No stipulation

3.1.7 Name Claim Dispute Resolution Procedure

When a possible name collision occurs the EPMA will work with the entity to develop an acceptable alternative, but the EPMA will contact the CertiPath PMA for instructions if the EPMA cannot resolve the disputed name.

3.2 Initial Identity Validation

3.2.1 Method to Prove Possession of Private Key

In all cases where the party named in a certificate generates their own keys they are required to prove possession of the private key corresponding to the public key in the certificate Request. For signature keys, this is done by the entity using its private key to sign a value and providing that value to the RAPIDPIV-I CA. The CA then validates the signature using the party‘s public key.

When the RAPIDPIV-I PKI is issuing smart cards, the CMS initiates a certificate request over SSL, and uses the CMS’s authentication keys to authenticate to the RAPIDPIV-I Signing CA.

3.2.2 Authentication of Organization Identity

The existence of an affiliated organization is verified prior to issuing any end user certificates on its behalf. Once an organization signs a contract with Eid Passport, the organization name and other pertinent information is entered into the CMS system by a CMS Systems Administrator. Requests for subscriber certificates in the name of an Affiliated Organization includes the organization name, address, and

(26)

documentation of the existence of the organization. The RA verifies the information, in addition to the authenticity of the requesting representative and the representative’s authorization to act in the name of the organization.

3.2.3 Authentication of Individual Identity

eidPIV-I certificates are issued only to human subscribers. Identity is established by in-person proofing before the RA, a Trusted Agent, or, for Assurance Levels other than eidPIV-I Assurance Levels, an entity certified by a State or Federal Entity as being authorized to confirm identities; information provided is verified to ensure legitimacy. For Assurance Levels other than eidPIV-I the applicant presents one valid National Government-issued photo ID, or two valid non-National Government IDs, one of which is a recent photo ID (i.e., driver's license)

Authentication of individual identity using antecedent in-person identity-proofing data is not supported by this CPS.

The RA ensures that the applicant’s identity information is verified. For certificates issued under id-eidPIV-I-medium, and id-eidPIV-I-mediumHardware, identity is established no more than 30 days before initial certificate issuance. RAs may use remote authentication of an applicant’s identity using an Eid Passport TA to support identity proofing of applicants, assuming RAPIDPIV-I identity badging requirements are otherwise satisfied. Minimal procedures for authentication of human subscribers are detailed below.

• Verify that a request for certificate issuance to the applicant was submitted by an authorized sponsoring/Affiliated organization employee. This validation includes the authentication of

organization identity as specified in section 3.2.2 and inclusion of the organization name within the subscriber DN

• Applicant’s employment is verified through use of official organization records

• Applicant’s identity is established by in-person proofing before the Registration Authority or Trusted Agent, based on the following processes:

o Identity source documents are presented as follows:

The applicant presents two identity source documents in original form. The identity source documents must come from the list of acceptable documents included in Form I-9, OMB No. 1115-0136, Employment Eligibility Verification. At least one document must be a valid State or Federal Government-issued picture identification (ID). For PIV-I credentials, an in-person antecedent is not permitted.

o The RA examines the presented credential for biometric data that can be linked to the applicant (e.g. a photograph on the credential itself or a securely linked photograph of applicant)

o The credential presented above is verified by the RA for currency and legitimacy (e.g., the organization ID is verified as valid)

• Biometric data is captured for PIV-I credentials and formatted in accordance with NIST SP800-76 as follows:

o An electronic facial image used for printing facial image on the card, as well as for

performing visual authentication during card usage (a new facial image is collected each time a card is issued)

o Two electronic fingerprints to be stored on the card for automated authentication during card usage

(27)

Where it is not possible for applicants to appear in person before the RA, a Trusted Agent may serve as proxy for the RA. The Trusted Agent forwards the information collected from the applicant directly to the RA in a secure manner.

Authentication by a Trusted Agent does not relieve the RA of its responsibility to perform the appropriate steps above. In addition, the RA records the process that was followed for issuance of each certificate, and the process documentation includes the following on the last page of the Subscriber Agreement:

a. The identity of the person (TA or RA) performing the identity verification;

b. A signed declaration by that person that he or she verified the identity of the applicant as required by the RAPIDPIV-I CP using the format set forth at 28 U.S.C. 1746 (declaration under penalty of perjury);

c. Name of identifying document type (e.g., Passport);

d. Ensure the identifying document is still valid and not expired;

e. Unique identifying numbers from the ID of the verifier and from an ID of the applicant; and The date and time of the verification.

3.2.3.1 Authentication of Component Identities

Some computing and communications components (routers, firewalls, servers, etc.) may be named as certificate subjects. In such cases, the component (usually referred to as a ‘device’) has a human sponsor (the ‘PKI Sponsor’).

The PKI Sponsor is responsible for providing the following registration information:

a. Equipment identification (i.e., serial number) or service name (i.e., DNS name) sufficient to uniquely identify the Subject;

b. Equipment public keys;

c. Equipment authorizations and attributes (if any are to be included in the certificate); and d. Contact information to enable the CA or RA to communicate with the sponsor when required. The RAPIDPIV-I PKI requires in person registration of the PKI Sponsor, with the identity of the PKI Sponsor confirmed in in the same manner as required in Section 3.2.3. If the PKI Sponsor has a valid certificate issued by the RAPIDPIV-I PKI, verification of the signature on a digitally signed message from the PKI Sponsor is acceptable for identity authentication. When a PKI Sponsor is changed, the new PKI Sponsor must review the status of each device under his/her sponsorship to ensure it is still authorized to receive certificates, and any found to no longer need a certificate from the RAPIDPIV-I PKI will request it to be revoked.

3.2.4 Non-verified Subscriber Information

Information that is not verified is not included in certificates. 3.2.5 Validation of Authority

Certificates that contain explicit or implicit organizational affiliation are issued after ascertaining the applicant has the authorization to act on behalf of the organization in the asserted capacity.

(28)

3.2.6 Criteria for Interoperation

Although the Eid Passport PKI Cross-Certified with CertiPath is not intended to serve as its own Bridge, in any cases where an external PKI-domain CA wishing to interoperate with the RAPIDPIV-I PKI must adhere to the following requirements:

a. Have a contractual relationship with Eid Passport;

b. Have a CP mapped to and determined by the EPMA to be in conformance with the RAPIDPIV-I CP; c. Operate a PKI that has undergone a successful compliance audit pursuant to section 8 of this CPS

and as set forth in the Subject CA CPS’s corresponding section;

d. Issue certificates compliant with the profiles described in this CPS, and make certificate status information available in compliance with this CPS; and

e. Provide CA certificate and certificate status information to the Relying Parties in compliance with this CPS.

3.3 Identification and Authentication for Re-Key Requests

3.3.1 Identification and Authentication for Routine Re-Key

Subscribers are authenticated through use of their current Signing Key or by using the initial identity-proofing process as described in section 3.2.

Subscribers with medium-software, medium-hardware, software, and/or medium-CBP-hardware certificates must re-establish identity through the initial identity-proofing process at least once every nine years.

When a current public key certificate is used for identification and authentication purposes, the expiration date of the new certificate does not extend beyond the initial identity-proofing times specified in the paragraphs above, and the Assurance Level of the new certificate does not exceed the Assurance Level of the certificate being used for identification and authentication purposes.

3.3.2 Identification and Authentication for Re-Key After Revocation

Once a certificate has been revoked, the certificate subject (i.e., Subscriber or device) is authenticated by using the initial identity-proofing process as described in section 3.2 or through use of another current, valid public key certificate in accordance with section 3.3.1.

3.4 Identification and Authentication for Revocation Request

{Redacted}

As in section 3.2.3, a Company PKI Sponsor or Trusted Agent may request revocation of an affiliated Subscriber’s certificate by sending a digitally signed e-mail message to the RA. The RA must ensure the TA is requesting a revocation for a Subscriber that is affiliated with the TA’s organization.

(29)

4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate Application

4.1.1 Submission of Certificate Application

Only an RA acting on behalf of the Subscriber submits a certificate application to the CA.

In some cases devices are issued a trusted certificate. For these situations, a PKI Sponsor submits identity information to an RA who submits the request. This PKI Sponsor already had gone through the process of identity vetting and have in their possession a valid and current PIV-I credential.

4.1.2 Enrolment Process and Responsibilities

Applicants for public key certificates are responsible for providing accurate information in their applications for certification, and the RAPIDPIV-I PKI ensures the following actions take place:

a. Check and record identity of Subscriber (per section 3.2);

b. Verify the applicant’s authority to request the certificate by using a point of contact or other verfiable means of determining authorization; and

c. Generate and confirm the functionality of a Public/Private Key pair for each certificate required.

4.2 Certificate Application Processing

It is the responsibility of the RA, or, in the case of a CA certificate, the EPMA, to verify that the information in a certificate application is accurate. Section 4.2.1 gives details on how the CMS verifies that the certificate application is processed accurately and with authorization.

4.2.1 Performing Identification and Authentication Functions {Redacted}

Prior to certificate issuance, a Subscriber is required to sign a Subscriber Agreement containing the requirements that the Subscriber protects the private key and use the certificate and private key for authorized purposes only.

4.2.2 Approval or Rejection of Certificate Applications

The EPMA or any of its RAs may approve or reject a certificate application.

Some examples of reason to reject an application include, but are not limited to the following: • Information on the certificate application is contradictory or does not match the applicant • Vital information on the certificate application cannot be authenticated

• Payment is not received in time

4.2.3 Time to Process Certificate Applications

Certificate application processing from the time the request/application is posted on the CA or RA system to certificate issuance does not exceed thirty (30) days.

Identity is checked at time of issuance and is verified by a 2:2 biometric match with data gathered at Subscriber enrollment (e.g. finger print and facial image).

(30)

4.3 Certificate Issuance

While the Subscriber may do most of the data entry, it is still the responsibility of the CA and the RA to verify that the information in a certificate request is correct and accurate.

4.3.1 CA Actions During Certificate Issuance The CA:

• Verifies the source of a certificate request before issuance;

• Checks certificates to ensure that all fields and extensions are properly populated; and • Posts the certificate after generation, verification, and acceptance.

In addition, the CA requires PIV-I certificate authentication before processing certificate requests in order to verify the source of the request. The Eid Passport CMS holds a PIV-I Auth certificate to use for establising certificate authentication. This PIV-I Auth certificate was issued by the RAPIDPIV-I CA, thus ensuring authorization. Every Eid Passport RA uses the CMS to communicate with the RAPIDPIV-I CA.

4.3.2 Notification to Subscriber of Certificate Issuance

Subscribers are notified of certificate issuance by means of handing the card to the Subscriber.

4.4 Certificate Acceptance

4.4.1 Conduct Constituting Certificate Acceptance

Failure to object to the certificate indicates acceptance of it.

The Subscriber must sign a Subscriber Agreement, acknowledging their understanding and acceptance of their responsibilities as defined in Section 9.6.2 of this CPS. Once the RA downloads the Subscriber’s certificates to the smart card, the RA releases the PIV-I Card to the subscriber only after a successful 1:1 biometric match of the applicant against the biometrics collected in Section 3.2.3.1.

In the case of devices or services (web servers, routers, firewalls, etc.), the PKI Sponsor (as defined in Section 5.2.1.6) performs the same function as described above for the acceptance of the device certificate. There is no escrow of private keys associated with certificates for devices or services.

4.4.2 Publication of the Certificate by the CA

All CA certificates are published in a dedicated PKI repository site accessible to the Internet. 4.4.3 Notification of Certificate Issuance by the CA to other Entities

No stipulation beyond an agreement in any MOU.

4.5 Key Pair and Certificate Usage

4.5.1 Subscriber Private Key and Certificate Usage

Subscribers and CAs protect their private keys from access by any other party. The Subscriber must agree to the Subscriber Agreement and accept the certificate before the private key corresponding to the public key in the certificate may be used.

Subscribers and CAs use their private keys for the purposes as constrained by the extensions (such as key usage, extended key usage, certificate policies, etc.) in the certificates issued to them, and they do not continue to use the certificates after they have expired or been revoked.

(31)

4.5.2 Relying Party Public Key and Certificate Usage

Relying Parties accept and use public key certificates and their associated public keys for the purposes intended as constrained by the extensions (such as key usage, extended key usage, certificate policies, etc.) in the certificates.

4.6 Certificate Renewal

Renewing a certificate means creating a new certificate with the same name, key, and other information as the old one, but with a new, extended validity period and a new serial number.1_{However, certificate renewal} does not apply to eidPIV-I Subscriber certificates. There is no certificate renewal or modification allowed for these Subscriber certificates. The old certificate(s) may or may not be revoked, but must not be further re-keyed, renewed or updated.

4.6.1 Circumstance for Certificate Renewal

For certificates other than eidPIV-I Assurance Level certificates a certificate may be renewed if the public key has not reached the end of its validity period, the associated private key has not been revoked or compromised, and the device or CA name and attributes are unchanged. In addition, the validity period of the certificate does not exceed the remaining lifetime of the private key, as specified in section 5.6. The identity proofing requirement listed in section 3.3.1 must also be met.

4.6.2 Who May Request Renewal

A Subject may request the renewal of its certificate.

A PKI Sponsor may request renewal of its Device certificate.

A CA may request renewal of its Subscriber certificates, i.e., when the CA re-keys. 4.6.3 Processing Certificate Renewal Requests

A certificate renewal is achieved using one of the following processes: a. Initial registration process as described in section 3.2; or

b. Identification & Authentication for Re-key as described in section 3.3, except the old key can also be used as the new key.

For Cross-Certificates issued by an Eid RAPIDPIV-I CA, certificate renewal also requires that a valid MOU exists between the EPMA and the Subject CA, and the term of the MOU is beyond the expiry period for the new certificate.

4.6.4 Notification of New Certificate Issuance to Subscriber See section 4.3.2.

4.6.5 Conduct Constituting Acceptance of a Renewal Certificate See section 4.4.1.

4.6.6 Publication of the Renewal Certificate by the CA See section 4.4.2.

1_{Renewal is supported by this CPS primarily for OCSP Responder certificates (renewed monthly) and external PKI-domain}

Cross-certificates (renewed according to an MoU, for example annually).

(32)

4.6.7 Notification of Certificate Issuance by the CA to other Entities See section 4.4.3.

4.7 Certificate Re-Key

The longer and more often a key is used, the more susceptible it is to loss or discovery. Therefore, it is important that a Subscriber periodically obtains new keys and re-establishes its identity. Re-keying a Certificate means that a new certificate is created that has the same characteristics and Assurance Level as the old one, except that the new certificate has a new, different public key (corresponding to a new, different private key) and a different serial number, and it may be assigned a different validity period.

Credentials that are to be re-keyed have its current certificates revoked. 4.7.1 Circumstance for Certificate Re-Key

A CA issues a new certificate to the Subject when the Subject has generated a new key pair and is entitled to a certificate.

4.7.2 Who may Request Certification of a New Public Key A Subject may request re-key of its certificate.

A PKI Sponsor may request re-key of a Device certificate. 4.7.3 Processing Certificate Re-Keying Requests

A certificate re-key is be achieved using one of the following processes: a. Initial registration process as described in section 3.2; or

b. Identification and Authentication for Re-Key as described in section 3.3.

To re-key a cross-certificate between the RAPIDPIV-I PKI and an external PKI domains' CAs, (such as with the CBCA) certificate re-key also requires that a valid MOU exists between Eid Passport and the PMA of the other CA, and the term of the MOU is beyond the expiry period for the new certificate.

4.7.4 Notification of new Certificate Issuance to Subscriber See section 4.3.2.

4.7.5 Conduct Constituting Acceptance of a Re-Keyed Certificate See section 4.4.1

4.7.6 Publication of the Re-Keyed Certificate by the CA See section 4.4.2.

4.7.7 Notification of Certificate Issuance by the CA to Other Entities See section 4.4.3.

4.8 Certificate Modification

Updating a certificate means creating a new certificate for the Subscriber. Existing certificates are not changed. Certificates are modified by having the Subscriber provide identity documentation and going through the registration and issuance process for a new set of certificates. New certificates may be put on the Subscriber’s existing card, but in this case, the old certificates will first be revoked. Consideration must be taken based on whether the Subscriber has encrypted anything that needs the old encryption keys, before revoking them.

Further, if an individual's name changes (e.g., due to marriage), then proof of the name change is provided to the RA or the Trusted Agent in order for an updated certificate having the new name to be issued.

(33)

4.8.1 Circumstance for Certificate Modification

A CA issues a new certificate to the Subject when some of the Subject information has changed, e.g., name change due to change in marital status, change in subject attributes, etc., and the Subject continues to be entitled to a certificate.

4.8.2 Who may Request Certificate Modification A Subject may request modification of its certificate.

A PKI Sponsor may request modification of Device certificate. 4.8.3 Processing Certificate Modification Requests

A certificate modification is achieved using one of the following processes: a. Initial registration process as described in section 3.2; or

b. Identification & Authentication for Re-key as described in section 3.3. In addition, the validation of the changed subject information is in accordance with the initial identity-proofing process as described in section 3.2.

For Cross-Certificates issued by an Eid RAPIDPIV-I CA, certificate modification also requires that a valid MOU exists between the EPMA and the Subject CA, and the term of the MOU is beyond the expiry period for the new certificate.

4.8.4 Notification of New Certificate Issuance to Subscriber See section 4.3.2.

4.8.5 Conduct Constituting Acceptance of Modified Certificate See section 4.4.1.

4.8.6 Publication of the Modified Certificate by the CA See section 4.4.2.

4.8.7 Notification of Certificate Issuance by the CA to Other Entities See section 4.4.3.

4.9 Certificate Revocation and Suspension

All revocation requests are authenticated. Here are some acceptable methods for authenticating a certificate revocation request, with the caveat however, that the compromised private key is not used to authenticate a revocation.

{Redacted}

4.9.1 Circumstances for Revocation

A certificate is revoked when the binding between the Subject and the Subject's public key defined within a certificate is no longer considered valid. Examples of circumstances that invalidate the binding include the following2_:

a. Identifying information or affiliation components of any names in the certificate become invalid;

2_{No privilege attributes are asserted in any current certificate Profile. In the event that any future profile allows for privilege}

attributes, reduction of privileges must be added to the list of reasons for revocation.

(34)

b. An Organization terminates its relationship with the CA such that it no longer provides affiliation information;

c. Privilege attributes asserted in the Subject’s certificate are reduced;

d. The Subject can be shown to have violated the stipulations of its agreement;

e. The private key, or the media holding the private key, is suspected of compromise; or

f. The Subject or other authorized party (as defined in this CPS) asks for his/her certificate to be revoked;

Whenever any of the above circumstances occurs, the associated certificate is revoked and placed on the CRL. Revoked certificates are included on all new publications of the certificate status information until the certificates expire.

If it is ever determined subsequent to issuance of new certificates that a private key used to sign requests for one or more additional certificates may have been compromised at the time the requests for additional certificates were made, all certificates authorized by directly or indirectly chaining back to that compromised key are to be revoked.

4.9.2 Who can Request Revocation

The following parties are allowed to request a revocation on behalf of the Subscriber for either affiliated or unaffiliated Subscribers:

• An RA

• The Eid Passport Operational Authority (OA)

• A PKI Sponsor or other official in the Subscriber’s authorizing organization • Other authorized party including a Trusted Agent

All of these can request the revocation of a Subscriber’s certificate on the Subscriber’s behalf. For certificates issued in association with an Affiliated Organization, the revocation request is only accepted from the Affiliated Organization named in the certificate. A Trusted Agent or official in the Subscriber’s authorizing organization only requests revocation of a certificate for a Subscriber that is affiliated with the Trusted Agent’s or official’s organization. Further explanation of Revocation requirements procedures are found in section 4.9.

In the case of CA certificates issued to another PKI-domain (such as the CBCA) by the Eid RAPIDPIV-I CA, the CBCA PMA or the EPMA may request revocation of a certificate.

For CA certificates, authorized individuals representing the CA Operational Authority may request revocation of certificates.

4.9.3 Procedure for Revocation Request

All revocation requests identify the certificate to be revoked and include the reason for revocation. The certificate to be revoked is uniquely identified with information including: the organization name, the subject name and the email address on the certificate or optionally the certificate serial number. This information alone or combined is used to uniquely identify the correct Subject DN of the certificate to be revoked. Optionally, the certificate serial number may be used to correctly discriminate one certificate among a history of certificates issued to the Subject. Only a certificate explicitly identified in the request is revoked.

RAPIDPIV-I Credential Service Certification Practice Statement Redacted