Operational Research Consultants, Inc. (ORC)
Access Certificates For Electronic Services
(ACES)
Certificate Practice Statement
DRAFT Version 3.1.5
October 1, 2004
DRAFT
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
THIS PAGE INTENTIONALLY LEFT BLANK.
DRAFT
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
Table of Contents
1
Introduction............................................................................................................... 1
1.1
Overview .......................................................................................................... 1
1.2
Policy Identification ............................................................................................ 2
1.3
Community and Applicability ............................................................................... 4
1.4
2
1.3.1
Certificate Service Providers .................................................................... 4
1.3.2
End Entities (EE) .................................................................................... 6
1.3.3
Policy Authority ...................................................................................... 8
1.3.4
Applicability ........................................................................................... 8
1.3.5
Related Authorities ............................................................................... 12
Contact Details ................................................................................................ 13
1.4.1
Policy Administration Organization .......................................................... 13
1.4.2
Policy Contact Personnel ........................................................................ 13
1.4.3
Person Determining CPS Suitability for the Policy ...................................... 13
1.4.4
CPS Administration Organization ............................................................ 13
General Provisions ................................................................................................... 14
2.1
Obligations ..................................................................................................... 14
2.1.1
Authorized CA Obligations...................................................................... 14
2.1.2
RA, LRA and IA Obligations .................................................................... 15
2.1.3
Certificate Manufacturing Authority Obligations ........................................ 17
2.1.4
Repository Obligations .......................................................................... 17
2.1.5
Subscriber Obligations........................................................................... 18
2.1.6
Server/Component Certificate Subscriber Obligations ................................ 19
2.1.7
Code Signer Certificate Subscriber Obligations ......................................... 19
2.1.8
Relying Party Obligations ....................................................................... 20
2.1.9
Policy Authority Obligations ................................................................... 22
2.1.10 ORC Certificate Status Authority (CSA) Obligations ................................... 22
2.2
2.3
2.4
Liability .......................................................................................................... 22
2.2.1
Authorized CA Liability .......................................................................... 22
2.2.2
RA, IA, CMA, and Repository Liability ...................................................... 22
2.2.3
Warranties and Limitations On Warranties ............................................... 22
2.2.4
Damages Covered and Disclaimers ......................................................... 23
2.2.5
Loss Limitations ................................................................................... 23
2.2.6
Other Exclusions ................................................................................... 23
Financial Responsibility ..................................................................................... 24
2.3.1
Indemnification By Relying Parties and Subscribers ................................... 24
2.3.2
Fiduciary Relationships .......................................................................... 24
2.3.3
Administrative Processes ....................................................................... 24
Interpretation and Enforcement ......................................................................... 24
2.4.1
106764133
Governing Law ..................................................................................... 24
i
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
2.5
2.6
2.7
2.8
2.9
2.10
3
2.4.2
Severability of Provisions, Survival, Merger, and Notice ............................. 25
2.4.3
Dispute Resolution Procedures ............................................................... 25
Fees ............................................................................................................... 25
2.5.1
Certificate Issuance, Renewal, Suspension, and Revocation Fees ................ 25
2.5.2
Certificate Access Fees .......................................................................... 26
2.5.3
Revocation or Status Information Access Fees .......................................... 26
2.5.4
Fees for Other Services Such as Policy Information ................................... 26
2.5.5
Refund Policy ....................................................................................... 26
Publication and Repository ................................................................................ 26
2.6.1
Publication of ORC ACES Information ...................................................... 26
2.6.2
Frequency of Publication ........................................................................ 27
2.6.3
Access Controls .................................................................................... 27
2.6.4
Repositories ......................................................................................... 27
Inspections And Reviews .................................................................................. 28
2.7.1
Certification and Accreditation ................................................................ 28
2.7.2
Quality Assurance Inspection and Review ................................................ 30
Confidentiality ................................................................................................. 31
2.8.1
Types of Information to Be Kept Confidential ........................................... 31
2.8.2
Types of Information Not Considered Confidential ..................................... 32
2.8.3
Disclosure of Certificate Revocation/Suspension Information ...................... 32
2.8.4
Release to Law Enforcement Officials ...................................................... 32
2.8.5
Release as Part of Civil Discover ............................................................. 32
2.8.6
Disclosure upon Owner's Request ........................................................... 33
Security Requirements ..................................................................................... 33
2.9.1
System Security Plan (SSP) ................................................................... 33
2.9.2
Risk Management ................................................................................. 33
2.9.3
Certification and Accreditation ................................................................ 33
2.9.4
Rules and Behavior ............................................................................... 34
2.9.5
Contingency Plan .................................................................................. 34
2.9.6
Incident Response Capability.................................................................. 34
Intellectual Property Rights ............................................................................... 34
Identification And Authentication ............................................................................ 36
3.1
106764133
Initial Registration ........................................................................................... 36
3.1.1
Types of Names .................................................................................... 36
3.1.2
Need for Names to be Meaningful ........................................................... 39
3.1.3
Rules for Interpreting Various Name Forms .............................................. 40
3.1.4
Uniqueness of Names ............................................................................ 40
3.1.5
Name Claim Dispute Procedure .............................................................. 41
3.1.6
Recognition, Authentication and Role of Trademarks ................................. 41
3.1.7
Verification of Possession of Private Key .................................................. 41
3.1.8
Authentication of Sponsoring Organizational Identity ................................ 42
3.1.9
Authentication of Individual Identity........................................................ 43
ii
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
3.1.10 Code Signer Authentication .................................................................... 47
3.1.11 Authentication of Component Identities ................................................... 48
3.2
4
Routine Re-Key (Certificate Renewal) ................................................................. 49
3.2.1
CA Certificate Routine Re-Key ................................................................ 49
3.2.2
Certificate Re-Key ................................................................................. 49
3.2.3
Certificate Renewal ............................................................................... 49
3.3
Obtaining a New Certificate After Revocation ....................................................... 50
3.4
Revocation Request ......................................................................................... 51
Operational Requirements ....................................................................................... 52
4.1
4.2
Certificate Application ...................................................................................... 52
4.1.1
Application Initiation ............................................................................. 52
4.1.2
Application Rejection ............................................................................. 54
Certificate Issuance.......................................................................................... 54
4.2.1
Certificate Delivery ............................................................................... 55
4.2.2
Certificate Replacement ......................................................................... 56
4.3
Certificate Acceptance ...................................................................................... 56
4.4
Certificate Suspension and Revocation ............................................................... 57
4.4.1
Who Can Request a Revocation .............................................................. 57
4.4.2
Circumstances for Revocation................................................................. 58
4.4.3
Revocation Request Procedure ............................................................... 59
4.4.4
Revocation Grace Period ........................................................................ 60
4.4.5
Certificate Authority Revocation Lists (CARLs)/Certificate Revocation Lists
(CRLs)................................................................................................. 61
4.4.6
Online Revocation/Status Checking Availability ......................................... 61
4.4.7
Online Revocation Checking Requirements ............................................... 62
4.4.8
Other Forms of Revocation Advertisements Available ................................ 62
4.4.9
Checking Requirements for Other Forms of Revocation Advertisements
Available ............................................................................................. 62
4.4.10 Special Requirements With Respect to Key Compromise ............................ 62
4.5
4.6
4.7
106764133
Certificate Suspension ...................................................................................... 63
4.5.1
Circumstances for Suspension ................................................................ 63
4.5.2
Who Can Request Suspension ................................................................ 63
4.5.3
Procedure for Suspension Request .......................................................... 63
Computer Security and Audit Procedures ............................................................ 63
4.6.1
Types of Event Recorded ....................................................................... 64
4.6.2
Frequency of Processing Data ................................................................. 67
4.6.3
Retention Period for Security Audit Data .................................................. 67
4.6.4
Protection of Security Audit Data ............................................................ 67
4.6.5
Security Audit Data Backup Procedures ................................................... 68
4.6.6
Security Audit Collection System (Internal vs. External) ............................ 68
4.6.7
Notification to Event-Causing Subject ...................................................... 68
4.6.8
Vulnerability Assessments...................................................................... 68
Records Archival .............................................................................................. 68
iii
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
5
4.7.1
Types of Data Archived.......................................................................... 68
4.7.2
Retention Period for Archive ................................................................... 70
4.7.3
Protection of Archive ............................................................................. 70
4.8
Key Changeover .............................................................................................. 71
4.9
Compromise and Disaster Recovery ................................................................... 71
4.9.1
Computing Resources, Software, and/or Data are Corrupted ...................... 72
4.9.2
Authorized CA Public Key Is Revoked ...................................................... 72
4.9.3
Private Key Is Compromised (Key Compromise Plan) ................................ 72
4.9.4
Facility after a Natural or Other Disaster (Disaster Recovery Plan) .............. 73
4.10
Authorized CA Cessation of Services................................................................... 73
4.11
Customer Service Center .................................................................................. 74
Physical, Procedural And Personnel Security Controls ............................................. 75
5.1
5.2
Physical Security Controls ................................................................................. 75
5.1.1
Physical Access Controls ........................................................................ 75
5.1.2
Security Checks .................................................................................... 77
5.1.3
Media Storage ...................................................................................... 77
5.1.4
Environmental Security ......................................................................... 77
5.1.5
Off-site Backup..................................................................................... 78
Procedural Controls .......................................................................................... 78
5.2.1
Trusted Roles ....................................................................................... 78
5.2.2
Number of Persons Required Per Task (Separation of Roles) ...................... 82
5.2.3
Identification and Authentication for Each Role ......................................... 83
5.2.4
Hardware/Software Maintenance Controls ................................................ 83
5.2.5
Documentation ..................................................................................... 83
5.2.6
Security Awareness Training .................................................................. 83
5.2.7
Retraining Frequency and Requirements .................................................. 84
5.2.8
Job Rotation Frequency and Sequence..................................................... 84
5.2.9
Sanctions for Unauthorized Actions ......................................................... 85
5.2.10 Contracting Personnel Requirements ....................................................... 85
5.2.11 Documentation Supplied to Personnel ..................................................... 85
5.3
6
Personnel Security Controls............................................................................... 85
5.3.1
Access Authorization ............................................................................. 85
5.3.2
Limited Access ..................................................................................... 86
Technical Security Controls ...................................................................................... 88
6.1
106764133
Key Pair Generation and Installation .................................................................. 88
6.1.1
Key Pair Generation .............................................................................. 88
6.1.2
Private Key Delivery to Entity ................................................................. 88
6.1.3
Subscriber Public Key Delivery to Authorized CA (Certificate Issuer)............ 89
6.1.4
ORC ACES CA Public Key Delivery to Users .............................................. 89
6.1.5
Key Sizes............................................................................................. 89
6.1.6
Public Key Parameters Generation .......................................................... 89
6.1.7
Parameter Quality Checking ................................................................... 89
iv
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
6.1.8
Key Usage Purposes (X.509 V3 Key Usage Field) ...................................... 89
6.1.9
Private Key Shared by Multiple Subscribers .............................................. 90
6.1.10 Date/Time stamping ............................................................................. 90
6.2
6.3
6.4
6.5
6.6
6.7
6.8
7
Private Key Protection ...................................................................................... 90
6.2.1
Standards for Cryptographic Modules ...................................................... 90
6.2.2
Private Key Backup ............................................................................... 91
6.2.3
Private Key Archival .............................................................................. 91
6.2.4
Private Key Entry Into Cryptographic Module ............................................ 91
6.2.5
Method of Activating Private Key ............................................................ 92
6.2.6
Method of Deactivating Private Key ......................................................... 92
6.2.7
Method of Destroying Private Key ........................................................... 93
Good Practices Regarding Key Pair Management .................................................. 93
6.3.1
Public Key Archival................................................................................ 93
6.3.2
Private Key Archival .............................................................................. 93
6.3.3
Usage Periods for the Public and Private Keys .......................................... 93
6.3.4
Restrictions on CA's Private Key Use ....................................................... 93
6.3.5
Private Key Multi-person Control............................................................. 93
6.3.6
Private Key Escrow ............................................................................... 94
Activation Data ................................................................................................ 94
6.4.1
Activation Data Installation and Generation ............................................. 94
6.4.2
Activation Data Protection ..................................................................... 95
6.4.3
Other Aspects of Activation Data ............................................................ 95
Computer Security Controls .............................................................................. 95
6.5.1
Audit ................................................................................................... 95
6.5.2
Technical Access Controls ...................................................................... 97
6.5.3
Identification and Authentication ............................................................ 97
6.5.4
Trusted Paths ....................................................................................... 97
Life Cycle Technical Controls ............................................................................. 98
6.6.1
System Development Controls (Environment Security) .............................. 99
6.6.2
Security Management Controls ............................................................... 99
6.6.3
Object Reuse ...................................................................................... 100
Network Security Controls ............................................................................... 100
6.7.1
Remote Access/Dial-up Access .............................................................. 101
6.7.2
Firewalls ............................................................................................. 101
6.7.3
Encryption .......................................................................................... 102
6.7.4
Interconnections .................................................................................. 102
6.7.5
Router ................................................................................................ 103
6.7.6
Inventory of Network Hardware/Software ............................................... 103
Cryptographic Module Engineering Controls........................................................ 103
Certificate And CRL Profiles ................................................................................... 104
7.1
Certificate Profile ............................................................................................ 104
7.1.1
106764133
Version Numbers ................................................................................. 104
v
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
7.2
7.3
8
7.1.2
Certificate Extensions ........................................................................... 104
7.1.3
Algorithm Object Identifiers .................................................................. 104
7.1.4
Name Forms ....................................................................................... 105
7.1.5
Name Constraints ................................................................................ 105
7.1.6
Certificate Policy Object Identifier .......................................................... 105
7.1.7
Usage of Policy Constraints Extension .................................................... 105
7.1.8
Policy Qualifiers Syntax and Semantics ................................................... 105
7.1.9
Processing Semantics for the Critical Certificate Policy Extension ............... 105
CRL Profile ..................................................................................................... 105
7.2.1
Version Numbers ................................................................................. 106
7.2.2
CRL and CRL Entry Extensions ............................................................... 106
OCSP Request – Response Format .................................................................... 106
CPS Administration ................................................................................................ 107
8.1
CPS Change Procedures ................................................................................... 107
8.1.1
List of Items ....................................................................................... 107
8.1.2
Comment Period .................................................................................. 107
8.2
Publication and Notification Procedures .............................................................. 107
8.3
CPS and External Approval Procedures .............................................................. 107
8.4
Waivers ......................................................................................................... 107
Appendix A: Relying Party Agreement ................................................................................ A1
Appendix B: Acronyms And Abbreviations ........................................................................... B1
Appendix C: Auditable Events Table .................................................................................... C1
Appendix D: Applicable Federal and GSA Regulations ......................................................... D1
Appendix E: ORC ACES Profile Formats ............................................................................... E1
E.1
ACES Root CA Self-Signed Certificate ..................................................................E1
E.2
Authorized CA Certificate Profile .........................................................................E2
E.3 Unaffiliated Individual Identity Certificate ..................................................................E3
E.3(a) Unaffiliated Individual Identity Certificate Hardware ...............................................E4
E.4 Unaffiliated Individual Encryption Certificate ..............................................................E5
E.4(a) Unaffiliated Individual Encryption Certificate Hardware ...........................................E6
E.5 Business Representative Identity Certificate ..............................................................E7
E.5(a) Business Representative Identity Certificate Hardware ............................................E8
E.6 Business Representative Encryption Certificate ...........................................................E9
E.6(a) Business Representative Encryption Certificate Hardware ...................................... E10
E.7
Relying Party Application Identity Certificate ...................................................... E11
E.8
Relying Party Application Encryption Certificate .................................................. E12
E.9 Federal Employee Identity Certificate ...................................................................... E13
E.9(a) Federal Employee Identity Certificate Hardware ................................................... E14
E.10 Federal Employee Encryption Certificate ................................................................ E15
E.10(a) Federal Employee Encryption Certificate Hardware ............................................. E16
E.11 Federal Agency Application Encryption (SSL) Certificate .......................................... E17
E.12 State and Local Employee Identity Certificate......................................................... E18
106764133
vi
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.12(a) State and Local Employee Identity Certificate Hardware ...................................... E19
E.13 State and Local Employee Encryption Certificate ..................................................... E20
E.13(a) State and Local Employee Encryption Certificate Hardware .................................. E21
E.14 State and Local Server (SSL) Certificate ................................................................ E22
E.15 Code Signing Certificate ...................................................................................... E23
E.16 Non Government Component Certificate ................................................................ E24
E.17 Domain Controller Certificate ............................................................................... E25
E.18 ORC Government Root CRL .................................................................................. E26
E.19 ORC ACES CA CRL .............................................................................................. E26
E.20 OCSP REQUEST FORMAT ..................................................................................... E27
E.21 OCSP Response Format ...................................................................................... E27
Appendix F: Security Officer Appointment Letter ................................................................ F1
Appendix G: References ...................................................................................................... G1
Appendix H: Glossary .......................................................................................................... H1
106764133
vii
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
1
Introduction
1.1 Overview
This Certificate Practice Statement (CPS) is the implementation document for
Operational Research Consultant’s (ORC’s) Access Certificates for Electronic Services
(ACES) Program (also known as the ORC ACES Public Key Infrastructure, “ORC
ACES PKI”). The General Services Administration (GSA) Office of Government-wide
policy (OGP) and Federal Technology Services (FTS) has designated ORC as an ACES
"Authorized Certification Authority (CA)" by:

Entering into an appropriate GSA ACES contract with ORC.

Reviewing the specific practices and procedures ORC implements to satisfy the
requirements of the ACES Certificate Policy (CP) in this certificate practice
statement.

Successfully completing a GSA's ACES Security Certification and Accreditation.

Approving this CPS.
This CPS is applicable to individuals, business representatives, Federal employees, State
and Local Government employees, relying parties, and agency applications who [that]
directly use these certificates, and who are responsible for applications or servers that
use certificates. Certificate users include, but are not limited to, Certificate Management
Authorities (CMAs), Registration Authorities (RAs), Issuing Authorities (IAs), Local
Registration Authorities (LRAs), subscribers, and relying parties.
This CPS applies to X.509 version 3 certificates with assurance levels as defined in the
ACES CP and the Common Policy Framework CP, as used to protect information up to
and including Sensitive But Unclassified (SBU). The policies and procedures in this
CPS are applicable to individuals who manage the certificates, who directly use these
certificates, and individuals who are responsible for applications or servers that rely on
these certificates.
In accordance with the stipulations of the Common Policy Framework CP, this CPS and
the ORC ACES subordinate CA that issues Federal employee will be updated to support
the use of 2048 bit RSA keys and the SHA-256 hash algorithm.
The CPS describes the operations of the ORC ACES PKI and the services that the ORC
ACES PKI provides. These services include:

106764133
Subscriber Registration: A subscriber or certificate applicant must appear in person
before an ORC Registration Authority (RA), an approved Local Registration
Authority (LRA) or a registered Notary Public (or a person legally empowered to
witness and certify the validity of documents and to take affidavits and depositions),
as stipulated by the Policy Authority, present valid identification (driver’s license,
passport, etc.), sign the subscriber’s obligation and mail the forms to ORC.
1
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Subscriber Enrollment: The ORC ACES system provides Federal Information
Processing Standards (FIPS) 140-1/2 Level 3 Secure Socket Layer (SSL)
connections to the certification authority. The subscriber must use a FIPS 140-1/2
Level 1 or 2 client for connection for enrollment.

Enrollment Validation: The ORC ACES registration process validates the subscriber
enrollment information (see above).

Certificate Issuance: When notified by an RA of a valid enrollment request, an ORC
IA issues the requested certificate for delivery to a FIPS 140-1/2 Level 1 or 2 client.
A FIPS 140-1 Level 1 issuance does not require a hardware token. ORC then notifies
the subscriber of the issuance and provide instructions for receiving the certificate.

Certificate Publishing: When a certificate is issued, the ORC publishes it to a
Lightweight Directory Access Protocol (LDAP) directory. The directory may be
accessed via Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS)
gateway or via the LDAP protocol.

Encryption Key Storage: Optional storage (escrow) of encryption keys.

Key Recovery: If encryption key storage (escrow) is selected.

Certificate Status information: In the form of Certificate Revocation Lists (CRLs)
distribution and Online Certificate Status Protocol (OCSP) responses.
To assist in providing these services and in meeting the reporting requirements outlined
in this CPS, ORC maintains a website, which contains instructions, online forms, a
summary of this CPS, compliance audit results, and copies of certificates and CRLs. The
majority of the information on the website is publicly accessible, although it incorporates
SSL to promote data integrity and to allow users to validate the source of the
information. Portions of the website are access controlled and require certificate
authentication for access to authorized individuals.
ORC is periodically audited by its independent auditor against this CPS and operates
primary and secondary secure data centers in conformance with the Department of
Defense (DoD), National Security Agency (NSA), U.S. General Services Administration
(GSA) and commercial practices.
1.2 Policy Identification
The ACES CP is registered with the Computer Security Objects Register (CSOR) at the
National Institute of Standards and Technology (NIST). The ORC ACES PKI and each
CA complies with the following object identifiers (OIDs) for the ACES Certificates
defined in this CPS:
106764133

ACES Authorized CA Certificates: {2 16 840 1 101 3 2 1 1 1}

Unaffiliated Individual Digital Signature Certificates: {2 16 840 1 101 3 2 1 1 2}

Unaffiliated Individual Encryption Certificates: {2 16 840 1 101 3 2 1 1 2}

Business Representative Digital Signature Certificates: {2 16 840 1 101 3 2 1 1 3}

Business Representative Encryption Certificates: {2 16 840 1 101 3 2 1 1 3}
2
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Relying Party Digital Signature Certificates: {2 16 840 1 101 3 2 1 1 4}

Relying Party Encryption Certificates: {2 16 840 1 101 3 2 1 1 4}

Agency Application SSL Server Certificates: {2 16 840 1 101 3 2 1 1 5}

Federal Employee Digital Signature Certificates: {2 16 840 1 101 3 2 1 1 6}

Federal Employee Encryption Certificates: {2 16 840 1 101 3 2 1 1 6}

Federal Employee Digital Signature Certificates on hardware tokens: {2 16 840 1
101 3 2 1 1 7}

Federal Employee Encryption Certificates on hardware tokens: {2 16 840 1 101 3 2 1
1 7}

State and Local Employee Digital Signature Certificates: {2 16 840 1 101 3 2 1 1 6}

State and Local Employee Encryption Certificates: {2 16 840 1 101 3 2 1 1 6}

State and Local Employee Digital Signature Certificates on hardware token: {2 16
840 1 101 3 2 1 1 7}

State and Local Employee Encryption Certificates on hardware token: {2 16 840 1
101 3 2 1 1 7}

Code Signing Certificates on hardware token: {2 16 840 1 101 3 2 1 12 1}, {2 16
840 1 101 3 2 1 12 2}
Certificates issued under this CPS also contains and complies with the following U.S.
Federal PKI Common Policy Framework1 object identifiers (OIDs) for the ACES
Certificates defined in this CPS:

Subscriber certificates not on hardware tokens, id-fpki-common-policy::={2 16 840
1 101 3 2 1 3 6}

Subscriber certificates on hardware tokens, id-fpki-common-hardware::={2 16 840 1
101 3 2 1 3 7}

Device certificates: id-fpki-common-devices::={2 16 840 1 101 3 2 1 3 6}
ORC ACES Certificates issued under this CPS reference the ACES CP and the Common
Policy Framework by including the appropriate OID, identified above, in the Certificate
Policies field. The foregoing OIDs may not be used except as specifically authorized by
the ACES CP and the Common Policy Framework CP. Unless specifically approved by
the Federal PKI Policy Authority, ORC ACES CAs do not assert the FBCA CP OIDs in
any certificates issued, except in the policyMappings extension establishing an
equivalency between an FBCA OID and an OID in the ACES CP. Only the OIDs
identified above are used within ORC ACES certificates with the exception of the
policyMappings extension, which may assert other PKI Policy OIDs for purposes of
1 The requirements associated with the US Federal PKI Common Policy Framework
OIDs are incorporated by reference.
106764133
3
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
cross certification of the ORC ACES PKI to another PKI. CSOR information is
available from 1) http://csrc.nist.gov/csor/csor.html, and 2) csor@nist.gov.
The ORC ACES PKI and this CPS support medium and medium-hardware assurance
levels as defined in Section 1.3.4.6.
1.3 Community and Applicability
This CPS describes the rights and obligations of persons and entities authorized under
this CPS to fulfill the roles of an ORC ACES Certificate Service Provider and End Entity
(EE). As an ACES Certificate Service Provider and a GSA Shared Service Provider,
ORC provides an ACES Certification Authority, Registration Authority, Certificate
Manufacturing Authority, and Repository. EE roles include Subscriber, Federal
Employee, Server, and Relying Party. Requirements for persons and entities authorized
to fulfill any of these roles are included in this section. A description of each of these
roles and their responsibilities is set forth in Section 2 of this CPS.
The ORC ACES program supports entities transacting electronic business with or
business for U.S. Government entities. ORC ACES Subscribers may include
Unaffiliated Individuals, Business Representatives, members of Federal, State, and Local
Government agencies and their trading partners. The GSA Shared Service Provider
program provides certificate issuance to Federal employees, contractors and other
affiliated personnel for the purposes of authentication, signature, and confidentiality.
1.3.1
Certificate Service Providers
Under this CPS, the ORC ACES CAs, Certificate Authority Administrators (CAAs), and
IAs are considered “Certificate Management Authorities” (CMAs) and are the only
authorities with direct trusted access to the ORC ACES CA’s applications and keys.
This CPS uses the term CMA when a function may be assigned to an ORC ACES CA,
CAA, or IA; or when a requirement applies to an ORC ACES CA, CAA, and/ or IA. The
division of responsibilities is described in this CPS. ORC server-based Certificate Status
Authorities (CSAs) are also considered CMAs. This CPS details the procedures that
ensure that all CMAs are in compliance with the ACES CP.
There are two additional roles that are critical to the operation of the PKI, the Corporate
Security Auditor and the System Administrator (SA). The Corporate Security Auditor is
designated within ORC as an individual who is not in the reporting chain under the
CAA. The Corporate Security Auditor is responsible for providing independent auditing
of the CA services. Corporate Security Auditor duties are a secondary job function. The
Corporate Security Auditor is an employee of ORC and is designated in Appendix G.
SAs are responsible for managing the CA server at the operating system level. All SAs
in support of this CPS are employees of ORC.
1.3.1.1
Certification Authorities
ORC issues certificates as an ACES “Authorized CA”, as stipulated in Section 1.1 of the
ACES CP. Each ORC ACES CA is under an autonomous root. The ORC ACES CA
106764133
4
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
operations follow guidance in accordance with the IETF PKIX Part 4 format. The ORC
ACES PKI generates and manages certificates and certificate revocation. It posts those
certificates and CRLs to an LDAP directory.
1.3.1.1.1
Certification Authority Administrator (CAA)
CAAs, as defined herein, administer the ORC ACES CAs and CSAs. CAAs are the only
authorities authorized to administer a CA or CSA. CAAs are ORC employees
designated directly by ORC’s President. ORC CAAs designate IAs and RAs and
perform tasks required for CA/CRL management.
1.3.1.1.2
Issuing Authorities (IAs)
IAs are the only authorities authorized to approve the issuance of ORC certificates. IAs
approve the issuance of certificates to EEs upon receipt of an identity validation,
digitally signed by an authorized RA. IAs are ORC employees and are designated
directly by an ORC CAA and are issued IA certificates stored on hardware tokens for the
purpose of issuing validated certificates to applicants. IAs appear in person to an ORC
CAA for identity verification with a valid, official photo ID. IAs are provided training in
issuing certificates and in the policies and processes of this CPS prior to being issued
their IA certificates. IA duties are a primary job responsibility for these individuals.
ORC IAs are employees of ORC or subcontract personnel only. The ORC IAs approve
the issuance of ORC certificates by accessing an ORC ACES CA from an ORC IA
workstation that securely communicates with the CA.
1.3.1.2
Registration Authorities
RAs are employed by ORC and designated directly by an ORC CAA and are issued RA
certificates for the purpose of submitting digitally signed verification of applicant
identities and information to be entered into public key certificates. ORC RAs use
hardware tokens for their RA certificates. RAs appear in person to either a CAA or an
IA for identity verification with official identification, in accordance with the
requirements of Section 3.1.9. RAs are provided training in identity proofing and in the
policies and processes of this CPS prior to being issued their RA certificates. RA
certificates are not valid for performing administrative tasks on the CA or IA equipment,
including issuing or revoking certificates.
1.3.1.2.1
Local Registration Authorities
ORC RAs may delegate the identity proofing tasks to LRAs. LRAs can be ORC
employees on location at a subscriber’s organization or employees of a subscriber’s
organization. LRAs perform duties identical to RAs, but have their identity validated by
RAs instead of a CAA or IA. Upon performing their duties, LRAs provide verification to
RAs via mail or signed email (using a medium hardware assurance certificate). If an RA
delegates duties to one or more LRAs, the RA informs the CAAs. LRAs may not
designate other LRAs. RA certificates are not valid for performing administrative tasks
on the CA or IA equipment, including issuing or revoking certificates.
1.3.1.2.2
106764133
Notaries Public
5
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Notaries Public (or other persons legally empowered to witness and certify the validity of
documents and to take affidavits and depositions) are not designated authorities of ORC.
These persons may only validate the identity of individuals who are unable to present
their identity credentials in person to an RA or LRA. In this situation, the subscriber is
provided with a form, which they print, and includes the subscriber’s name,
organizational affiliation (as appropriate), and the certificate request identification
number. The subscriber is required to present this form, along with required
identification and credentials identifying organizational affiliation. The Notaries Public
(or other persons legally empowered to witness and certify the validity of documents and
to take affidavits and depositions) shall witness and certify the signature on the form and
required IDs.
Note: In certain instances, ORC may identify one of the above officials to act in the
role of compliance auditor and/or attribute authority. An official performing
registration functions cannot audit the registration process and vice versa. The
subscriber is required to submit the notarized form and copies of the information
used to establish identity via certified mail to an IA.
1.3.1.3
Certificate Manufacturing Authorities
ORC performs the role and functions of the Certificate Manufacturing Authority under
the ORC ACES Program. Under this CPS, ORC performs all the functions of a
“Certificate Manufacturing Authority”, as defined in the ACES CP.
1.3.1.4
Repositories
ORC performs the role and functions of the repository under the ORC ACES Program.
1.3.2
End Entities (EE)
An EE is a holder of a certificate that is at the end of a certificate chain.
1.3.2.1
Subscribers
A subscriber is the EE whose name appears as the subject in a certificate, and who
asserts that it uses its key and certificate in accordance with this CPS. Subscribers are
limited to the following categories of entities:
106764133

Unaffiliated Individuals, including citizens of the United States conducting personal
business with a U.S. Government agency at local, state or Federal level

Employees of businesses acting in the capacity of an employee and conducting
business with a U.S. Government agency at local, state or Federal level

Employees of state and local governments conducting business on behalf of their
organization

Individuals communicating securely with a U.S. Government agency at local, state or
Federal level, and
6
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Qualified Relying Parties, including: workstations, guards and firewalls, routers,
trusted servers (e.g., database, File Transfer Protocol (FTP), and World Wide Web
(WWW)), and other infrastructure components communicating securely with, or for,
a U.S. Government agency at local, state or Federal level. These components must
be under the cognizance of humans, who accept the certificate and are responsible
for the correct protection and use of the associated private key.
The ORC ACES CAs are technically a subscriber to the PKI; however, the term
subscriber as used in this CPS refers only to those EEs who request certificates for uses
other than signing and issuing certificates.
1.3.2.2
Relying Party
Relying parties are those persons and entities authorized to accept and rely upon ACES
Certificates for purposes of verifying digital signatures. A Relying Party is an individual
or organization that, by using another’s certificate can:

Verify the integrity of a digitally signed message.

Identify the creator of a message, or establish confidential communications with the
holder of the certificate.

Rely on the validity of the binding of the subscriber’s name to a public key.
Relying parties are those eligible Federal agencies and entities that enter into an
agreement with GSA to accept ACES Certificates and agree to be bound by the terms of
the ACES CP and this CPS. Eligible federal agencies and entities include all Federal
agencies, authorized federal contractors, agency-sponsored universities and laboratories,
other organizations, and, if authorized by law, state, local, and tribal governments.
Note: At their own risk, 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.2.3
Agency Applications
ORC is authorized to issue ACES certificates to authorized agency applications
performing various functions.
106764133

SSL Server Certificates are for use on Agency Servers to allow mutual
authentication and/or trusted SSL communications with Agency customers.

Signing-only certificates are for use on agency applications for the purpose
of providing Agency Customers with signed return receipt notifications.

Data encryption certificates are for use on agency applications for the
purposes of encrypting agency application sensitive data.

Other certificate types are for use as needed by an Agency or agency
application, such as IPSEC certificates, Code signing certificates, etc.
7
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
1.3.2.3.1
Agency Application SSL Server Certificates
ORC is authorized to issue ACES Agency Application SSL Server Certificates for use on
Agency Servers to allow mutual authentication and/or trusted SSL communications with
Agency customers. These SSL Server Certificates are issued to the agency server where
the common name is the registered Domain Name of the Agency’s Web server.
Certificates allow for both server and client authentication through the extended
KeyUsage extension. The server designated in the certificate request is the only system
on which the certificate is to be installed. Agency applications are to use ORC ACES
SSL Server Certificates only for authorized applications meeting the requirements of this
CPS. All obligations related to obtaining and using ORC ACES SSL Server Certificates
can be found in Section 2.1.5 of this CPS.
1.3.2.3.2
Agency Application (Signing)
ORC is authorized to issue ACES “signing-only” certificates to agency applications for
the purpose of providing Agency Customers with signed return receipt notifications
acknowledging that the agency application received the customer’s transaction.
Additionally, an agency application may utilize signing certificates to sign internal data
(customer transactions, application log files or agency archive data) where required by
the agency policies.
1.3.2.3.3
Agency Application (Encryption)
ORC is authorized to issue ACES data encryption certificate to an agency application for
the purposes of encrypting agency application sensitive data where agency policy
dictates.
Note: ORC also provides an optional encryption private key escrow and recovery
service.
1.3.2.3.4
Agency Application (Other)
ORC is authorized to issue other ACES certificates as needed by an authorized agency or
agency application including IPSEC and Code Signing Certificates.
1.3.3
Policy Authority
The GSA serves as the Policy Authority and is responsible for organizing and
administering the ACES Certificates Policy and the ORC ACES Contract.
1.3.4
1.3.4.1
Applicability
Purpose
The ACES PKI supports the following security services: confidentiality, integrity,
authentication and technical non-repudiation. The ORC ACES PKI supports these
security services by providing Identification and Authentication (I&A), integrity, and
technical non-repudiation through digital signatures, and confidentiality through key
106764133
8
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
exchange. These basic security services support the long-term integrity of application
data, but may not by themselves provide a sufficient integrity solution for all application
circumstances. For example, when a requirement exists to verify the authenticity of a
signature beyond the certificate validity period, such as contracting, other services such
as trusted archival services or trusted timestamp may be necessary. These solutions are
application based, and must be addressed by subscribers and Relying Parties. ORC
provides support of security services to a wide range of applications that protect various
types of information, up to and including sensitive unclassified information.
ACES Digital Signature Certificates may be used to authenticate subscribers to Relying
Party applications for individual and/or business purposes, and for authentication of
Relying Party applications. Subscribers and Agency Applications may use ACES
Encryption Certificates to employ the confidentiality service on the data exchanged.
Subscribers and Agency Applications may also use ACES Code Signing Certificates for
the secure distribution of code. The following table summarizes the functional uses of
ORC ACES Certificates:
Table 1- ORC ACES Certificates Functional Use
Certificate Type
Unaffiliated
Individual
(Medium or
Medium
Hardware
Assurance
Certificates)
Business
Representative
Certificates
(Medium or
Medium
Hardware
Assurance
Certificates)
State and Local
Government
Representative
Certificates
(Medium or
Medium
Hardware
Assurance
Certificates)
Relying Party
(Agency
Application)
Certificates
106764133
Subscriber
Unaffiliated
Individual
Purpose
Use of Certificate
To enable Unaffiliated Individual ORC ACES
subscribers and Relying Parties to mutually
authenticate themselves electronically for information
and transactions and to verify digitally signed
documents/transactions
To enable an unaffiliated individual ORC ACES
subscriber to use confidentiality services (encryption
and decryption) on his/her information and transactions
To enable Business Representatives to mutually
authenticate themselves to conduct business-related
activities electronically and to verify digitally signed
documents/ transactions
Digital
Signature
Encryption
Business
Representative
authorized to
act on behalf of
a Sponsoring
Organization
Government
Employees
authorized to
act on behalf of
a State or Local
Government
Relying Party
Digital
Signature
Encryption
To enable a Business Representative to use
confidentiality services (encryption & decryption) on
his/her information and transactions
Digital
Signature
To enable State or Local Government Representatives
to mutually authenticate themselves to conduct
business-related activities electronically and to verify
digitally signed documents/transactions
Encryption
To enable a State or Local Government Representative
to use confidentiality services (encryption and
decryption) on his/her information and transactions
Digital
Signature
To enable Relying Party & Unaffiliated Individuals,
Business Representatives (Non-Federal Employees),
Federal, State, & Local Government Employees, &
Authorized CAs; to mutually authenticate themselves;
to make signed validation requests; & to sign log files.
9
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Certificate Type
Subscriber
Purpose
Use of Certificate
To enable a Relying Party to provide confidentiality
services (encryption and decryption) to subscribers on
their information and transactions
Encryption
Agency
Application SSL
Server Certificates
Federal Employee
Certificates
(Medium or
Medium
Hardware
Assurance
Certificates)
Authorized CA
Certificate
Code Signing
Medium
Hardware
Assurance
Certificate
Authentication
& Encrypted
Data
Transmission
To enable authenticated encrypted communications
between subscribers and servers
Federal
Employee
Digital
Signature
To enable Federal Employees and Relying Parties to
mutually authenticate themselves and verify digitally
signed documents/transactions
Federal
Employee
Encryption
To enable a Federal Employee to use confidentiality
services (encryption and decryption) on his/her
information and transactions
Server
To enable the Authorized CA to issue subscriber
certificates.
N/A
Individual
authorized to
act on behalf of
a Sponsoring
Organization
1.3.4.2
To enable the secure distribution of code to an
authorized community of users.
Code Signing
Suitable Uses
ACES Certificates are intended for use by individuals, businesses, and Federal, State,
and Local Governments to transact business with the Federal Government. Non-Federal
Government participants who would otherwise be involved in such transactions provided
that the Federal Government does not incur any additional costs may also use ACES
Certificates. Examples of suitable uses include, but are not limited to:

Personal or restricted information retrieval

Updating personal or restricted information

Filings with government agencies

Application processes, such as applying for government licenses, student loans,
government benefits, etc.

Financial transactions with government agencies

Distribution of code
Relying Parties must evaluate the environment and the associated threats and
vulnerabilities, as well as 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
Agency for each application and is not controlled by this CPS.
1.3.4.3
Level of Assurance
The level of assurance associated with a public key certificate is an assertion by a CA of
the degree of confidence that a Relying Party may reasonably place in the binding of a
106764133
10
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
subscriber’s public key to the identity and privileges asserted in the certificate.
Assurance level depends on the proper registration of subscribers and the proper
generation and management of the certificate and associated private keys, in accordance
with the stipulations of this policy. Personnel, physical, procedural, and technical
security controls are used to maintain the assurance level of the certificates issued by
ORC under this CPS, defined as Medium Assurance in the ACES CP and the Federal
Bridge CA.
1.3.4.4
Factors in Determining Usage
The amount of reliance a Relying Party chooses to place on the certificate is determined
by various risk factors. Specifically, the value of the information, the threat
environment, and the existing protection of the information environment are used to
determine the appropriate level of assurance of certificates required to protect and
authenticate the information.
1.3.4.5
Threat
Threat is any circumstance or event with the potential to cause harm. In terms of
information systems, harm includes destruction, disclosure, denial of service, or
modification of data, processes, or processing components. Threats to systems include
environmental disasters, physical damage, system penetration, and violation of
authorization, human error, and communications monitoring or tampering. It is the
responsibility of each relying party to assess the factor.
1.3.4.6
General Usage
This section contains definitions for two levels of assurance, and guidance for their
application. The guidance is based on the previous discussion of information value and
environmental protection. Emphasis is placed on two types of activity: integrity and
access control to information considered sensitive, and information related to electronic
financial transactions and other e-commerce. The final selection of the security
mechanisms, and level of strength and assurance, requires a risk management process
that addresses the specific mission and environment. Each Relying Party is responsible
for carrying out this risk analysis.
1.3.4.6.1
Medium Assurance (Software Certificate)
This level is intended for applications handling sensitive medium value information
based on the relying party’s assessment, which may include:
106764133

Non-repudiation for small and medium value financial transactions other than
transactions involving issuance or acceptance of contracts and contract modifications

Authorization of payment for small and medium value financial transactions

Authorization of payment for small and medium value travel claims

Authorization of payment for small and medium value payroll

Acceptance of payment for small and medium value financial transactions
11
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
1.3.4.6.2
Medium Hardware Assurance:
This level is intended for all applications operating in environments appropriate for
medium assurance but which require a higher degree of assurance and technical nonrepudiation based on the relying party’s assessment.

All applications appropriate for medium assurance certificates

Mobile code signing

Applications performing contracting and contract modifications
1.3.4.7
Prohibited Applications
This CPS prohibits the use of any application that does not follow approved standards
for the storage and transmittal of cryptographic information. Applicable standards
include:

FIPS 140-1, Security Requirements for Cryptographic Modules;

FIPS 180-1, Secure Hash Algorithm;

FIPS 186-1, Digital Signature Standard

PKCS #11 Hardware Format; and

PKCS #12 Software Format.

X.509 v2 Information Technology – ASN.1 Encoding Rules 1994

ANSI X9.31 American National Standard for Digital Signature using Reversible
Public Key Cryptography for the Financial Service Industry
1.3.5
1.3.5.1
Related Authorities
Compliance Auditors
Compliance audits as stipulated in this CPS are independently administered by ORC’s
Corporate Security Auditors. Corporate Security Auditors are not in any way under the
control of CAAs. Nor are CAAs under the control of Corporate Security Auditors. The
Corporate Security Auditors maintain the ORC internal audit system and are designated
directly by ORC’s President.
ORC’s Corporate Security Auditors also coordinate and support external auditing,
including aperiodical audits by: GSA, DoD and NSA; and the American Institute of
Certified Public Accountants (AICPA) WebTrust Program for Certification Authorities
or other current industry accepted standards and practices, as described herein.
1.3.5.2
Certificate Status Authorities
A Certificate Status Authority (CSA) uses Online Certificate Status Protocol (OCSP)
that provides revocation status and/or certificate validation responses. The ORC ACES
CSA conforms to the stipulations of the ACES CP and this CPS.
106764133
12
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
1.3.5.3
Code Signing Attribute Authorities
A Code Signing Attribute Authority (CSAA) is a duly appointed organization sponsor
who has been granted signature authority for an organization/agency. The Code Signing
Attribute Authority authorizes applications or individuals for a code-signing certificate
for the designated organization/agency.
1.4 Contact Details
1.4.1
Policy Administration Organization
GSA, as the Policy Authority and Contract Authority administers the ACES Certificate
Policy:
General Services Administration
18th and F Streets, NW
Washington, DC 20405-0007
1.4.2
Policy Contact Personnel
Office of Electronic Government and Technology
Office of Government-wide Policy
Phone: (202) 501-0202
1.4.3
Person Determining CPS Suitability for the Policy
The government has determined the suitability of this CPS as part of the evaluation
process. Any changes to this CPS made after determination of suitability shall be
transmitted to the Government for approval prior to incorporation.
GSA/FTS is responsible for ensuring that this CPS conforms to the ACES CP and ACES
Contracts.
Stephen Duncan, ACES Program Manager
Federal Technology Service
General Services Administration
Phone: (202) 708-7626
e-mail address: stephen.duncan@gsa.gov
1.4.4
CPS Administration Organization
The Board of Directors of Operational Research Consultants, Inc., administers ORC PKI
organization. The ORC PKI Project Director is responsible for registration,
maintenance, and interpretation of this CPS. PKI Project Director, 11250 Waples Mill,
South Tower, Ste 210, Fairfax, VA 22030.
106764133
13
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
2
General Provisions
This section provides a description of the roles and responsibilities of the ORC ACES
system operating under this CPS.
2.1 Obligations
Additional obligations are set forth in other provisions of the ACES CP, the ORC ACES
Contract (including the requirements of this CPS, System Security Plan (SSP), Privacy
Practices and Procedures (PPP)), ORC-ACES Agreements with Relying Parties, and the
Subscriber Agreements.
2.1.1
Authorized CA Obligations
ORC accepts responsibility for all aspects of the issuance and management of ORC
ACES Certificates, which include:

The application/enrollment process

The identification verification and authentication process

The certificate manufacturing process which has the private key residing only in the
applicant’s possession (the key length is 1024 bits)

Dissemination and activation (i.e., certificate issuance/manufacturing) of the
certificate

Publication of the certificate

Renewal, suspension, revocation, and replacement of the certificate

Verification of certificate status upon request

Notifying subscribers of receipt of their request to change information

Ensuring that all aspects of the ACES Certificates issued under this CPS are in
accordance with the requirements, representations, and warranties of this CPS

Provide a customer service center for answering subscriber questions

Weekly review the audit logs that are provided by the System Administrator
ORC accepts the following obligations to the Policy Authority:
106764133

Providing to the Policy Authority this CPS, as well as any subsequent changes, for
conformance assessment

Conforming to the stipulations of the ACES CP and the approved CPS

Ensuring that registration information is accepted only from IAs, RAs, and LRAs
who understand and are obligated to comply with this policy
14
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
ORC accepts the following obligations to Relying Parties who follow the policies of this
CPS:

Ensuring that ACES certificates are issued to the named subscriber

Including only valid and appropriate information in the certificate, and maintaining
evidence that due diligence was exercised in validating that information contained in
the certificate. The information in the certificate is accurate (including, but not
limited to the subscriber Distinguished Name in the subject field and the subject
public key information field)

Ensuring that the subscriber has accepted their certificate

Revoking the certificates of subscribers found to have acted in a manner counter to
subscriber obligations

Ensuring that obligations are imposed on subscribers in accordance with Section
2.1.5 and that subscribers are informed of the consequences of not complying with
those obligations

Notifying subscribers and making public, for the benefit of subscribers and Relying
Parties, any changes to the CA operations that may impact interoperability or
security (i.e., re-key)

Operating or providing for the services of an online repository that satisfies the
obligations under Section 2.6, and informing the repository service provider of those
obligations, if applicable

Posting certificates and CRLs to the repository
ORC also accepts the obligation to maintain records necessary to support requests
concerning its operation, including audit files and archives.
2.1.2
2.1.2.1
RA, LRA and IA Obligations
RA Obligations
RAs are obligated to accurately represent the information prepared for the CA and to
process requests and responses in a timely and secure manner. RAs may designate
LRAs, however LRAs may not designate other LRAs. RAs under this CPS CA are not
authorized to assume any other CA administration functions.
When validating subscriber requests for certificates issued under this CPS, an RA
accepts the following obligations:
106764133

To validate the accuracy of all information contained in the subscriber’s certificate
request

To validate that the named subscriber actually requested the certificate

To verify to the IA that the certificate request originated from the named subscriber
and that the information contained in the certificate request is accurate

To use the RA certificate only for purposes associated with the RA function
15
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

To request revocation and verify reissue requirements of a subscriber’s certificate
upon notification of changes to information contained in the certificate

To request revocation of the certificates of subscribers found to have acted in a
manner counter to subscriber obligations

To immediately request revocation of a subscriber certificate and inform the IA and
the subscriber when a private key compromise is suspected

To inform subscribers and the IA of any changes in RA status

To protect the RA certificate private keys from unauthorized access

To immediately request revocation of an RA certificate and report to the IA if private
key compromise is suspected

To ensure that obligations are imposed on subscribers in accordance with Section
2.1.5

To inform subscribers of the consequences of not complying with those obligations
An RA who is found to have acted in a manner inconsistent with these obligations is
subject to revocation of RA responsibilities.
2.1.2.2
LRA Obligations
LRAs are obligated to accurately represent the information prepared for the RA. LRAs
may not designate other LRAs under this CPS. LRAs under this CPS are not authorized
to assume any other CA administration functions.
When validating subscriber requests for certificates issued under this CPS, an LRA
accepts the following obligations:

To validate that the named subscriber actually requested the certificate

To use the LRA certificate only for purposes associated with the LRA function

To request revocation and verify reissue requirements of a subscriber’s certificate
upon notification of changes to information contained in the certificate

To request revocation of the certificates of subscribers found to have acted in a
manner counter to subscriber obligations

To inform subscribers and an RA of any changes in LRA status

To protect the LRA certificate private keys from unauthorized access

To immediately request revocation of the LRA certificate and report to the RA if
private key compromise is suspected

To ensure that obligations are imposed on subscribers in accordance with Section
2.1.5

To inform subscribers of the consequences of not complying with those obligations
An LRA who is found to have acted in a manner inconsistent with these obligations is
subject to revocation of LRA responsibilities.
106764133
16
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
2.1.2.3
IA Obligations
The IA accepts the following obligations:

Approve the issuance of certificates only when both the subscriber’s request and the
trusted agent validation have been received

Notify the subscriber through e-mail or other means that the certificate request has or
has not been granted in accordance with Section 2.6.1

Notify a subscriber of certificate revocation in accordance with Section 2.6.2

To use the IA certificate only for purposes associated with the IA function

To immediately revoke a RA, LRA or subscriber certificate and inform the
certificate holder if private key compromise is suspected

To revoke (and approve the re-issuance of, if necessary) subscriber certificates that
were validated by an RA or LRA whose private key is suspected to be compromised

To inform the CAA of any changes in IA status

To protect the IA certificate private key from unauthorized access

To immediately revoke the IA certificate and report to the CAA if private key
compromise is suspected
An IA who is found to have acted in a manner inconsistent with these obligations is
subject to revocation of IA responsibilities.
2.1.3
Certificate Manufacturing Authority Obligations
ORC is the Certificate Manufacturing Authority responsible for the functions of
manufacturing, issuance, suspension, and revocation of ACES Certificates Refer to
Section 2.1.1.
2.1.4
Repository Obligations
The ORC ACES Repository is responsible for:

Maintaining a secure system for storing and retrieving ACES Certificates.

Maintaining a current copy of this CPS.

Maintaining other information relevant to ACES Certificates.

Providing information regarding the status of ACES Certificates as valid or invalid
that can be determined by a Qualified Relying Party.
ORC posts ACES certificates and CRL information in an LDAP enabled directory
established by the ORC ACES PKI. Only information contained in the certificate(s) are
posted in this directory to ensure compliance with the Privacy Act. Access is available
via an interoperable implementation of an LDAP directory, with certificate storage
accomplished for sub-trees identified by organization, “o=”. Access to the directory is
also available via Hypertext Transfer Protocol (HTTP) via a directory gateway interface.
106764133
17
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
The ORC ACES directory sub-trees identify the organization of the EE. The ORC
ACES directory gateway is located at:
https://aces.orc.com/dsgw/bin/csearch?context=dsgw
The certificate repository meets the following obligations:

To list all un-expired certificates for the ORC ACES CAs to relying parties

To contain an accurate and current CRL for the respective CAs for use by relying
parties

To be publicly accessible through a web server gateway using HTTPS and FIPS 1401 approved encryption

To be physically accessible, via certificate authenticated access control over SSL, for
authorized requests coordinated with the ORCs point of contact during normal
business hours for the operating organization

To be maintained in accordance with the practices specified in this CPS

To meet or exceed the requirement of 99% availability for all components within the
control of the operating organization [NOTE: Communication failures as a result of
Internet problems external to the operating organization shall not count against this
availability requirement.]
ORC maintains a copy of at least all certificates and CRLs ORC issues and provides this
information to the U.S. Government for archiving. ORC provides this information on a
certificate accessed web server posted no later than 10 days after the end of the
collection of the data.
2.1.5
Subscriber Obligations
When requesting and using a certificate issued under this CPS, a subscriber accepts the
following obligations:
106764133

To accurately represent themselves in all communications with the PKI

To protect the certificate private key from unauthorized access in accordance with
Section 6.2, as stipulated in their certificate acceptance agreements, and local
procedures

To immediately report to the appropriate RA or LRA and request certificate
revocation if private key compromise is suspected

To use the certificate only for authorized applications which have met the
requirements of this CPS

To use the certificate only for the purpose for which it was issued, as indicated in the
key usage extension

To report any changes to information contained in the certificate to the appropriate
RA or LRA for certificate reissue

Abide by all the terms, conditions, and restrictions levied upon the use of their
private keys and certificates
18
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
These obligations are provided to the subscriber during the registration process in the
form of a Subscriber Agreement that the subscriber must read and agree to prior to
completing registration. Theft, compromise or misuse of the private key may cause the
subscriber, Relying Party and their organization legal consequences.
2.1.6
Server/Component Certificate Subscriber Obligations
When requesting, renewing and using a server certificate issued under this CPS, the
applicant agency or company and their PKI Sponsor accept the following obligations:

To accurately represent themselves in all communications with the PKI and abide by
all the terms, conditions and restrictions levied upon the use of the issued private
key(s) and certificate(s).

To protect the certificate private key from unauthorized access in accordance with
Section 6.2.

To immediately report to the appropriate RA and request certificate revocation if
private key compromise is suspected.

In the event of a PKI sponsor change, due to the verified individual having left the
employ of the subscribing company or no longer being assigned as the PKI sponsor
for the certificate, the applicant company must designate a new PKI sponsor and the
new PKI sponsor must complete a new identity verification.

When renewing the server certificate, the PKI sponsor must complete a new identity
verification.

Confirm that you are a current employee of the applying company and that you are
authorized to obtain server certificates for the company by completing and
submitting the “Proof of Organizational Affiliation” letter.

The server designated in the certificate request is the only system on which the
certificate is to be installed.

To use the certificate only for authorized applications that have met the requirements
of this CPS.

To use the certificate only for the purpose for which it was issued, as indicated in the
key usage extension.

To report any changes to information contained in the certificate to the appropriate
RA for certificate reissue processing.
2.1.7
Code Signer Certificate Subscriber Obligations
When requesting and using a code-signing certificate issued under this CPS, the
organization and the code signer accept the following obligations:
106764133

To accurately represent themselves in all communications with the PKI and abide by
all the terms, conditions and restrictions levied upon the use of the issued private
key(s) and certificate(s)

To protect the certificate private key from unauthorized access in accordance with
Section 6.2
19
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

To immediately report to the RA if private key compromise is suspected

Request that the Code Signing Attribute Authority approve and forward to the RA an
authorization on the code signer’s behalf to obtain a code signing certificate

To apply for (generate a key pair) and download the code signing certificate onto a
FIPS 140-1/2 Level 2 validated smart card

When not in use, the Code Signer hardware token shall be stored in a locked
container

Submit the certificate request to the CA via a secure (SSL protected) web session

Digitally sign an e-mail, using acceptable PKI credentials, that contains the subject
Distinguished Name (DN), code signer DN, and the code signing certificate request
number and send it to an ORC RA

In the event of Code Signer change (due to the verified individual having left the
employ of the subscribing organization or no longer being assigned as the code
signer for the certificate) the applicant organization must designate and notify ORC
of the new Code Signer

The Code Signer is a current employee of the organization and is authorized to
obtain a code signing certificate(s) for the organization

To use the certificate only for authorized applications which have met the
requirements of this CPS

To use the certificate only for the purpose for which it was issued, as indicated in the
key usage extension

To report any changes to information contained in the certificate to the appropriate
RA
2.1.8
Relying Party Obligations
This CPS is binding on each Qualified Relying Party by virtue of its GSA ACES
Agreement, and governs its performance with respect to its application for, use of, and
reliance on ACES Certificates.
ORC publicly posts a summary of this CPS on the ORC ACES website (ACES.orc.com)
to provide the relying party information regarding the expectation of the ORC ACES
system. When accepting a certificate issued under this CPS, a relying party accepts the
following obligations:
106764133

Perform a risk analysis to decide whether the level of assurance provided by the
certificate is adequate to protect the Relying Party based upon the intended use

To ensure that the certificate is being used for an appropriate approved purpose

To check for certificate revocation prior to reliance

To use the certificate for the purpose for which it was issued, as indicated in the
certificate information (e.g., the key usage extension)
20
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

To verify the digital signature of the ORC ACE CA that issued the certificate being
relied upon as stipulated in the ACES CP

To establish trust in the ORC ACES PKI by verifying the chain of CA certificates
starting from a trust anchor of the relying party in accordance with the guidelines set
by the X.509 Version 3 Amendment (for the ORC ACES PKI, this trust anchor is the
ORC ACES Self-signed Root CA with no additional chaining)

To acknowledge all warranty and liability limitations

Preserve original signed data, the applications necessary to read and process that
data, and the cryptographic applications needed to verify the digital signatures on
that data for as long as it may be necessary to verify the signature on that data

To abide by all the terms, conditions and restrictions levied upon the use of the
issued private key(s) and certificate(s) as stipulated in the ACES CP
Note: Data format changes associated with application upgrades may invalidate
digital signatures and shall be avoided.
Relying parties that do not abide by these obligations assume all risks associated with the
certificates upon which they are relying.
2.1.8.1
Acceptance of Certificates
As stipulated in the ACES CP, each Qualified Relying Party will validate ACES
Certificates issued by all Authorized CAs.
2.1.8.2
Certificate Validation
As stipulated in the ACES CP, each Qualified Relying Party will validate every ACES
Certificate it requests and receives with the Authorized CA that issued the certificate.
2.1.8.3
Reliance
A Qualified Relying Party may rely on a valid ACES Certificate for purposes of
verifying the digital signature only if:
106764133

The ACES Certificate is used and relied upon to authenticate a subscriber’s digital
signature by an application bound under the ACES Certificate Policy.

Prior to reliance, the Qualified Relying Party (1) verified the digital signature by
reference to the public key in the ACES Certificate, and (2) checked the status of the
ACES Certificate by generating an online status request to the ORC ACES system,
and a check of the certificate’s status indicated that the certificate was valid.

The reliance was reasonable and in good faith in light of all the circumstances known
to the Qualified Relying Party at the time of reliance.
21
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
2.1.9
Policy Authority Obligations
The Policy Authority, as designated in Section 1.4, is responsible for the terms of this
CPS and contract administration.
2.1.10 ORC Certificate Status Authority (CSA) Obligations
ORC operates a CSA using an OCSP responder that provides revocation status and/or
certificate validation responses. The ORC CSA practices conform to the stipulations of
the ACES CP and this CPS. All ORC CSA practice updates, as well as any subsequent
changes are updated in this CPS and submitted to the Policy Authority for conformance
assessment. The CSA practices include:

Conformance to the stipulations of the ACES CP and this CPS.

Ensuring that certificate and revocation information is accepted only from valid CAs.

Providing only valid and appropriate responses.

Maintaining evidence of due diligence being exercised in validating certificate
status.
2.2 Liability
Nothing in this CPS creates, alters, or eliminates any other obligation, responsibility, or
liability that may be imposed on any Program Participant by virtue of any contract or
obligation that is otherwise determined by applicable law.
2.2.1
Authorized CA Liability
As an Authorized CA, ORC stipulates that tort liability for transactions involving
services under the ACES contract(s) are governed by the Federal Tort Claims Act. The
Government Contractor defense is available to ORC to the extent that ORC has met the
standard of care spelled out in this CPS.
2.2.2
RA, IA, CMA, and Repository Liability
No additional stipulations.
2.2.3
Warranties and Limitations On Warranties
ORC warrants that its procedures are implemented in accordance with this CPS, and that
any issued certificates that assert the policy OIDs identified in this CPS, are issued in
accordance with the stipulations of this CPS. ORC warrants that CRLs are issued and
keys generated by ORC are in conformance with this CPS. ORC warrants that any CMA
or ORC designated authority operates in accordance with the applicable sections of this
CPS.
Subscriber organizations that authorize and employ LRAs warrant that:
106764133
22
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

The LRA procedures are implemented in accordance with the ACES CP and this
CPS.

All LRA actions are accomplished in accordance with this CPS.

LRAs operate in accordance with the applicable sections of this CPS.

The organization’s PKI Sponsor will cooperate and assist ORC in monitoring and
auditing authorized LRAs operating in accordance with the applicable sections of
this CPS.

Network security controls to LRA equipment are in accordance with the applicable
sections of this CPS.
ORC does not warrant the actions of Notaries Public or other persons legally empowered
to witness and certify the validity of documents and to take affidavits and depositions.
2.2.4
Damages Covered and Disclaimers
Without limiting other subscriber obligations stated in this CPS, subscribers are liable
for any misrepresentations they make in certificates to third parties who, having verified
one or more digital signatures with the certificate, reasonably rely on the representations
contained therein.
ORC disclaims all warranties and obligations of any type other than those listed in
Sections 2.1 and 2.2.
2.2.5
Loss Limitations
ORC disclaims any liability for loss due to use of certificates issued by the ORC ACES
PKI provided that the certificate(s) and associated CRLs were issued in accordance with
this CPS. ORC disclaims any liability for loss due to use of certificates issued by the
ORC ACES PKI where the relying party has not used validation information in
compliance with this CPS and the ACES CP. ORC acknowledges professional liability
with respect to the ORC ACES PKI, ORC CAs, CMAs and/or the ORC RAs and ORC
LRAs.
2.2.6
Other Exclusions
Certificate applicants and subscribers signify and guarantee that their application does
not interfere with or infringe upon the rights of any others regarding their trademarks,
trade names or any other intellectual property. Certificate applicants and subscribers
shall hold ORC harmless for any losses resulting from any such act.
As a result of issuing a certificate that identifies a person as an employee or member of
an organization, ORC does not represent that the individual has authority to act for that
organization.
106764133
23
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
2.3 Financial Responsibility
2.3.1
Indemnification By Relying Parties and Subscribers
ORC assumes no financial responsibility for improperly used certificates.
2.3.2
Fiduciary Relationships
Issuance of certificates in accordance with this CPS does not make ORC (its designated
authorities or employees) an agent, fiduciary, trustee, or other representative of
subscribers or relying parties. The relationship between ORC (or its designated
authorities or employees) and subscribers and that between ORC (or its designated
authorities or employees) and relying parties is not that of agent and principal. Neither
subscribers nor relying parties have any authority to bind ORC (or its designated
authorities or employees) by contract or otherwise, to any obligation. ORC (or its
designated authorities or employees) make no representations to the contrary, either
expressly, implicitly, by appearance, or otherwise.
2.3.3
Administrative Processes
A nationally known accounting company (approved by the ACES PMO) audits ORC
annually, in accordance with WebTrust. ORC is also audited aperiodically by: GSA,
DoD and NSA. ORC has an independent internal department that performs weekly
procedures in order to attest to ORC’s compliance with this CPS. Audit and inspection
is accomplished in accordance with the American Institute of Certified Public
Accountants (AICPA) WebTrust Program for Certification Authorities or other current
industry accepted standards and practices.
2.4 Interpretation and Enforcement
2.4.1
Governing Law
The laws of the United States of America govern the enforceability, construction,
interpretation, and validity of this CPS with respect to the ACES CP and the Contract
between GSA and ORC (the ACES provider).
With respect to Subscriber or Relying Party Agreements or Obligations made by a U.S.
Government entity by purchasing the services associated with this CPS, Agreement and
interpretation will be governed by the Contracts Disputes Act of 1978 as amended
(codified at 41 U.S.C. section 601). If the individuals or organizations purchasing the
services associated with this CPS are not within the jurisdiction of the U.S. Government,
the laws of the Commonwealth of Virginia apply.
Various laws and regulations may apply, based on the jurisdiction in which a certificate
is issued or used. It is the responsibility of the certificate holder, or user, to ensure that
all applicable laws and regulations are adhered to.
106764133
24
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
2.4.2
Severability of Provisions, Survival, Merger, and Notice
All contracts or orders negotiated, for the purpose of providing ORC ACES services
under this CPS, shall contain clauses that ensure continuity and stability of the ORC
ACES operation.
Should it be determined that one section of this CPS is incorrect or invalid, the other
sections shall remain in effect until the CPS is updated. Requirements for updating this
CPS are described in Section 8. Responsibilities, requirements, and privileges of this
document are transferred to the newer edition upon release of that newer edition.
2.4.3
Dispute Resolution Procedures
In the event of any dispute or disagreement between two or more of the program
participants (“disputing parties”) arising out of or relating to ACES Contracts, CPS, or
agreements, the disputing parties shall use their best efforts to settle the dispute or
disagreement through negotiations in good faith following notice from one disputing
party to the other(s). If the disputing parties cannot reach a mutually agreeable
resolution of the dispute or disagreement within 60 days following the date of such
notice, then the disputing parties may present the dispute to the GSA ACES Contract
Officer for resolution.
Any contract dispute between ORC and GSA shall be handled under the terms and
conditions of the ACES contract. An attempt shall be made to resolve any dispute
through an independent mediator, mutually agreed to by all disputing parties. If
mediation is unsuccessful in resolving a dispute, it shall be resolved by arbitration in
accordance with applicable statutes.
2.5 Fees
All fees are set in accordance with the terms of the ORC ACES Contract. Fees are
published on the ORC ACES website or established contractually. Fees are published at
http://aces.orc.com and may change with a 7-day notice.
2.5.1
Certificate Issuance, Renewal, Suspension, and Revocation Fees
A fee per validity year, unless otherwise negotiated, is levied by ORC to issue Identity
and Encryption certificates. A fee per year, unless otherwise negotiated, is levied by
ORC to issue Server and Code Signer certificates. Likewise, a fee per each additional
year, unless otherwise negotiated, is levied by ORC to renew an ORC ACES certificate.
A fee per encryption certificate is levied for the escrowing of encryption keys.
A fee, unless otherwise negotiated, is levied by ORC for the replacement of certificates
and or tokens when the subscriber’s private key has not been compromised and there are
no changes to the certificate.
Note: Fees for tokens are separate from Certificate Issuance, Renewal, and
Replacement Fees.
106764133
25
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
2.5.2
Certificate Access Fees
ORC does not impose any certificate access fees on subscribers with respect to its own
ACES Certificate(s) or the status of such Certificate(s). No fee is levied by ORC for
access to information about any certificate issued by the ORC that is requested under a
court order. ORC assesses a fee from subscribers and Relying Parties for recovering
archived certificates.
2.5.3
Revocation or Status Information Access Fees
Fees may be assessed for certificate validation services as set forth in the Authorized
ORC-GSA ACES Contract. ORC CSA services are priced separate from certificate
issuance services, on a transaction and subscription basis.
2.5.4
Fees for Other Services Such as Policy Information
No fee is levied for online access to policy information. A reasonable fee to cover media
reproduction and distribution costs may be levied for a physical media copy of this
policy information. A consulting fee per hour is levied for certificate support required in
addition to the detailed instructions delivered with the notification of subscriber
certificate issuance. This additional support includes documentation, telephone and onsite support.
2.5.5
Refund Policy
Refunds may be negotiated on a case-by-case basis.
2.6 Publication and Repository
2.6.1
Publication of ORC ACES Information
ORC maintains a publicly accessible repository that is available to subscribers and
relying parties that contains:

A listing of all current signature and encryption certificates signed by the ORC
ACES CAs.

Current and accurate CRLs.

ORC ACES certificates for signing keys.

ORC ACES certificates for CRL signing keys.

A copy or link to the current ACES CP.

A summary of this approved CPS.

Any additional policy, waiver, or practice information that is supplemental to the
ACES CP or this CPS
The repository is located at http://aces.orc.com.
106764133
26
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
2.6.2
Frequency of Publication
Certificates are published to a repository at the time of issuance and remain accessible
from the repository following subscriber acceptance. CRL publication is in accordance
with Section 4.4.5.1. This CPS is published in accordance with Section 8.2.
2.6.3
Access Controls
There are no access controls on the reading the CPS summary, any supplemental policy
information, or any supplemental practice information published by ORC. Certificate
and CRL information are publicly available.
Access to ACES Certificates and ACES Certificate status information is in accordance
with provisions of the ORC ACES Contract. Access controls include:

Access to ORC Electronic Resources are be controlled by job requirements and
authentication, as stipulated in this CPS.

ORC employees are only able to access those resources that they require to
accomplish the tasks they are assigned, as stipulated in this CPS (access rights are
assigned by resource (server, computer, share, volume, printer, etc.)).

User authentication is via certificate authentication (or UserID and password when
appropriate) and data encryption is used, as stipulated in this CPS.

ORC employees are assigned access rights before accessing any electronic resources.

The ORC Corporate Security Auditor determines and periodically reviews user
access rights.

The CAA and SA are notified of any changes that affect employee access rights.
These policies are elaborated upon in the ORC Systems Security Plan (SSP).
2.6.4
Repositories
ORC maintains a master directory accessible through an LDAP interface. This directory
is protected by a firewall and is accessible through the Internet. Information in ACES
repositories is protected in accordance with the Privacy Act of 1974 as set forth in
ORC’s Privacy Policy and Procedures documents. See Section 2.8.1.1.
Updating the repository is restricted only to authorized individuals using certificate
authenticated access control over SSL. The directory is configured by the CAA to
recognize ORC IAs and CAAs as authorized to make changes. ORC protects any and all
repository information not intended for public dissemination or modification.
The directory is located at:
ldap://aces-ds.orc.com.
The CRLs are located at:
106764133
27
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
ldap://aces-ds.orc.com/ cn=ORC ACES <CA Name>, o=ORC PKI,
c=US?certificaterevocationlist;binary
The CA signing certificates are located at:
ldap://aces-ds.orc.com/ cn=ORC ACES <CA Name>, o= ORC PKI,
c=US
The ORC ACES Root Certificate is located at:
ldap://aces-ds.orc.com/ cn=ORC Government Root CA, o=ORC PKI ,
c=US
The HTTP Gateway is located at:
https:// aces-ds.orc.com /dsgw/bin/csearch?context=dsgw
2.7 Inspections And Reviews
The ORC ACES system, including all of its CMA and repository roles underwent an
ACES Security Certification and Accreditation (C&A) as a condition of obtaining and
retaining approval to operate as an “Authorized CA” in accordance with the ACES CP
and the GSA ACES Contract. The purpose of the C&A process is to verify that the CA
has in place and follows a system that assures that the quality of its “Authorized CA”
Services; and conforms to the requirements of the ACES CP, the GSA ACES Contract
and this CPS.
2.7.1
Certification and Accreditation
ORC (including all of its RA, CMA, and Repository subcontractor(s), if applicable),
undergo ACES Security C&A as a condition of obtaining and retaining approval to
operate as an “Authorized CA” as stipulated in the ACES CP and GSA ACES Contract
and in accordance with Federal regulations and GSA policy and supporting security
guidelines. See Appendix D.
Management authorization is based on an assessment of management, operational, and
technical controls. Since the SSP establishes the security controls, it forms the basis for
the accreditation, supplemented by more specific studies as needed. In addition, periodic
review of controls contributes to future accreditations.
Depending upon the risk and magnitude of harm that could result, weaknesses identified
during the review of security controls are reported by the GSA ACES Program Manager
as deficiencies in accordance with OMB Circular A-123, Management Accountability
and Control, and the Federal Managers' Financial Integrity Act.
Re-authorization occurs prior to a significant change in processing, but at least every
three years, as required by the GSA ACES Program Manager. It may be done more often
where there is a high risk and potential magnitude of harm.
106764133
28
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
2.7.1.1
Frequency of Certification Authority Compliance Review
ORC has undergone a C&A from GSA prior to initial approval as an ACES “Authorized
CA”. ORC acknowledges the Government’s right to require periodic and a-periodic
inspections and audits of the ACES system within its domain to validate the CA is
operating in accordance with the security practices and procedures set forth in this CPS
as stipulated in the ACES CP and the GSA ACES Program Manager.
ORC shall submit to a technical evaluation by the Government and support a
Government evaluation of the system. Audit results shall be provided to the Government
for review. If ORC fails to demonstrate the proper implementation of the PKI,
documentation shall be provided to the Government indicating areas that are deficient.
A second audit shall be performed to demonstrate the PKI has been properly
implemented.
2.7.1.2
Identity/ Qualifications of Reviewer
The C&A process shall be conducted by an independent security audit firm acceptable to
GSA that is qualified to perform a security audit on a CA.
ORC contracts to an auditing firm to perform an independent audit. This audit team, in
total, meets or exceeds the following qualifications:

More than three years experience performing security audits

More than one year PKI engineering experience

More than three years cryptography engineering experience

More than three years of computer security experience
GSA or ORC engage the services of an auditor that is competent in the field of security
compliance audits of Information Technology systems and is thoroughly familiar with
the CPS. In all cases, the selected auditor will have experience in information security,
cryptography and PKI.
2.7.1.3
Auditor's Relationship to Audited Party
The auditor identified above is an independent entity and may have a contractual
relationship with ORC for performance of the audit. ORC also performs internal audits
of CMA facilities, conducted by a Corporate Security Auditor, as defined herein.
2.7.1.4
Communication of Results
Results of the C&A review are made available to GSA, to be used in determining the
CA’s suitability for continued performance as an Authorized CA.
106764133
29
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
2.7.2
2.7.2.1
Quality Assurance Inspection and Review
Topics Covered by Quality Assurance Inspection and Review
All aspects of CA operation as specified in this CPS are subject to Quality Assurance
compliance inspections and reviews. The quality assurance inspection shall be
conducted in concert with the C&A (Section 2.7.1) and pursuant to the guidance
provided in the American Institute of Certified Public Accountants (AICPA) WebTrust
Program for Certification Authorities or other current industry accepted standards and
practices, as described herein.
2.7.2.2
Identity/Qualifications of Reviewer
Stipulated in Section 2.7.1.2.
2.7.2.3
Auditor's Relationship to Audited Party
Stipulated in Section 2.7.1.3.
2.7.2.4
Audit Compliance Report
Stipulated in Section 2.7.1.4.
2.7.2.5
Actions Taken as a Result of Deficiency
GSA will address any identified deficiencies with ORC. Any discrepancies between the
actual operation and the stipulations of this CPS and the ACES CP shall be noted. The
Government shall be immediately notified of all discrepancies. A remedy will be
determined, including a reasonable time for completion.
Any remedy may include permanent or temporary CA cessation or termination of CA
accreditation, but several factors must be considered in this decision, including the
severity of the discrepancy and the risks it imposes, and the disruption to the certificate
using community.
Remedies shall be defined and communicated to ORC as soon as possible to limit the
risks created. The implementation of remedies shall be communicated to the appropriate
authority. A special audit may be required to confirm the implementation and
effectiveness of the remedy.
2.7.2.6
Communication of Results
Results of the QA compliance inspection and review are made available to GSA, to be
used in determining the CA’s suitability for continued performance as an “Authorized
CA”.
The auditor shall communicate the results of any inspection or audit, in whole, to ORC
and to the Government. Complete audit information shall be posted on the ORC ACES
PKI website in an access-controlled area. This website operates using the Secure
Sockets Layer (SSL) protocol. If found not to be in compliance with this CPS, or the
106764133
30
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
policy identified in Section 1.2, ORC shall be notified immediately upon completion of
the audit. Required remedies shall be defined and communicated to ORC as soon as
possible to limit the risks created. The implementation of remedies shall be
communicated to the appropriate authority. A special audit may be required to confirm
the implementation and effectiveness of the remedy.
ORC shall post a compliance audit summary outlining key results on the ORC ACES
PKI website in a publicly accessible area to allow inspection by the interested persons.
This website operate using the SSL protocol to protect against alteration of result
information.
2.8 Confidentiality
As an ACES “Authorized CA”, ORC maintains an ACES system of records under
established administrative, technical, and physical safeguards to ensure the security and
confidentiality of records and to protect against any anticipated threats or hazards to their
security or integrity which could result in substantial harm, embarrassment,
inconvenience, or unfairness to any individual on whom information is maintained IAW
Title 5, U.S.C., Sec. 552a.
2.8.1
2.8.1.1
Types of Information to Be Kept Confidential
Privacy Policy and Procedures
As an ACES “Authorized CA”, ORC maintains an ACES system of records on behalf of
the Government under a written Privacy Policies and Procedures (PPP) designed to
ensure compliance with the requirements of 5 U.S.C. 552a, Appendix I to OMB Circular
A-130, and the ACES Contract. These policies and procedures are incorporated into this
CPS.
2.8.1.2
Subscriber Information
The ORC ACES system protects the confidentiality of personal information regarding
subscribers that is collected during the applicant registration, ACES Certificate
application, authentication, and certificate status checking processes in accordance with
the Privacy Act of 1974, and Appendix III to Office of Management and Budget (OMB)
Circular A-130. The procedures followed by ORC for Privacy Act requirements, and all
other aspects of CA administration, are contained in Appendix B. Such information
shall be used only for the purpose of providing Authorized CA Services and carrying out
the provisions of the ACES CP, the GSA ACES Contract and this CPS. This
information shall not be disclosed in any manner to any person without the prior consent
of the subscriber, unless otherwise required by law, except as may be necessary for the
performance of the Authorized CA services in accordance with the ACES Contract. In
addition, personal information submitted by subscribers:
106764133

Must be made available by ORC to the subscriber involved following an appropriate
request by such subscriber

Must be subject to correction and/or revision by such subscriber
31
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Must be protected by ORC in a manner designed to ensure the data’s integrity

Cannot be used or disclosed by ORC for purposes other than the direct operational
support of ACES unless such use is authorized by the subscriber involved
Under no circumstances does ORC (or any authorized IA, RA, CMA, or Repository)
have access to the private keys of any subscriber to whom it issues an ACES Certificate,
with the exception of escrowed private encryption keys.
2.8.1.3
GSA and Other Government Information
ORC takes reasonable steps to protect the confidentiality of any GSA, Qualified Relying
Party, or other Government information provided to the Authorized CA. Such
information is used only for the purpose of providing ACES Services and carrying out
the provisions of the ACES CP, the GSA ACES Contract and this CPS. This
information is not disclosed in any manner to any person except as may be necessary for
the performance of the ACES Services in accordance with the GSA ACES contract.
2.8.2
Types of Information Not Considered Confidential
Information contained on a single ACES Certificate or related status information is not
considered confidential, when the information is used in accordance with the purposes of
providing ORC ACES Services and carrying out the provisions of this CPS and the GSA
ACES contract and in accordance with the Privacy Act of 1974, and Appendix III to
Office of Management and Budget (OMB) Circular A-130. However, a compilation of
such information is treated as confidential. Information not considered includes the
subscriber’s name, e-mail address, certificate public key, and certificate validity period.
2.8.3
Disclosure of Certificate Revocation/Suspension Information
When applicable, the CRL for the CA is updated in accordance with Section 4.4.5.1.
This information shall be available in the CA repository. Information concerning the
revocation of a certificate or events leading to such a revocation should be limited to the
individuals involved.
2.8.4
Release to Law Enforcement Officials
Sensitive data shall be released to law enforcement officials only under a proper court
order. ORC does not disclose certificate or certificate-related information to any third
party unless expressly authorized by the ACES Program Manager, required by criminal
law, government rule or regulation, or order of a criminal court with jurisdiction. ORC
authenticates such requests prior to disclosure. External requests must be made via the
subscriber’s organization, unless under court order.
2.8.5
Release as Part of Civil Discover
Sensitive information shall be released to civil authorities only under a proper subpoena.
106764133
32
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
2.8.6
Disclosure upon Owner's Request
Subscriber’s information shall be made available to an identified party, upon the request
of that subscriber, for any purpose related to the issue of the subscriber’s certificate. See
also Section 2.8.1.
2.9 Security Requirements
The ACES Program and all GSA Federal employees and authorized users of IT including
contractors, consultants, or other third parties who are specifically granted access to the
ACES Program shall comply with GSA Order CIO 2100.1A. At a minimum ORC met
the following security controls prior to being approved as an ACES “Authorized CA”:

Technical and/or security evaluation complete

Risk assessment conducted

Rules of behavior established and process to be signed by users

Contingency Plan developed and tested

Security Plan developed, updated, and reviewed

System evaluated meeting all applicable Federal laws, regulations, policies,
guidelines, and standards

In-place and planned security safeguards adequate and appropriate for the system,
i.e., the level of controls are consistent with the level of sensitivity of the system
ORC does not publish or disclose in any manner, without the GSA Administrative
Contracting Officer’s (ACO) written consent, the details of any safeguards either
designed or developed by ORC under the ACES Contract or otherwise provided by the
Government.
2.9.1
System Security Plan (SSP)
ORC maintains an SSP in accordance with requirements set forth in OMB Circular A130, NIST 800-18, GSA Order 2100.1A and all supporting GSA security guidelines, as
well as the ACES Contract.
2.9.2
Risk Management
ORC conducts periodic risk assessments and maintains the ORC ACES system at the
level of residual risk accepted by the designated approving authority in accordance with
OMB Circular A-130, NIST 800-18, GSA Order 2100.1A and all supporting GSA
security guidelines, and the ACES Contract. The ORC risk assessment is included in the
ORC SSP.
2.9.3
Certification and Accreditation
Certification and Accreditation of the ORC ACES system has been performed and is
maintained in accordance with requirements set forth in OMB Circular A-130, NIST
106764133
33
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
800-18, GSA Order 2100.1A and all supporting GSA security guidelines, and the ACES
Contract.
2.9.4
Rules and Behavior
The ACES SSP includes the rules of conduct that is used to instruct ORC’s officers and
employees in compliance requirements and penalties for noncompliance. The rules of
behavior have been developed and are implemented in accordance with requirements set
forth in OMB Circular A-130, NIST 800-18, GSA Order 2100.1A and all supporting
GSA security guidelines, and the ACES Contract.
2.9.5
Contingency Plan
The ORC SSP includes a contingency plan under which ORC has implemented and
periodically tests the ACES system in accordance with guidelines provided in OMB
Circular A-130, NIST 800-18, FIPS PUB 87, and GSA Order 2100.1A and all supporting
GSA security guidelines. The contingency plan is maintained in accordance with the
requirements of the SSP.
2.9.6
Incident Response Capability
ORC ensures that there is a capability to provide help to users when a security incident
occurs in the system and to share information concerning common vulnerabilities and
threats. A security incident is defined to be any adverse event that threatens the security
of information resources. Adverse events include compromises of integrity, denial of
service, compromises of confidentiality, loss of accountability, or damage to any part of
the system.
Incident response procedures and reporting of security incidents are in accordance with
guidelines provided in OMB Circular A-130, NIST 800-18, GSA Order 2100.1A and all
supporting GSA security guidelines, and the ACES contract.
2.10 Intellectual Property Rights
“Access Certificates for Electronic Services,” “ACES”, and the ACES OIDs are the
property of GSA, which is used only by ORC in accordance with the provisions of this
CPS and the ORC-GSA ACES Contract. Any other use of the above without the express
written permission of GSA is expressly prohibited.
Distinguished names are the property of the individuals named or their employer. Unless
otherwise agreed, property interests in the following security-related information
materials and data are regarded as the property of the parties indicated below:

106764133
Certificates and CRLs issued under this CPS are the personal property of
Operational Research Consultants, Inc. Permission is granted to reproduce and
distribute certificates issued by ORC on a non-exclusive, royalty-free basis, provided
that they are reproduced and distributed in full. Certificates and CRLs shall not be
published in any publicly accessible repository or directory without the express
written permission of ORC
34
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
106764133

This CPS is the sole property of Operational Research Consultants, Inc.

Private keys are the personal property of the subscribers who rightfully use or are
capable of using them (or their employer or principal), regardless of the physical
medium within which they are stored and protected

Public keys are the personal property of subscribers (or their employer or principal),
regardless of the physical medium within which they are stored and protected

ORC public keys, including ORC CA public keys, are the property of Operational
Research Consultants, Inc. ORC licenses relying parties to use such keys only in
conjunction with FIPS 140-1/2 validated encryption modules
35
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
3
Identification And Authentication
3.1 Initial Registration
This section contains the practices to be followed in identifying and authenticating
individuals involved in the certification request process.
3.1.1
Types of Names
All certificates issued by the ORC under this CPS use the Distinguished Name (DN)
format for subject and issuer name fields.
DNs consist of a combination of a Common Name (CN) and a Relative Distinguished
Name (RDN). CNs are either full names for individuals, Uniform Resource Locators
(URLs) or Internet Protocol (IP) addresses for servers or name of the code signer’s
organization for code signing certificates and include a unique ten-digit number preceded
by “ORC” (unique identification string) and assigned sequentially by ORC. The unique
identification string is followed by:
.ID, for Identity Certificates
.encrypt, for Encryption Certificates
The unique identifier is the same for all certificates (digital signature/non-repudiation
and key encipherment) issued to a single subscriber. For code signing certificates, the
unique identification number can be assigned by the requesting organization.
The ORC Authorized CA CNs are:
cn=ORC ACES Unaffiliated CA
cn=ORC ACES Business CA
cn=ORC ACES FICC CA (for federal, state, and local Government)
The RDN for ORC Authorized ACES CA Certificates is:
o=ORC PKI, c=US
Since the DN is ‘DN = CN, RDN ’, the ORC Authorized CA DNs are ‘cn=ORC ACES
<CA name>, o=ORC PKI, c=US ’.
The RDN for Unaffiliated Subscriber Certificates is:
106764133
36
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
ou=<State of Residence or citizenship2>, c=US
The RDN for Business Representative certificates is:
ou=<Location or Department Name>, ou=<State of Residence or
citizenship3>, o==<Organizations Name> c=US, where ou=<Location
or Department Name> is optional
The RDN for Federal Government entity certificates is:
ou=<Agency Name>, ou=<department>, o=U.S. Government, c=US
The RDN for State and Local Government entity certificates is:
ou=<Agency Name>, o==<State Name>, c=US, where ou=<Agency
Name> is optional
Note: Additional ‘ou’ fields may be added to any RDN to support organizational
needs.
3.1.1.1
ACES Unaffiliated Individual Digital Signature and Encryption
Certificates
The subject name used for ORC ACES Unaffiliated Individual Digital Signature and
Encryption Certificates applicants is the subscriber’s authenticated common name and
optional Subject Alternative Name marked non-critical, where:
Digital Signature Certificates CN = Smith.John.J.ORC0000000001.id
Encryption Certificates CN = Smith.John.J.ORC0000000001.encrypt
3.1.1.2
ACES Business Representative Digital Signature and Encryption
Certificates
ORC ACES Business Representative Digital Signature and Encryption certificates shall
X.500 Distinguished Name, and optional Subject Alternative Name. Subject Alternative
Names are marked non-critical. DNs are assigned by ORC, in accordance with a naming
authority, where:
Digital Signature Certificates CN = Smith.John.J.ORC0000000001.id
Encryption Certificates CN = Smith.John.J.ORC0000000001.encrypt
106764133
2
State of Residence is used for U.S. Citizens and Citizenship for non-U.S. citizens.
3
State of Residence is used for U.S. Citizens and Citizenship for non-U.S. citizens.
37
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
ACES Business Representative Digital Signature Certificates assert an alternate name
form subject to requirements set forth in Section 3.1.2.2, below intended to ensure name
uniqueness.
3.1.1.3
ACES Agency (Relying Party Applications) Digital Signature and
Encryption Certificates
ORC ACES Agency (Relying Party Applications) Digital Signature and Encryption
certificates assert X.500 Distinguished Name, and optional Subject Alternative Name
marked non-critical. ORC ACES Agency (Relying Party Applications) Digital Signature
and Encryption certificates contain an X.500 DN that contains domain component
elements assigned by ORC, in accordance with the agency’s naming scheme under
government-wide policy, where:
CN = Host URL, Name or IP Address of the ACES Relying Party Application Digital
Signature and Encryption Certificates assert an alternate name form subject to
requirements, as set forth in Section 3.1.2.3, below, intended to ensure name uniqueness.
3.1.1.4
Agency Applications SSL Server Certificates
ORC Agency Applications SSL Server certificates assert the X.500 Distinguished Name
of the server including the identification of the organization and organizational unit
sponsoring the server, where:
CN = <fully qualified domain name of the server>
3.1.1.5
ACES Federal Employee Digital Signature and Encryption Certificates
ORC ACES Federal Employee Digital Signature and Encryption certificates assert an
X.500 Distinguished Name, and optional Subject Alternative Name marked non-critical.
DNs are assigned by ORC, in accordance with a naming authority, where:
Digital Signature Certificates CN = Smith.John.J.ORC0000000001.id
Encryption Certificates CN = Smith.John.J.ORC0000000001.encrypt
Every ACES Federal Employee subscriber certificate contain an Organization field
wherein O=U.S. Government and an Organizational Unit field wherein OU=agency
name as stipulated by the agency. ACES Federal Employee Digital Signature
Certificates assert an alternate name form subject to requirements, as set forth in Section
3.1.2.6, below, intended to ensure name uniqueness.
3.1.1.6
ACES State and Local Government Employee Digital Signature and
Encryption Certificates
ORC ACES State and Local Government Employee Digital Signature and Encryption
certificates assert an X.500 Distinguished Name, and optional Subject Alternative Name
marked non-critical. DNs are assigned by ORC, in accordance with a naming authority,
where:
106764133
38
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Digital Signature Certificates CN = Smith.John.J.ORC0000000001.id
Encryption Certificates CN = Smith.John.J.ORC0000000001.encrypt
Every ACES State and Local Government Employee subscriber certificate contain an
Organization field wherein O=State and an Organizational Unit fields wherein
OU=agency name, as stipulated by the agency. ACES State and Local Government
Employee Digital Signature Certificates assert an alternate name form subject to
requirements, as set forth in Section 3.1.2.7, below, intended to ensure name uniqueness.
3.1.2
Need for Names to be Meaningful
Common Names are meaningful as individual names, as actual server Uniform Resource
Locators (URLs) or Internet Protocol (IP) addresses or as code signing organizational
names. Names identify the person or object to which they are assigned. ORC ensures
that an affiliation exists between the subscriber and any organization that is identified by
any component of any name in its certificate.
The common name used represents the subscriber in a way that is easily understandable
for humans. For people, this is typically a legal name. For equipment, this may be a
model name and serial number, or an application process (e.g., Organization X Mail List
or Organization Y Multifunction Interpreter).
ORC CAs asserting this policy only sign certificates with subject names from within a
name-space approved by the GSA ACES Program Manager.
3.1.2.1
ACES Unaffiliated Individual Digital Signature and Encryption
Certificates
In the case of ORC ACES Unaffiliated Individuals, the authenticated common name
should be a combination of first name and/or initials and surname:
cn= surname.firstName.initial.(unique identification string).(certificate type)
3.1.2.2
ACES Business Representative Digital Signature and Encryption
Certificates
In the case of ORC ACES Business Representatives, the authenticated common name
should be the combination of first name and/or initials and surname:
cn= surname.firstName.initial.(unique identification string).(certificate type)
The legal name of the organization and/or unit is reflected in the RDN.
3.1.2.3
ACES Agency (Relying Party Applications) Digital Signature and
Encryption Certificates
In the case of Relying Parties, the common name should be the authenticated name of the
Relying Party application:
106764133
39
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
cn= (unique applicationname).(unique identification string)
3.1.2.4
ACES Authorized CA Digital Signature Certificates
ORC implements the name constraint extension of the X.509 version 3 certificate profile
in issuing cross certificates, in accordance with the FBCA:
cn=ORC Government Root CA, o=ORC PKI, c=US
3.1.2.5
Agency Applications SSL Server Certificates
In the case of Agency Application Servers, the common name should be the
authenticated registered domain name of the server Agency Application:
cn=<fully qualified domain name of the server>
3.1.2.6
ACES Federal Employee Digital Signature and Encryption Certificates
In the case of Federal Employees, the authenticated common name should be the
combination of first name and/or initials and surname:
cn= surname.firstName.initial.(unique identification string).(certificate type)
The Agency legal name of the organization and/or unit is reflected in the RDN.
3.1.2.7
ACES State Employee Digital Signature and Encryption Certificates
ORC ACES State Employee Digital Signature and Encryption Certificates authenticated
common name is based on the combination of first name and/or initials and surname:
cn= surname.firstName.initial.(unique identification string).(certificate type)
The Agency legal name of the organization and/or unit is reflected in the RDN.
3.1.3
Rules for Interpreting Various Name Forms
Rules for interpreting name forms are contained in the applicable certificate profile (see
Section 7.1.4), and are established by the GSA/FTS Center for Information Security.
The ACES Program Management Office is responsible for Agency CA name space
control.
3.1.4
Uniqueness of Names
ORC complies with uniqueness of names; including X.500 DNs. ORC enforces name
uniqueness, as described in Sections 3.1.1 and 3.1.2.
ORC ensures the following for subscriber names:

106764133
The name contains the subscriber identity and organization affiliation (if applicable)
that is meaningful to humans
40
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

The naming convention is described in this CPS (Section 3.1.1)

ORC complies with the Policy Authority for the naming convention
This does not prevent devices from sharing a Fully Qualified Domain Name (FQDN) as
CN.
3.1.5
Name Claim Dispute Procedure
ORC investigates and corrects, as necessary, any name collisions brought to our
attention. If appropriate, ORC shall coordinate with and/or defer to the GSA/FTS Center
for Information Security and/or the GSA ACES Policy Authority.
3.1.6
Recognition, Authentication and Role of Trademarks
A corporate entity is not guaranteed that its common name will contain a trademark if
requested. ORC will not issue that name to the rightful owner if it has already issued one
sufficient for identification. See Section 2.2.6.
In general, use of trademarks in a name form or as any part of a name form is
discouraged. Trademarks shall not be used as a name form or as a part of the name form
for certificates issued to government employees unless U.S. Government personnel hold
them or devices have a legitimate right to their use. The holder of the trademark shall
only use trademarks in certificates issued to contractors, contractor-owned servers,
foreign nationals, or organizations with specific permission.
3.1.7
Verification of Possession of Private Key
In all cases where the subscriber generates key pairs, the subscriber is required to prove,
to an ORC ACES CA, possession of the private key that corresponds to the public key in
the certificate request. Subscriber are required to use a FIPS 140-1/2 validated
cryptographic module for generation of keys. In the case of a Level 1 cryptographic
module, the ORC ACES CAs perform a browser check prior to registration to ensure
compliance against a list of FIPS 140-1/2 Level 1 browsers and upon submitting a
registration request. ORC ACES CAs only allows compliant key generation. In the case
of Level 2 tokens, required for medium hardware assurance certificates, key generation is
accomplished with a Level 2-compliant token in the presence of an ORC RA or LRA, or
other specifically assigned authority.
The subscriber is in possession and control of the private key from time of generation or
benign transfer. The ORC ACES CAs authenticate the subscriber with a proof of
possession (POP) test when requesting and retrieving a certificate by requiring the
subscriber to perform a private key operation and verifying that the public key presented
by the subscriber matches the private key. ORC supports multiple enrollment protocols
which support POP including: KEYGEN/SPAC, CRMF/CMMF, PKCS #10 and CMC.
To effect POP the CA supplies a random challenge string to the browser as part of the
KEYGEN tag. The public key generated by the browser and the challenge string
supplied by the CA are DER (Distinguished Encoding Rules) encoded together, and the
resulting PublicKeyAndChallenge value is then digitally signed with the private key to
106764133
41
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
produce a SignedPublicKeyAndChallenge value. This signed value is then base 64
encoded and sent to the CA as part of the certificate request; the CA verifies the
signature using the included public key, thus proving possession by the browser of the
private key corresponding to that public key.
The public key and challenge strings are DER encoded as PublicKeyAndChallenge and
then digitally signed with the private key to produce a SignedPublicKeyAndChallenge.
The SignedPublicKeyAndChallenge is base64 encoded, and the ASCII data is finally
submitted to the server as the value of a name-value pair, where the name is specified by
the NAME attribute of the KEYGEN tag. When retrieving the completed certificate the
browser also checks before importing the certificate into its database, to verify that the
public key in the certificate being installed matches the private key it originally
generated.
An additional out-of-band check is preformed by requiring the requestor to print the base
64 of the DER encoded certificate request and present it in person during the validation
process. The RA validates both the person’s identity and their possession of a certificate
request corresponding to their private key.
In all cases, IAs may request additional information or verification from an RA or LRA
if deemed necessary by the IA to confirm the requestor’s identity.
3.1.7.1
Hardware Tokens
When hardware tokens are used for private key storage, the ORC maintains a record of
validation for receipt of the token by the subject.
3.1.7.2
Use of Shared Secrets
ORC does not use shared secrets.
3.1.8
Authentication of Sponsoring Organizational Identity
If the applicant is requesting a Business Representative, Federal Employee or State
Employee ACES Certificate, in addition to verifying the applicant’s authorization to
represent the Sponsoring Organization, ORC verifies the Sponsoring Organization's
current operating status and that said organization conducts business at the address listed
in the ACES Certificate application. ORC provides validation of information concerning
the Sponsoring Organization, such as legal company name, type of entity, year of
formation, names of directors and officers, address (number and street, city, ZIP code),
and telephone number. All applicants are notified, on the website application process,
that the process is secure.
Users shall provide proof of their relationship to the company/organization they work
for. This proof can be accomplished by:
106764133

Applicant requesting a certificate accompanied by a U.S. Government sponsor

Applicant presenting a government-issued photo ID badge including the applicants
company affiliation
42
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Applicant providing a signed letter on company letterhead from an authorized
organization official attesting to the relationship (this is the only method approved
for server certificate requests and code signing certificate requests)

Applicant presenting an un-expired photo ID badge issued by the organization
3.1.9
Authentication of Individual Identity
Verification of an applicant’s identity shall be performed prior to certificate issuance.
All applicants for medium assurance certificates are required to appear in person before
an RA, an LRA, or Notary Public (or a person legally empowered to witness and certify
the validity of documents and to take affidavits and depositions) for identity
authentication. All applicants for medium hardware assurance certificates are required
to appear in person before an RA or LRA. Applicants for medium assurance and
medium hardware assurance certificates are required to present official photo credentials
along with other application information, identified below, and the applicant form
generated during the certificate request process containing the public key.
Minors and others not competent to perform face-to-face registration alone are not
supported under this CPS.
When the applicant’s identity is validated by a Notary Public (or a person legally
empowered to witness and certify the validity of documents and to take affidavits and
depositions), the applicant shall submit the notarized statement of identity along with
copies of other information used to verify the applicant’s identity directly to an ORC RA,
as prescribed in the subscriber agreement. Applicants must fill out and sign a form
acknowledging understanding and acceptance of the responsibilities associated with
accepting a certificate. The Subscriber Agreement may also serve as a testimonial to the
accuracy of the information provided in the certificate request.
The RA shall archive a copy of all information used in the verification process. In all
cases, the RA shall submit a digitally signed e-mail message to an ORC IA, including the
public key, attesting that the identity of the individual has been authenticated.
In all cases, ORC records the following information:
106764133

The Identity of the person performing the validation process

Applicant’s name as it appears in the certificate Common Name field

A signed declaration by the identity-verifying agent that they verified the identity of
the applicant

Method of application (i.e., online, in-person)

The method used to authenticate the applicant’s identity, including identification
type and unique number or alphanumeric identifier on the ID

The date of verification

A handwritten signature by the applicant in the presence of the person performing
the identity verification
43
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

For each data element accepted for proofing, including electronic forms:
o
Name of document presented for identity proofing
o
Issuing authority
o
Date of issuance
o
Date of expiration
o
All fields verified
o
Source of verification (i.e., which databases used for cross-checks)
o
Method of verification (i.e., online, in-person)
o
Date/time of verification

The ORC ACES name, including subcontractors, if any

All associated error messages and codes

Date/time of process completion

Names (IDs) of ORC PKI processes, including subcontractors’ processes, if any.
Alternately, certificate requests may be validated and authenticated on the basis of
electronically authenticated subscriber requests using a current, valid PKI signature
certificate issued by an ORC ACES CA and associated private key. The following
restrictions apply:

The assurance level of the new certificate shall be the same or lower than the
certificate used as the authentication credential.

The DN of the new certificate shall be identical to the DN of the certificate used as
the authentication credential.

Information in the new certificate that could be used for authorization shall be
identical to that of the certificate used as the authentication credential.

The expiration date of the new certificate shall be no later than the next required inperson authentication date associated with the certificate used as the authentication
credential.

The validity period of the new certificate shall not be greater than the maximum
validity period requirements of the ACES CP for that particular type of certificate.

The in-person authentication date associated with the new certificate shall be no later
than the in-person authentication date associated with the certificate used for
authentication.
In all cases, ORC may request additional information or verification if deemed necessary
to confirm the requestor’s identity.
106764133
44
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
3.1.9.1
Authentication of Unaffiliated Individual ACES Digital Signature and
Encryption Certificates
Unaffiliated Individuals are required to appear in person before an ORC RA, an LRA, or
a Notary Public (or a person legally empowered to witness and certify the validity of
documents and to take affidavits and depositions) for identity authentication. ORC
verifies all of the following identification information supplied by the applicant: first
name, middle initial, and last name, date of birth, current address (number and street,
city, ZIP code), and telephone number.
An exception to the above is provided to the Government when the Government provides
identity proofing. Any exception is the subject of an approved Registration Practice
Statement.
3.1.9.2
Authentication of ACES Business Representative Digital Signature and
Encryption Certificates
Verification of an applicant’s identity for an ACES Business Representative Digital
Signature or Encryption Certificate shall be performed prior to certificate issuance.
Applicants are required to appear in person before an RA, an LRA, or a Notary Public
(or a person legally empowered to witness and certify the validity of documents and to
take affidavits and depositions) for identity authentication.
The ORC ACES RA, LRA or Trusted Agent shall verify:

That the applicant is a duly authorized representative of the Sponsoring Organization
as an employee, partner, member, agent, or other association.

The Sponsoring Organization’s identity as specified in Section 3.1.8.
The process documentation and authentication requirements shall include the following:

Identity of the person performing the identification

A signed declaration by that person that he or she verified the identity of the
subscriber as required by the applicable certificate policy which may be met by
establishing how the applicant is known to the verifier as required by this certificate
policy

A unique identifying number from the ID of the verifier and from the ID of the
applicant

The date and time of the verification

A declaration of identity signed by the applicant, using a handwritten signature,
performed in the presence of the person performing the identity authentication.
3.1.9.3
Authentication of ACES Agency (Relying Party Applications) Digital
Signature and Encryption Certificates
If the applicant is requesting an ORC ACES Agency (Relying Party Applications)
Digital Signature or Encryption Certificate, ORC verifies:
106764133
45
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

that the applicant is authorized to act on behalf of the Relying Party

the affiliation of the ACES Certificate applicant with the Relying Party

that the applicant’s organization has completed a Relying Party Agreement with
GSA
3.1.9.4
Authentication of Component Identity Certificates (e.g. Agency
Application SSL Server Certificates)
Some computing and communications components (web servers, routers, firewalls, etc.)
may be named as certificate subjects. In such cases, the component must have a human
PKI Sponsor as described in Section 5.2.1. The PKI Sponsor is responsible for providing
the ORC ACES approved IA’s, through an application form, correct information
regarding:

Equipment identification

Equipment public keys

Equipment authorizations and attributes (if any are to be included in the certificate)

Contact information to enable the ORC to communicate with the PKI sponsor when
required
An ORC ACES IA shall authenticate the validity of any authorizations to be asserted in
the certificate, and shall verify source and integrity of the data collected to an assurance
level commensurate with the certificate level being requested. Authentication and
integrity checking is accomplished by one of the following methods:

Verification of digitally signed messages sent from PKI sponsors (using certificates
of equivalent or greater assurance than that being requested).

In person registration by the PKI Sponsor, with the identity of the PKI Sponsor
confirmed in accordance with the requirements of Section 3.1.9.
3.1.9.5
Authentication of ACES Federal Employee Digital Signature and
Encryption Certificates
For ACES Federal Employee Digital Signature and Encryption Certificates, identity shall
be established in-person. Information provided is checked to ensure its legitimacy.
Federal Government-issued Photo I.D Credentials are required. The Federal Employee’s
identity must be personally verified prior to the certificate being issued. The applicant
shall appear personally before either:

An ORC authorized RA or LRA

A Trusted Agent approved by the ORC or appointed in writing by name by ORC

A person certified by a State or Federal Government as being authorized to confirm
identities (such as Notaries Public), that use a stamp, seal, or other mechanism to
authenticate their identity confirmation
The ORC ACES RA, LRA or trusted agent shall verify:
106764133
46
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

That the applicant is a duly authorized representative of the Sponsoring Organization
as an employee, partner, member, agent, or other association.

The Sponsoring Organization’s identity as specified in Section 3.1.8.
The process documentation and authentication requirements shall include the following:

Identity of the person performing the identification

A signed declaration by that person that he or she verified the identity of the
subscriber as required by the applicable certificate policy which may be met by
establishing how the applicant is known to the verifier as required by this certificate
policy

A unique identifying number from the ID of the verifier and from the ID of the
applicant

The date and time of the verification

A declaration of identity signed by the applicant using a handwritten signature. This
shall be performed in the presence of the person performing the identity
authentication
The applicant shall personally appear before one of the required identity verifiers at any
time prior to application of an ORC ACES CA’s signature to the applicant’s certificate.
Alternatively, when private keys are delivered to subscribers via hardware tokens, the
subscribers shall personally appear before the ORC ACES RA, LRA or Trusted Agent to
obtain their tokens or token activation data.
3.1.9.6
Qualified Relying Party ACES Certificates
If the applicant is requesting a Qualified Relying Party ACES Certificate, ORC verifies:

That the applicant is authorized to act on behalf of the Qualified Relying Party.

The affiliation of the ACES Certificate applicant with the Qualified Relying Party,
GSA, or Agency Application.
3.1.10 Code Signer Authentication
Code signing certificates are issued to individuals on behalf of the CSAA sponsoring
organization. Each sponsoring organization is required to send a signed letter on
organizational/agency letterhead to ORC authorizing CSAA(s). The CAA maintains a
log of these letters, which is available to all RAs for verification purposes. The CSAA is
required to send a signed memorandum on organizational/agency letterhead to the RA
authorizing the code signer to receive a code-signing certificate. The memorandum
could be either a hard copy with ink signature or an electronic copy that is digitally
signed. The memorandum specifies, at a minimum, the subject DN to be asserted
including the office symbol and an optional number (in order to make the code signing
certificate’s subject DN unique). The memorandum also contains the DN of the person
authorized as the code signer. If digitally signed, the public key certificate used to verify
the digital signature shall be an ORC medium hardware assurance certificate.
106764133
47
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
After generating a key-pair and submitting a certificate request to an ORC ACES CA, the
Code Signer is required to send a digitally signed e-mail to the RA. The e-mail will
contain the following information:

Request number

Subject DN in the certificate request

DN of the code signer as it appears in the subject alternate name field
The e-mail shall be digitally signed using an approved ORC medium hardware assurance
certificate. If the person authorized to become a code signer does not possess the
required certificate, the person obtains the credential using the process defined in this
CPS, prior to making the code signer request.
The RA performs the following steps:

Verify that it has received a signed memorandum from the valid attribute authority
(i.e., the attribute authority identified in this CPS) for the code signer. This
verification includes the verification of digital signature if it received an electronic
copy of the memorandum

Verify the digital signature on the e-mail from the code signer. Verify that the e-mail
was signed using the acceptable PKI credentials. Verify that the subject alternate
name DN in the e-mail is same as the DN of the e-mail signer
In all cases, the public key certificate used to verify the digital signature shall be an ORC
medium hardware assurance certificate.
3.1.11 Authentication of Component Identities
Some computing and communications components (web servers, routers, firewalls, etc.)
may be named as certificate subjects. In such cases, the component must have a human
PKI Sponsor as described in Section 5.2.1.1. The PKI Sponsor is responsible for
providing the CAA, or approved IAs, through an application form, correct information
regarding:

Equipment identification

Equipment public keys

Equipment authorizations and attributes (if any are to be included in the certificate)

Contact information to enable ORC to communicate with the PKI sponsor when
required
An ORC IA authenticates the validity of any authorizations to be asserted in the
certificate, and verifies source and integrity of the data collected to an assurance level
commensurate with the certificate level being requested. Authentication and integrity
checking is accomplished by one of the following methods:

106764133
Verification of digitally signed messages sent from PKI sponsors (using certificates
of equivalent or greater assurance than that being requested)
48
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

In person registration by the PKI Sponsor, with the identity of the PKI Sponsor
confirmed in accordance with the requirements of Section 3.1.9
3.2 Routine Re-Key (Certificate Renewal)
3.2.1
CA Certificate Routine Re-Key
When an ORC ACES CA private signature key is updated, and thus generates a new
public key, ORC notifies all CAAs, IAs, RAs, LRAs, and subscribers that rely on the
CA’s certificate that it has been changed.
3.2.2
Certificate Re-Key
ACES Certificate re-keying (signing and encryption) is accomplished through the
limitation on certificate renewal, see Section 3.2.3. The minimum requirement for all
ACES certificate re-keying, with the exception of CA certificates, is once every 8 years
from the time of initial registration (i.e., after three 2-year renewals). ORC ACES
subscribers shall identify themselves for the purpose of re-keying through use of their
current signature key, except that identity shall be established through initial registration
process described in Section 3.1.
3.2.3
Certificate Renewal
ORC accepts ACES Certificate renewal requests from their subscribers within 90 days
from the scheduled end of the operational period (expiration date) of the ACES
Certificate, provided the ACES Certificate is not revoked, suspended, or expired. ACES
Certificates are renewed in 2-year increments.
To renew a certificate, as described in the ACES CP, the subscriber obtains a new
certificate based on an existing key pair. ORC authenticates the subscriber’s renewal
request using the subscriber’s current certificate for authentication in the renewal
process. In the event that subject information has changed (and/or the key pair is
required to be changed for any reason), ORC requires the subscriber to request a new
ACES Certificate. The old certificate (as a result of an update action) may or may not be
revoked, but is not further re-keyed, renewed, or updated. A certificate that is not
renewed by the end of the operation period reflects an expired status.
ORC renews ACES Certificates issued to Relying Parties only after completing
successful identity proofing verification in accordance with the requirements for identity
proofing specified in Section 3.1.9.3.
Server subscribers (PKI Sponsors) are required to have to revalidate their identity and
any equipment authorizations and/or attributes (if any are to be included in the
certificate). The subscriber is required to present a currently valid certificate to request a
new certificate. End-users are required to renew their certificates through a web-based
electronic form.
106764133
49
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Medium assurance certificate may be renewed or updated on the basis of
electronically authenticated subscriber requests three times. Every eight years, inperson authentication is required.

Medium hardware assurance certificates may be renewed or updated on the basis of
electronically authenticated subscriber requests only one time. Every four years, inperson authentication is required.
Certificates issued by an ORC ACES CA have a validity period of two years. Prior to
the expiration of these certificates, identity and encryption certificate subscribers are
required to request a new certificate, which may be done by electronically submitting
their existing certificates.
During the renewal process the user must present his or her current identity certificate
during an SSL client authentication to the CA. The CA validates the authenticity of the
certificate being presented by verifying that the certificate was issued by the CA in
question and mapping the subject name in the certificate to its corresponding certificate
in the database. This process verifies that the subscriber is eligible for renewal on the
basis of the subscriber’s existing certificate, as stipulated above. If the subscriber is not
eligible for renewal on the basis of the subscriber’s existing certificate, ORC redirects
the subscriber to the in-person registration process. The forms to accomplish this
process are controlled by access control lists on a secure web server that binds to the
corresponding users with certificates in an LDAP directory. Access control to the
renewal forms is based on comparing the certificate with the Distinguished Name of the
subscriber (based on an X.509 certificate-based authentication) against the certificate
with DN in the directory.
Provisions for the renewal of Code signing certificates are in accordance with the
Medium Hardware Assurance criteria below.
In cases where a subscriber’s organization (including PKI Sponsors or CSAAs) has
required authorizations to be included in an ORC ACES certificate, the person
responsible for the subscriber’s organization ORC ACES agreement shall notify an ORC
ACES RA of the withdrawal of authorizations, via digitally signed e-mail using a
medium assurance hardware certificate. The RA verifies the signature of the
subscriber’s organization.
3.3 Obtaining a New Certificate After Revocation
Identification and authentication of individuals after certificate revocation requires
following the steps outlined in Section 3.1.9. If private key compromise is suspected,
additional steps shall be taken to minimize key compromise risk as outlined in Section
4.4.
Invalid, suspended, revoked, or expired ACES Certificates are not renewed. Applicants
without a valid ACES Certificate are re-authenticated by ORC via a new ACES
Certificate application, just as with an initial applicant registration, and issued a new
ACES Certificate.
106764133
50
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
ORC provides for the revocation of certificates when requested, as stipulated in Section
4.4.. If the Government provides RA functions, or if ORC has delegated revocation
functions to subcontractor RA(s), all information is transmitted via a network between
ORC and/or subcontractors and/or government RAs using mutual authentication.
3.4 Revocation Request
Certificate revocation requests may be made using the same practices as certificate
issuance requests in accordance with Section 3.1.9. In addition, certificate revocation
requests may be made electronically using e-mail digitally signed by a certificate of
equal or greater level of assurance then that of the certificate that the request is for. In
either case, the request must additionally include the reason for revocation. See Section
4.4 for details on certificate revocation procedures.
A subscriber may request revocation of a certificate regardless of whether or not it has
been compromised. ORC may revoke a subscriber’s certificate for cause. The RA
collects signed documentation stating the reason and circumstances for the revocation. If
an RA performs this on behalf of a subscriber, a formal, signed message format known to
the ORC IA is employed.
In accordance with the ACES contract, an ACES Certificate revocation request that is
submitted electronically may be authenticated on the basis of a digital signature using the
ACES Certificate’s associated key pair. The identity of the person submitting a
revocation request in any other manner is authenticated in accordance with Section 3 of
this CPS. Revocation requests authenticated on the basis of the ACES Certificate’s
associated key pair are always accepted as valid. Other revocation request authentication
mechanisms may be used as well, including a request in writing signed by the subscriber
and sent via U.S. Postal Service first-class mail. ORC RAs are verify the authentication
mechanism and balances the need to prevent unauthorized revocation requests against
the need to quickly revoke certificates.
Subscribers who are in possession of their private keys may also revoke their own
certificates at any time via the ORC ACES website (http://aces.orc.com).
106764133
51
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
4
Operational Requirements
4.1 Certificate Application
ORC ACES offers the certificate types as defined in Section 1.3.4.1.
4.1.1
Application Initiation
The following parties may initiate the ORC ACES Certificate application process:
Potential Subscriber
Unaffiliated Individual
Business Representative
Qualified Relying Party
Agency Application Server
Federal/State Employee
Authorized Initiator
Potential subscriber only
Sponsoring Organization; or potential subscriber
Duly authorized representative of the Qualified
Relying Party
PKI sponsor responsible for the component
receiving the certificate
Sponsoring Organization; or potential subscriber
The application is available only on the Internet at http://aces.orc.com. Once the
applicant starts the application process, the Internet protocol changes from non-secure to
secure using the SSL protocol.
The individual requiring the certificate shall make certificate requests. When applicable,
the subscriber’s organization is required to provide a point of contact for verification of
any roles or authorizations to be included in the subscriber’s certificates, via signed
letterhead or digitally signed e-mail. The CAAs record all such appointments in a log
available to all RAs. This point of contact may be the PKI Sponsor or CSAA.
Generally, requests are made from the primary workstation of the subscriber via a web
interface. When making the certificate request, the applicant shall submit a proposed
distinguished name in accordance with local naming conventions, generate the public
private key pair using FIPS 140-1 Level 1 approved software or Level 2 hardware tokens,
and submit the information and the public key to the CA for disposition.
The applicant shall protect the private key with a password. This password shall be kept
confidential and shall not be recorded or given to any other parties except in accordance
with locally approved key escrow procedures.
In the case of medium assurance certificates, the applicant shall make the request using a
web browser incorporating a FIPS 140-1/2 Level 1 cryptographic module for generating
the key pair and submitting the required information through an online form. In the case
of medium hardware assurance certificates, the applicant shall make the request at the
RA workstation using a web browser and a FIPS 140-1/2 Level 2 token for generating
the key pair and submitting the required information through an online form. The
following instructions explain the steps necessary for an applicant to apply for a
certificate:
106764133
52
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Connect to the ORC ACES web page (http://aces.orc.com) and follow the directions
filling out the electronic and printed forms

For encryption keys, the application process asks if the subscriber desires to escrow
the encryption key and notifies subscriber upon successful completion or failure of
key escrow

Present the printed application and two photo IDs to an RA, LRA, or Notaries Public
(or a person legally empowered to witness and certify the validity of documents and
to take affidavits and depositions)
Upon notification of certificate issuance by e-mail, the certificate is accepted and
retrieved.
4.1.1.1
Application Form
The PKI issues certificates to EEs. It does not issue certificates to or cross-certify with
other CAs without express permission from the Government.
The individuals requiring certificates shall make certificate requests. Requests are made
from a workstation via a web interface. When making a certificate request, the applicant
shall complete an ACES Certificate application and provide requested information
requested by an on-line form. The following steps occur during the application process:

The applicant is presented with the Root CA certificate and requested to trust this
CA. The site is be protected by a firewall and incorporates SSL to ensure secure
distribution of the certificate and to prevent substitution, as stipulated in Section 5

The applicant is presented with a screen detailing the subscriber obligations and
required to accept these obligations prior to continuing

The applicant completes the online form which includes his or her name, address,
phone number, e-mail address (if available), social security number, and other
identifying information

The applicant generates a public and private key pair and is required to use a
password to protect the private key, as stipulated in the Subscriber Agreement. This
password is stored locally and is required to be kept confidential and not be recorded
or given to any other parties. The password shall be in compliance with best
commercial practices

The applicant submits identifying information and the public key to the CA

The applicant proves to the CA that the public key forms a functioning key pair with
the private key via the proof of possession functionality as described in Section 3.1.7
Upon submission of the completed application form, the applicant is provided with a
request number and is required to print the form, and take it, with the appropriate identity
credentials, to an authorized RA, LRA, trusted agent or member of the Notary Public to
have the identity credentials verified. If the applicant goes in person to an RA, LRA or
trusted agent, the application process for the applicant is completed. If the applicant has
the forms notarized, the applicant is required to send the notarized form via U.S. postal
106764133
53
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
service to ORC or personally deliver the forms to an ORC facility. This information is
provided on the printed form.
4.1.1.2
Applicant Education and Disclosure
At the time of an ORC ACES certificate application ORC ACES website:

Informs applicants of the need for independent verification of their identity

Requests permission to perform this independent verification

Indicates the advantages and potential risks associated with using ACES Certificates
to access Qualified Relying Parties electronically

Provides information to subscribers regarding the use of private keys and digital
signatures created with such keys
The subscriber acknowledges, via the application form, the subscriber obligations as
defined in this CPS.
4.1.2
Application Rejection
If verification is not successful or the application is otherwise rejected, ORC notifies the
applicant of the verification failure or rejection via an out-of-band notification process
linked to the certificate applicant’s physical postal address. This notification includes
the steps required by the applicant to resume processing of the certificate request.
4.2 Certificate Issuance
Upon successful completion of the subscriber identification and authentication process in
accordance with the GSA ACES Contract, ORC creates the requested ACES Certificate,
notifies the applicant thereof, and makes the ACES Certificate available to the applicant.
If the applicant provided an e-mail address, ORC sends the notification message via email. If no e-mail address was provided, ORC sends the notification to the U.S. postal
mail address provided.
The notification informs the applicant of the creation of a certificate, state a URL for use
by the applicant for retrieving the certificate, contain a unique serial number, and
reaffirm the subscriber’s responsibilities as explained in the application process and
described in Section 3.1.9. The notification also obligates the subscriber to:
106764133

Accurately represent themselves in all communications with the ORC PKI;

Protect the private keys at all times, in accordance with this policy, as stipulated in
their certificate acceptance agreements, and local procedures;

Notify ORC, in a timely manner, of the suspicion that their private keys are
compromised or lost. Such notification is made directly, or indirectly through
mechanisms consistent with this CPS

Abide by all the terms, conditions, and restrictions levied upon the use of their
private keys and certificates
54
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Upon issuance of an ACES Certificate, ORC warrants to all program participants that:

ORC has issued, and manages, the ACES Certificate in accordance with the
requirements in this CPS

ORC has complied with all requirements in this CPS when identifying the subscriber
and issuing the ACES Certificate

There are no misrepresentations of fact in the ACES Certificate known to ORC and
that ORC has verified the information in the ACES Certificate

Information provided by the subscriber for inclusion in the ACES Certificate has
been accurately transcribed to the ACES Certificate

The ACES Certificate meets the material requirements of this CPS.
The ORC ACES CAs are configured to establish client authenticated SSL sessions and is
configured (by the CAA) to recognize IAs as legitimate issuers via certificate
authentication. IAs using CA issued medium hardware assurance certificates, and
recognized by the CA, are required to initiate the SSL session with the CA to begin the
issuance process. Upon successful authentication, the IA searches the CA database for
the appropriate certificate request.
The IA issues certificates upon receipt of the RA digitally signed e-mail only after
verifying that the applicant’s subject DN (provided in the RAs e-mail) matches the
subject DN in the CA database. The IA archives the e-mails signed by RAs. When
issued certificates are published and issuance transactions automatically logged.
In the case of code signing certificate issuance, the IA verifies that the subject DN and
the DN in the subject alternate name field match those provided by the attribute authority
and the code signer.
4.2.1
4.2.1.1
Certificate Delivery
Delivery of Subscriber’s Public Key to Certificate Issuer
Public keys are delivered to the certificate issuer in a way that binds the applicant’s
verified identification to the public key being certified only after the subscriber has read
and agreed to the Subscriber Agreement (obligations), as defined in this CPS. The
binding is accomplished using means that are as secure as the security offered by the
keys being certified. The binding is accomplished using cryptographic, physical,
procedural, and other appropriate methods, described in this CPS.
Medium assurance and medium hardware assurance requests are treated the same, except
all medium hardware assurance requests is made in the presence of an RA, LRA or other
designated trusted agent.
4.2.1.2
Delivery of Subscriber’s Private Key to Subscriber
Private keys associated with medium assurance certificates are generated and stored in
the subscriber’s software or hardware cryptographic modules, there is no need to deliver
them.
106764133
55
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
In the case of medium hardware assurance encryption certificates, ORC’s card issuing
requires that the keys are generated on a FIPS 140-1/2 Level 3 device at the CA. Those
keys are delivered to the ORC Key Recovery System (KRS) and the hardware token; and
encrypted by keys protected by FIPS 140-1/2 Level 3 in the case of the KRS, and Level 2
in the case of the token.
4.2.1.3
CA Public Key Delivery to Users
ORC supports delivery of the ORC ACES CAs public keys via a web interface to a
protected server using SSL. The public key shall be stored such that it is unalterable and
not subject to substitution. The Relying Party must contact the help desk to receive the
official certificate hashes to compare them with the certificates downloaded from the
site.
4.2.2
Certificate Replacement
ORC provides for the replacement of certificates when the subscriber’s private key has
not been compromised and there are no changes to the certificate.
Upon receiving an authenticated request to replace a damaged or lost certificate from a
subscriber (i.e., unaffiliated individual, business representative, agency application
server, or Federal, State and Local Government employee) or an authorized official of a
business entity for a business representative subscriber, ORC records the following
certificate replacement transaction data:

Certificate serial number

Certificate common name

Certificate policy OID

Date/time of completion of replacement process

Name (ID) of ORC ACES PKI process(es)
Fees associated with certificate and/or token replacement are stipulated in Section 2.5.
4.3 Certificate Acceptance
As described in the ACES Contract, a condition to issuing an ACES Certificate is that
the subscriber shall indicate acceptance or rejection of the ORC ACES Certificate to
ORC and acknowledge the subscriber obligations. By accepting the ORC ACES
Certificate, the subscriber is warranting that all information and representations made by
the subscriber that are included in the ORC ACES Certificate are true.
ORC notifies the certificate applicant of certificate issuance through e-mail. The
notification includes the URL that the applicant uses to receive the approved certificate.
ORC verifies possession of the subscriber’s private key at the time the applicant accepts
the issued certificate.
106764133
56
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
The notification informs the subscriber of the creation of the certificate, contents of the
certificate and reaffirms the subscriber’s responsibilities as explained in the application
process and described in Section 3.1.9. The notification informs the subscriber if the
private key has been escrowed.
The subscriber agreement includes the following subscriber obligations. The subscriber
shall:

Accurately represent themselves in all communications with the ORC.

Protect their private keys at all times, in accordance with this policy, as stipulated in
their certificate acceptance agreements, and local procedures.

Notify ORC, in a timely manner, of the suspicion that their private keys are
compromised or lost. Such notification shall be made directly, or indirectly through
mechanisms consistent with this CPS.

Abide by all the terms, conditions, and restrictions levied upon the use of their
private keys and certificates.

Formally accept the certificate at the designated ORC web page during certificate
retrieval. (Failure to do so will result in revocation of the certificate.)
The subscriber has already agreed to the obligations during the request phase (as
stipulated in the Subscriber Agreement), and the certificate can only be accepted during a
proof of possession of private key test. ORC logs the acceptance of the certificate.
A subscriber who does not provide this verification notice within 30 calendar days of
receiving notification that his or her approved certificate is available for downloading, or
who is found to have acted in a manner counter to these obligations shall have their
certificate revoked, and will forfeit all claims he or she may have against the ORC ACES
PKI in the event of a dispute arising from the failure to fulfill the obligations above.
4.4 Certificate Suspension and Revocation
The individual making the request shall either digitally sign requests for certificate
revocation, or the individual shall present the request in person to an RA.
Note: Code signer certificates may not be revoked when the code signer departs or is
no longer with the organization. Code signer’s suspected of having signed
(intentionally or unintentionally) unapproved code, may have their code signing
certificate revoked by the IA.
4.4.1
Who Can Request a Revocation
The following authorized parties may request a revocation of a certificate:
106764133

Any EE may request revocation of their own certificate(s)

RAs and LRAs may request revocation of any EE certificate on behalf of the EE or
other authorized party.
57
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

An ORC IA may revoke any certificate within its domain for reasons identified in
this CPS.

Other parties may also request revocation of certificates through an ORC RA or
LRA. The ORC RA or LRA validates the credentials of the requesting party, and the
RA determines if the revocation request meets the requirements of this CPS.
If any individual has reason to believe that a certificate private key has been
compromised, that individual is required to notify the ORC RA or LRA of the
compromise suspicion. It is the responsibility of the ORC RA to investigate the
information and determine if certificate revocation is warranted.
If so, the RA forwards the revocation request along with documentation of the reason for
the request to the ORC IA. ORC sends a written notice and brief explanation for the
revocation to the subscriber.
4.4.2
Circumstances for Revocation
Whenever any of the circumstances below occur, the associated certificate shall be
revoked and placed on the CRL. In addition, if it is 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 shall be revoked. Certificates shall remain on the CRL until
they expire. They shall be removed after they expire, but must at least appear in one
CRL.
4.4.2.1
Permissive Revocation
As described in the ACES contract, a subscriber may request revocation of his/her/its
ORC ACES Certificate at any time for any reason. A Sponsoring Organization may
request revocation of an ACES Certificate issued to its Business Representative at any
time for any reason. If the Government provided RA functions, or if ORC has delegated
revocation functions to subcontractor RAs, all information is transmitted via a network
between ORC and/or subcontractors and/or government RAs using mutual
authentication.
4.4.2.2
Required Revocation
A subscriber, or a Sponsoring Organization (where applicable), is responsible for
promptly requesting revocation of an ACES certificate:
106764133

When the private key, or the media holding the private key, associated with the ORC
ACES Certificate is, or is suspected of having been, compromised

When the individual named as a Business Representative no longer represents, or is
no longer affiliated with, the Sponsoring Organization

If ORC learns, or reasonably suspects, that the subscriber’s private key has been
compromised or the subscriber has failed to meet their responsibilities
58
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

If ORC determines that the ORC ACES Certificate was not properly issued in
accordance with this CPS

The certificate holder requests that the certificate be revoked

The certificate holder can be shown to have violated the subscriber obligations,
including payment of any required fees

The certificate holder is no longer authorized to hold the certificate (e.g. termination
of employment or change in responsibilities)

The information in the certificate is no longer accurate so that identifying
information needs to be changed (e.g. change of name or privilege attributes asserted
in the subscriber’s certificate are reduced)

The subscriber’s employer or organization requests revocation

The certificate was obtained by fraud or mistake

The certificate was not correctly requested, issued or accepted

The certificate contains incorrect information, is defective or creates a possibility of
incorrect reliance or usage

Certificate private key compromise is suspected

The certificate holder fails to make a payment or other contractual obligations
related to the certificate
ORC reserves the right to revoke any ORC ACES issued certificate at its discretion.
ORC provides for the revocation of certificates when requested, at any time for any
reason. If the Government provided RA functions, or if ORC has delegated revocation
functions to subcontractor RAs, all information is transmitted via a network between
ORC and/or subcontractors and/or government RAs using mutual authentication.
4.4.3
Revocation Request Procedure
As described in the ACES Contract, an ORC ACES certificate revocation request should
be promptly communicated directly to an RA or LRA who are authorized to accept such
notices on behalf of the CA.
If the subscriber is making the revocation request, and is in possession of the private key
associated with the certificate, the subscriber may access the ORC ACES website to
revoke their own certificate at any time. This revocation is immediate.
If the subscriber is no longer in possession of the private key, or an entity other than the
subscriber is making the revocation request, this request may be communicated via an
online form, electronically via digitally signed e-mail, or in person to an ORC RA, or via
U.S. postal mail.
All revocation requests are verified prior to certificate revocation. If the subscriber
makes the request and has the private key, this proof of possession test is considered
adequate and the certificate is revoked immediately. If the request comes via a digitally
106764133
59
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
signed e-mail message (signed with a certificate at least of the same assurance level as
the certificate to be revoked) sent from an ORC CMA or an authorized Sponsoring
Organization representative, validation of the e-mail signature is considered adequate
and the certificate is revoked.
If the request comes from an in person visit, identity credentials are required (at least to
the same assurance level as the certificate to be revoked) from the individual making the
request and verified prior to revoking the certificate. If the request is made via online
form or unsigned e-mail, ORC contacts the subscriber via the information kept in the
database from the request process to verify the request prior to certificate revocation.
For these cases, the certificate is suspended pending verification of the revocation
request.
If an ORC CMA or RA is making the request, the reason for the revocation request is
documented. If an LRA is requesting the revocation, the reason shall be sent to an RA
via a digitally signed e-mail message for revocation, who investigates the request,
document the reason for the revocation request and archive. Upon disposition, the CMA
or RA sends the reason for revocation and confirm that it was vetted to the IA via a
digitally signed e-mail message for revocation.
ORC shall revoke or suspend the certificate by placing its serial number and other
identifying information on a Certificate Revocation List (CRL). ORC shall also remove
the certificate from any repositories containing that certificate.
The subscriber is notified of the revocation request, reason for the request, and status of
the request. If appropriate, the subscriber is provided information on obtaining a new
certificate and a list of all certificates issued.
If an ORC CMA is choosing to revoke a certificate because of sufficient evidence of
noncompliance with this CPS, an ORC IA documents the reason for certificate
revocation and notifies the subscriber of the revocation.
Subscribers leaving the organizations that sponsored their participation in the PKI shall
surrender to their organization's PKI point of contact (through any accountable
mechanism) all cryptographic hardware tokens that were issued, under the sponsoring
organization, prior to leaving the organization. The PKI point of contact shall zero (refer
to Section 6.2.7) or destroy the token promptly upon surrender and shall protect the
token from malicious use from the time of surrender. In all cases, whether software or
hardware tokens are involved, the organization shall promptly notify an ORC RA to
revoke the certificate and attest to the disposition of the token, via a digitally signed email.
4.4.4
Revocation Grace Period
Certificates are revoked upon request as soon as the need can be verified. There is no
grace period. The subscriber, or sponsoring organization, must request revocation from
ORC as soon as the need for revocation has been determined.
106764133
60
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
4.4.5
4.4.5.1
Certificate Authority Revocation Lists (CARLs)/Certificate Revocation
Lists (CRLs)
CRL Issuance Frequency
The ORC ACES CAs issue CRLs every 12 hours with a validity period of seven (7)
days. A new CRL is issued twice per day even if there are no changes or updates to be
made. When a revocation request is granted for the reason of key compromise, a new
CRL is generated as quickly as is feasible and posted within eighteen hours of receipt of
the request. All superceded CRLs are removed from the repository upon posting of the
latest CRL.
ORC ACES CRLs may be obtained from: ldap://aces-ds.orc.com/cn=ORC ACES <CA
Name>, o=ORC PKI, c=US?certificaterevocationlist;binary.
4.4.5.2
CRL Checking Requirements
It is the responsibility of the relying party to verify that certificates have not been
revoked. Certificates may be stored locally by a relying party, but should be validated at
least daily before use. The relying party shall always check a certificate against a CRL
that has not expired.
Any relying party that downloads the CRL shall verify the authenticity of the CRL by
verifying the signature and associated certification path. They should also check the
CRL date to confirm that old CRLs are not presented in a replay attack. The following
text is included in the Subscriber Agreement and posted on the ORC ACES website:
“USE OF REVOKED CERTIFICATES COULD HAVE DAMAGING OR
CATASTROPHIC CONSEQUENCES IN CERTAIN APPLICATIONS. THE
MATTER OF HOW OFTEN NEW REVOCATION DATA SHOULD BE
OBTAINED IS A DETERMINATION TO BE MADE BY THE RELYING PARTY
AND THE SYSTEM ACCREDITOR. IF IT IS TEMPORARILY INFEASIBLE
TO OBTAIN REVOCATION INFORMATION, THEN THE RELYING PARTY
MUST EITHER REJECT USE OF THE CERTIFICATE, OR MAKE AN
INFORMED DECISION TO ACCEPT THE RISK, RESPONSIBILITY, AND
CONSEQUENCES FOR USING A CERTIFICATE WHOSE AUTHENTICITY
CANNOT BE GUARANTEED TO THE STANDARDS OF THIS PRACTICE
STATEMENT.”
4.4.6
Online Revocation/Status Checking Availability
ORC validates online and near-real-time the status (Valid, Invalid or Suspended) and
signature of the ACES Certificate indicated in an ACES Certificate Validation Request
message. The CA returns in the Certificate Status Response message a signed message.
This functionality is integrated with the GSA-approved Certificate Arbitrator Module
(CAM) using the Online Certificate Status-checking Protocol (OCSP).
The ORC WAN OCSP Responder (CSP) is located at: http://aces.eva.orc.com. Contact
ORC to register for use.
106764133
61
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
4.4.7
Online Revocation Checking Requirements
Each Qualified Relying Party will validate every ACES Certificate it receives in
connection with a transaction. Any self-signed OCSP responder used for verifying
certificates asserting a policy OID from this CPS are required to meet the certificate
profile stipulated in Appendix E of this CPS and ensure that:

Certificates indicated as being valid have a chain of valid certificates (valid as
defined by [X.509]) linking back to a “trusted Root CA”

Each certificate in the certificate chain used to validate the certificate whose status is
being requested is checked for revocation, such that the Relying Party need not
check more than one responder to validate a subscriber certificate

Certificate status responses provide authentication and integrity services
commensurate with the assurance level of the certificate being verified

It is made clear in the certificate status response the attributes (other than certificate
subject name (e.g., citizenship, clearance authorizations, etc.)) being authenticated
by the responder

An accurate and up-to-date CRL, from the authorized CA, is used to provide the
revocation status

Revocation status responses provide authentication and integrity services
commensurate with the assurance level of the certificate being checked
ORC disclaims any liability for loss due to use of any validation information relied on by
any party that does not comply with this stipulation, in accordance with this CPS.
4.4.8
Other Forms of Revocation Advertisements Available
No stipulation.
4.4.9
Checking Requirements for Other Forms of Revocation Advertisements
Available
No stipulation.
4.4.10 Special Requirements With Respect to Key Compromise
If an ORC ACES certificate is revoked because of suspicion of private key compromise,
the following additional requirements apply in addition to requirements specified above.
ORC issues new CRLs with date of compromise and notifies, through website posting,
any relying parties that download the CRL that a certificate has been revoked because of
key compromise, and the date that the suspected compromise occurred.
If the compromised certificate was an RA certificate, the RA revalidates any subscriber
certificates validated after the date of the suspected compromise, and revokes any
certificates not revalidated.
106764133
62
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Note: ORC uses reason codes and has the ability to transition any reason code to
compromise.
4.5 Certificate Suspension
4.5.1
Circumstances for Suspension
If a certificate revocation request is received in an unverified manner, the certificate is
placed in suspended status pending authentication of the request. See Section 4.4.3 for
details. At no time does ORC suspend a CA certificate.
4.5.2
Who Can Request Suspension
See Section 4.4.1.
4.5.3
Procedure for Suspension Request
See Section 4.4.1. The suspension state remains until the revocation request is verified.
4.6 Computer Security and Audit Procedures
All significant security events on the ORC ACES system are automatically recorded in
audit trail files. Such files shall be securely archived in accordance with Section 4.6.1.
The ORC CA equipment records, for purposes of security audit, events as described
below, whether the events are attributable to human action (in any role) or are
automatically invoked by the equipment. The information recorded includes the type of
event, and the date and time the event occurred. Where appropriate, ORC records the
success or failure, the source or destination of a message, or the disposition of a created
object (e.g., a filename). The auditing capability of the underlying CA equipment
operating system is enabled during all installations. Where possible, the audit data is
automatically collected. When this is not possible, a logbook is used. Logbook entries
include records of hardware and software maintenance, designation of official personnel
and certain RA, LRA, and IA responsibilities that require out-of-band activity, as
stipulated below; as well as, records of any paper forms or copies of identity credentials
collected from subscribers.
Proofs of possession checks for the applicant’s private key are performed for correlation
with the applicant's public key at two separate instances as described in Section 3.1.7.
The first check is performed during the certificate request process where the public
private key pair is generated and the public key is passed on to the CA. At this time the
CA automatically records the:
106764133

Request ID

Module which accomplishes authentication

DNCN Requested
63
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
The second check is performed after a certificate has been generated. The CA signs the
public key and user subsequently collects his/her certificate.
4.6.1
Types of Event Recorded
ORC archives data and files that include ACES certificate application information,
certificate issuance, and transaction data.
ORC records events attributable to human intervention or automatically invoked by the
equipment, refer to Appendix X. At a minimum, the information recorded includes the
type of event and the time the event occurred. Where appropriate, additional information
is recorded. Where possible, the security audit data is automatically collected; when this
is not possible, a logbook, paper form, or other physical mechanism is used. All security
audit logs, both electronic and non-electronic, is retained in accordance with the
requirements of Section 4.5.3, and made available during compliance audits.
For each auditable event, CMA security audit records include, at a minimum:

The type of event

The date and time the event occurred

Messages from RAs (or other entities) requesting CA actions, the message source,
destination and contents

Attempted CA certificate signature or revocation, a success or failure indication

Operator initiated actions (including equipment and application access), the identity
of the equipment operator who initiated the action
Events related to the CA, IA and CSA software:
106764133

Installation - name of installers, date of installation, and build information of any
files installed, as well as and EE key generation (accomplished and logged in system
“Audit Notebook” by CAA and SA in accordance with ORC PKI Installation Plan,
Version Description Document and Installation Procedures, after installation the
Solaris Basic Security Module (BSM) logs collect some of the activities
automatically)

Software modification - name of modifier, date of modification, build information of
any modified files, reason for modification (software changes, once generated/tested,
are installed and logged in system “Audit Notebook” by CAA and SA, BSM logs
automatically capture information such as administrator log-on and file change
activity)

Configuration modification - changes in configuration files, security profiles,
certificate and CRL profiles, administrator privileges, changes to audit parameters,
and reason for modification (configuration changes, once generated/ tested, are
installed and logged in system “Audit Notebook” by CAA and SA, BSM logs
automatically capture information such as administrator log-on and file change
activity)
64
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Logins and logouts - username, unique identifier number, and time are recorded for
failed login attempts (BSM logs automatically capture), the number of failed login
attempts permitted prior to logging is three (3) (manually logged)

Anomalies, error conditions, software integrity check failures, receipt of improper or
misrouted messages (automatically captured by BSM and CA/CSA application
software records, anomalies noted from inspection of these records are manually
logged)

Any known or suspected violations of physical security, suspected or known
attempts to attack the CMA equipment via network attacks, equipment failures,
power outages, network failures, or violations of this certificate policy (the system is
protected by 1) two separate physical access logging/alarm systems, see Section
5.1.2; 2) firewalls, where each firewall rule is monitored by an auditing module, see
Section 6.6; and, 3) traffic recording, intrusion detection, and forensic analysis
system to monitor intrusion attempts and policy verification, see Section 6.6;
anomalies noted from inspection of these records are manually logged)
The equipment records server installation, access, and modification (to include changes
in configuration files, security profiles, and administrator privileges). Security auditing
capabilities of the underlying CMA equipment operating system are enabled during
installation. The following operations are recorded:

Equipment configuration (manually logged)

Equipment access (e.g., room access) (automatically and manually logged)

File manipulation and account management (automatically logged)

Posting of any material to a repository (automatically logged)

Access to databases (automatically logged)

Any use of a signing key (automatically logged)
Events related to the processing:
106764133

Certificate generation requests – including sender DN, subject DN, and transaction
ID (automatically logged)

Certificate revocation requests – including sender DN, issuer DN and serial number
of certificate revoked, subject DN of certificate to revoke, revocation reason,
transaction ID, and date of suspected compromise (automatically logged)

Responses - transaction ID, subject DN, and status of request (automatically logged)

User confirmation (certificate acceptance) – receipt transaction ID, subject DN, and
method of confirmation (automatically logged)

Other actions - designation of IAs and RAs, execution of any IA and RA duties,
CSAA authorizations, manual interactions with EEs (manually logged), disclosure of
information, access to databases, and CRL generation (automatically logged)

Publications - certificate and CRL publication to directory, and changes to CPS
(automatically logged)
65
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Re-key - new certificate mapped to the list of designated IAs and RAs (manually and
automatically logged)

Error conditions - anomalies, software integrity check failures, receipt of improper
messages (manually and automatically logged)

Physical access to, loading, zeroing, transferring keys to or from, backing-up,
acquiring or destroying cryptographic modules (manually logged)

Receipt, servicing (e.g., keying or other crypto-logical manipulations), and shipping
hardware cryptographic modules (manually logged)

Any known or suspected violations of physical security, suspected or known
attempts to attack the equipment via network attacks, equipment failures, power
outages, network failures, or violations of this certificate policy (manually logged)

Certificate generation requests – including subject DN and transaction ID
(automatically logged)

CA responses - transaction ID, subject DN, and status of request (automatically
logged)

Interactions with CA - CA compromise or re-key (automatically and manually
logged)

Documentation of receipt and acceptance of certificates (automatically logged)
Events to be recorded by the RA and/or LRA:

Authentication of user identity - copies of photo ID, verification of organizational
affiliation, and any forms filled out by users (manually logged)

Certificate revocation requests – including issuer DN and serial number of certificate
revoked, subject DN of certificate to revoke, revocation reason, and transaction ID
(automatically logged)

Certificate Change Status – including issuer DN and serial number of certificate
changed, reason for change, and transaction ID (Manually logged)

Manual interactions with EEs - telephone or in person requests for revocation
(manually logged)

Documentation of receipt of tokens (manually logged)

Any actions taken in association with cryptographic modules of subscribers who
have left their organizations (manually logged)
Note: Any other actions taken during the processing of a request and generation of a
response will be recorded. Many RA responsibilities require out-of-band
activity. Records of such activity shall be recorded in a logbook or other
physical medium. A record of any paper forms or copies of photo IDs collected
from users shall be maintained.
The following events applying to humans and physical operations are audited:
106764133
66
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Appointment of CAA, IA, RA and LRA personnel (manually logged)

Training of CAA, IA, RA and LRA personnel (manually logged)

Physical access to the CA, CSA and IA equipment (automatically and manually
logged)

Operator initiated actions (including equipment and application access), the identity
of the equipment operator who initiated the action (automatically and manually
logged)
4.6.2
Frequency of Processing Data
The CA, RA, IA, and system audit logs and personnel access logs are consolidated
(summarized) and reviewed weekly by the Corporate Security Auditor. As stated in the
ACES CP, 25% of all of the security audit data is reviewed, at a minimum. IAs review
RA audit logs. The audit logs are removed monthly to CDROM for archival purposes
and to ensure that the security audit data is transferred prior to overwriting or overflow
of automated security audit log files.
4.6.3
Retention Period for Security Audit Data
The information generated on the CA, IA and CSA equipment is kept on the CA, IA and
CSA equipment until the information is moved to an appropriate archive facility. The
SA in coordination with the Corporate Security Auditor performs deletion of the audit
log from the CA, IA and CSA equipment. Security audit data is retained on-site for at
least two months. Audit and security logs are retained off-site as archive records in
accordance with this CPS.
4.6.4
Protection of Security Audit Data
Audit logs are protected from unauthorized modification or unauthorized deletion. No
person is authorized to modify the content of audit logs, except for appending new audit
records without overwriting existing audit records. The action of two parties is required
to protect the data, as described in this CPS, the Operating Procedures, and the Roles
Manual. This two party control ensures that audit data cannot be open for reading or
modification by any human, or by any automated process, other than those that perform
security audit processing and that no unauthorized user is able to write to, modify, or
delete the archive.
Electronic audit logs are deleted only after they have been backed up to archive media.
Only ORC SAs are authorized to delete CA, CSA, or IA logs. RAs each manage their
respective audit records. Before deleting any electronic audit log, ORC’s Corporate
Security Auditors verifies that the audit log data has been successfully backed up to
archive media. No person is authorized to delete or destroy audit data recorded on
archive media, except as stipulated in Section 4.7.2.
106764133
67
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
4.6.5
Security Audit Data Backup Procedures
Audit logs are backed up along with the rest of the data on the CA, IA and CSA
equipment, as described in this CPS, in addition to the weekly consolidation and
monthly, as described in the same Section 4.7.
4.6.6
Security Audit Collection System (Internal vs. External)
The ORC security audit process is independently controlled through the Corporate
Security Auditor and the SA. The audit system is internal to CA, IA and CSA equipment
and operates at the network, operating system and application level. Should it become
apparent that an automated security audit system has failed, ORC shall cease all
operation except for revocation processing until the security audit capability can be
restored. ORC shall invoke the audit processes at system startup and shall cease audit
processes only at system shutdown. At no time does ORC operate the CA, IA or CSA
without a functioning audit capability.
RA audit logs are manually collected. Signed e-mail requests received by an IA are
maintained as electronic audit records. An IA archives their inbox to a CDROM (or
other Policy Authority approved media) on a monthly basis.
4.6.7
Notification to Event-Causing Subject
ORC does not necessarily notify an entity of an auditable event caused by that entity.
4.6.8
Vulnerability Assessments
SAs and other operating personnel are instructed to be watchful for attempts to violate
the integrity of the CA, including the equipment, physical location, and personnel. The
daily intrusion detection audit logs are checked at the end of each working day for
anomalies in support of any suspected violation. The weekly-consolidated audit logs are
reviewed at the end of each week by a security auditor for continuity of audit data and
events such as repeated failed actions, requests for privileged information and attempted
access of system files.
ORC operates secure systems in accordance with WebTrust security guidelines and
undergoes independent audit of its operations once a year.
4.7 Records Archival
4.7.1
Types of Data Archived
The ORC ACES archive records are kept with sufficient detail to establish the validity of
a signature and of the proper operation of the CA, IA and CSA. At a minimum, the
following data are archived:
During system initialization:

106764133
Self accreditation documentation
68
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

This CPS, policies and procedures

Any contractual agreements

System and equipment configuration
During ORC ACES operation:
106764133

Modifications or updates to any of the above data items

Certificate status requests and responses

Audit log of all data identified in this CPS

Security audit data

Other data or applications sufficient to verify archive contents

Authorized CA accreditation

Modifications and updates to system or configuration

Certificate requests

Revocation requests

Subscriber Identity Authentication data as per Section 3.1.9

Documentation of receipt and acceptance of certificates

Export of private keys

Documentation of loading, shipping, receipt and zeroizing of tokens

All certificates issued or published

All changes to the certificate profile

All changes to the revocation profile

All changes to the revocation list profile

All changes to the trusted public keys

Record of Authorized CA re-key

All CRLs and CARLs/ issued and/or published

All routine certificate validation transactions

All audit logs

Other data or applications to verify archive contents

All work related communications to or from the Policy Authority, and compliance
auditors
69
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
4.7.2
Retention Period for Archive
Archived records are retained for ten years and six months. Prior to the end of the
archive retention period, ORC will provide archived data to a Policy Authority approved
archival facility, upon request. ORC could itself own that facility.
Applications necessary to read these archives are maintained for at least the applicable
retention period above. Those applications include:

WinZip 8.1

ASCII text reader (e.g. Notepad v 5.0)

Netscape CMS 6.1

SUN JarSign toolset

CDROM reader capable of reading IS09660

Solaris 8 operating system
Requests for archived material are provided in the above format with the above tools.
4.7.3
Protection of Archive
No unauthorized users are able to write to, modify, or delete the archive. The archive is
transferred to CDROM (or other Policy approved media) and stored off-site in a secured
location. The ORC CAAs maintain a list of individuals authorized to modify or delete
the archive. The list is available during compliance audits.
4.7.3.1
Archive Backup Procedures
Audit data is backed-up on a weekly basis. ORC creates a monthly backup of audit data
for off-site storage labeled with the ORC ACES name and date, and stored in a separate
location under the control of individuals other than the designated CAA and the SA.
4.7.3.2
Archive Collection System (Internal or External)
Consolidated audit logs are stored on the ORC CA equipment until copied to unalterable
media (e.g., recordable CDROM (CDR)). Consolidated audit logs are moved monthly to
unalterable media. The unalterable media are stored off-site in a secure location.
Additional consolidated logs may be stored on the media without modifying previously
stored audit logs.
4.7.3.3
Procedures to Obtain and Verify Archive Information
Archive data is obtained from the archive media by the Corporate Security Auditor only
in response to a verified request for review of archived information.
When archive information is needed, the Corporate Security Auditor is contacted to
retrieve the data from storage. The Corporate Security Auditor then views the contents
106764133
70
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
of the archive to insure that the correct data is being retrieved. Procedures for creating
the archive or archive extraction are located in the ORC PKI Operator’s Manual.
4.8 Key Changeover
A self-signed ORC Government Root CA signs the ORC ACES CA certificates. This
Root CA private key is used only to sign CA certificates, cross certificates, and CRLs. A
new self-signed Root CA signing authority certificate will be issued to sign CA
certificates when the validity period of the CA exceeds the remaining validity period of
the Root CA. The old Root CA certificate continues to be used to sign CRLs until all
CA certificates issued by that Root CA certificate have expired.
ORC uses a signing (private) key for creating certificates; however, Relying Parties
employ the ORC ACES CA certificates for the life of the subscriber certificate beyond
that signing. Therefore, the CA does not issue subscriber certificates that extend beyond
the expiration dates of its own certificates and public keys, and the CA certificate
validity period will extend one subscriber certificate validity period (listed in this CPS)
past the last use of the CA private key. To minimize risk to the PKI through compromise
of the CA key, the private signing key is changed more frequently, and only the new key
is used for certificate signing purposes from that time forward. This is accomplished by
setting up a new CA with a new signing key. The older, but still valid, certificate will be
available to verify old signatures until all of the subscriber certificates signed under it
have also expired. Since the old private key is used to sign CRLs that contain
certificates signed with that key, the old key will be retained and protected. Key
changeover is accomplished in accordance with Certificate Management Protocol
[RFC2510].
The validity period of an ORC ACES CA signature certificate is 6 years. RA key
lifetimes are as described for subscribers in this CPS.
Note that signature keys that have expired for the purposes of certificate signature may
still be used for CRL signature.
4.9 Compromise and Disaster Recovery
Compromise or disaster notification and recovery procedures are employed by ORC to
ensure a secure state. The security provided by the PKI is dependent on protection of the
CA private keys. The CA keys are protected from compromise due to malicious attack
or inadvertent loss of key/ activation data; as well as, from disasters causing the loss of
essential equipment, by employing controls such as:
106764133

Two person control procedures of the CA and CSA hardware encryption modules,
which includes physical separation of its activation mechanism

Two person control procedures of the CA and CSA key activation data

Assignment of passwords only to authorized trusted users

Backup and recovery systems
71
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Periodic changing of passwords
These measures minimize the risk of compromise due to use, storage, or knowledge of
key activation mechanisms.
4.9.1
Computing Resources, Software, and/or Data are Corrupted
CA data, including audit logs and the certificate database, are backed up on an external
tape backup system. Differential backups are run weekly, as a minimum, to back up all
files modified since the last full backup. A full backup is run at least monthly where all
files are saved to the tape.
Two sets of the weekly and monthly backup tapes are created. One set is retained on-site
in a safe or fireproof cabinet. The other set is moved off-site to a safe, fireproof cabinet,
or safe deposit box. At least four months of backup data are retained. A rotation
schedule is used to ensure that at least four months of backup data is available. Data on
each tape is overwritten when that tape comes up in the rotation schedule.
4.9.2
Authorized CA Public Key Is Revoked
CA termination is handled in accordance with Section 4.10. If the termination is for
convenience, contract expiration, re-organization, or other non-security related reason,
certificates may continue to be considered valid at the discretion of the program or
relying party (who has been made aware of the termination). In this case, provision must
be made for compromise recovery, audit, archive, and data recovery material, either by
transferring the current agreements to the new CA, or by the program otherwise
upholding the current contractual agreements or making new arrangements.
The Government will communicate the revocation of the CA’s certificate to relying
parties in a manner to ensure maximum dissemination of the revocation notice.
4.9.3
Private Key Is Compromised (Key Compromise Plan)
As required by the ACES contract, ORC has in place an appropriate key compromise
plan that addresses the procedures that are followed in the event of a compromise of the
private signing key to issue certificates. This plan includes procedures for revoking all
affected ACES Certificates and promptly notifying all subscribers and all Qualified
Relying Parties.
In the case of an ORC ACES CA key compromise, the U.S. Government shall
communicate the revocation of the ORC ACES certificate to relying parties.
Subsequently, the CA installation shall be re-established as described in ORC ACES
Installation Manual. The ORC ACES CA shall subsequently be re-keyed. The
outstanding certificates will be re-issued using the new CA keys.
In case of an ORC CSA key compromise, the ORC CA that issued the CSA a certificate
shall revoke that CSA’s certificate, and the revocation information shall be published
immediately in the most expedient manner. The ORC CSA is subsequently re-keyed.
The ORC CSA does not use self-signed certificates.
106764133
72
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
4.9.4
Facility after a Natural or Other Disaster (Disaster Recovery Plan)
ORC maintains a Disaster Recovery Plan (DRP) as part of the SSP. The DRP is based
upon a combination warm site/hot site located in ORC’s backup Secure Network
Operations Center (SNOC). The ORC DRP comes into effect only if an outage of more
than 24 hours is anticipated. Since the ORC ACES CA servers operate with backup
generator power and telecommunications, long outages are unlikely.
In the event of an extended outage, a second suite of equipment will be brought on line to
provide temporary ORC ACES CA services. Backup tapes from the primary CA
server(s) will be used to synchronize the temporary CA(s).
In the case of a disaster in which CA equipment is damaged and inoperative, CA
operations are reestablished as quickly as possible, giving priority to the ability to revoke
subscriber’s certificates. If a CA cannot reestablish revocation capabilities prior to the
next update field in the latest CRL issued by the CA, then ORC will report to the Policy
Authority. The Policy Authority shall decide whether to declare the CA private signing
key as compromised and reestablish the CA keys and certificates, or allow additional
time for reestablishment of the CA’s revocation capability.
In the unlikely case of a disaster whereby CA installation, off-site backup storage and
secondary warm site is physically damaged and all copies of the CA signature key are
destroyed as a result, ORC shall revoke the CA signature key via the off-line self signed
root and publish the CRL in a timely fashion. The CA installation shall then be
completely rebuilt, by reestablishing the CA equipment, generating new private and
public keys and being re-certified. Finally, all subscriber certificates shall be re-issued.
In such events, Relying Parties continue to use certificates signed with the destroyed
private key at their own risk.
The ORC ACES directory operates in a replicated configuration that is two or more
platforms located at different sites that contain replicas of the directory information. In
the event one fails, users are still be able to obtain necessary information from the second
directory server through a load balancer.
4.10 Authorized CA Cessation of Services
In the event that ORC ceases operation of its participation as an Authorized CA in ACES
or is otherwise terminated:
106764133

All subscribers, Sponsoring Organizations, and Qualified Relying Parties must be
promptly notified of the cessation, via the ACES website.

All ACES Certificates issued by ORC under this CPS shall be revoked no later than
the time of cessation

All current and archived ACES identity proofing, certificate, validation,
revocation/suspension, renewal, policy and practices, billing, and audit data shall be
transferred to GSA within 24 hours of cessation and in accordance with this CPS.
Transferred data shall not include any non-ACES data
73
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
4.11 Customer Service Center
As described in the ACES Contract, ORC has implemented and maintains an ACES
customer service center to provide assistance and services to subscribers and Qualified
Relying Parties. The customer service center is the focal point for receiving, recording,
addressing, and reporting any issues regarding to the operation and maintenance of the
ORC ACES PKI. The customer service center provides resources via the ORC ACES
website (http://aces.orc.com), via e-mail and via phone (listed on the website). Support
is available to subscribers, ORC employees and subcontractors, and the Government.
All incidents reported to the customer service center are tracked. Issues that have not
been resolved in a timely manner are elevated to ensure prompt and professional
response. Capabilities provided by the center include:
106764133

Emergency response available 24/7/365

Prompt acknowledgement of problem receipt

Online ability to check status of certificate requests via request identifier

Immediate revocation of certificates when validated with proof of possession test on
private key

End user instructions and technical documentation

Professionally staffed center from 7:30 am – 6:00 pm eastern time, with on-call
support at all other times

Direct link to engineering staff for escalation and resolution of technical issues

The ORC ACES customer service center maintains records related to customer
requests for service, including:

Date and time initially contacted

Method of contact (e.g., telephone, e-mail, etc.)

Name of individual making the contact, individual agency application (if applicable)

Type of service requested or problem reported

Action taken

Date and time action completed

Name of person taking the action

Requirements for follow-up action (if any)

Date/time report filed

Name of person filing report
74
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
5
Physical, Procedural And Personnel Security
Controls
5.1 Physical Security Controls
ORC’s CA equipment is dedicated to the CA function. IA workstations and IA hardware
tokens are dedicated to the use of issuing certificates. RAs and LRAs use generalpurpose workstations and medium hardware assurance certificates dedicated to the
ACES certificate application process.
The CA, IA and CSA equipment consists of equipment dedicated to the CA, IA and CSA
functions, and do not perform non-related functions. The equipment includes, but is not
limited to, the system running the CA, IA and CSA software, hardware cryptographic
modules, and databases and directories located on the equipment. In addition, databases
and directories located on the equipment are not accessible to the subscribers and
Relying Parties.
Unauthorized use of CA, IA and CSA equipment is forbidden. Physical security controls
are implemented that protect the hardware and software from unauthorized use.
Cryptographic modules are protected against theft, loss, and unauthorized use through
multiple party management.
A check is made at least once every 24 hours to ensure that no attempts to defeat the
physical security mechanisms have been made.
5.1.1
Physical Access Controls
Physical access to CA, IA and CSA hardware, including the firewall server, and any
external cryptographic hardware tokens, is limited to those personnel performing one of
the roles identified in Section 5.2. Access to any media containing CA, IA or CSA
information is also physically protected and access restricted to authorized personnel.
Such information includes:

Certificate database and database backups

ORC ACES CA private keys and private key backups

Audit logs

Archives
Note: Access restrictions do not necessarily apply to copies of audit log information or
archive information made in response to authorized requests.
There are three roles that have privileged access to CA, IA and CSA equipment, the
CAA, SA and the IA. The CAA requires the presence and participation of the SA to
upgrade, stand down or stand up the CA or an IA workstation. The CAA and IA do not
106764133
75
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
have access at the root level of the operating systems and the SA does not have physical
access to the CA. The SA must have either the Corporate Security Auditor or CAA
present for audit log handling operations.
Access to computer facilities is restricted to authorized personnel only. All unknown or
unidentified persons are accompanied or challenged by personnel to prevent
unauthorized access to IT resources and/or disclosure of sensitive data. Only authorized
users have access to IT resources. Non-cleared maintenance and cleaning personnel are
escorted at all times while in central computer rooms and facilities.
ORC employs five levels of physical access control and two separate physical access
alarm systems:
Level 1 – ORC facilities are located in two buildings each employing securityguarded entrances during normal working hours and 24-hour security patrolling the
premises after hours and on weekends. Proximity card access is required after hours
for building and elevator access. Cameras are located at all entry points.
Level 2 – ORC proximity cards, issued to all employees requiring access to ORC
general access areas, activate the card reader at the suite doors. Cameras are located
at all entry points.
Level 3 – ORC personnel who have successfully completed the required screening
process validating a routine requirement to work in the operations center are granted
access controlled by ORC Proximity card readers programmed for this level.
Level 4 – ORC personnel who have successfully completed the required screening
process validating a routine requirement to work in this level and have met the
appropriate “clearance” requirements are granted access to this level controlled by
ORC proximity readers programmed for this level. All personnel must present their
proximity card to enter and leave this level. (Note: Level 3 and 4 are combined in
ORC’s backup facility since daily operations are not performed.)
Level 5 – ORC personnel who have successfully completed the required screening
process, are authorized to work on CA, CSA, or Key Recovery equipment, and have
met the appropriate “clearance” requirements are granted access to this controlled
area via combination lock programmed for this level. All personnel must log when
they enter and leave this level.
A GSA-approved five-drawer security container (Mosler Safe), located at each ORC
facility, provides physical protection of key and key activation data related to the three
privileged access roles (CAA, SA and Corporate Security Auditor). At least two parties
are necessary to do any key management or audit log operations. Separation of
activation-mechanism components is protected in separate safe draws accessible only to
personnel in each role.
All hardware cryptographic modules are stored in the GSA-approved security container
when not in use. Activation information used to access or enable the CA is stored in a
separate series of Mosler Safe drawers, separately from the CA. Each drawer has a
separate combination lock.
106764133
76
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
5.1.2
Security Checks
A security check of the facility housing CA, IA and CSA equipment is made at the end of
each workday. The check ensures that:

The equipment is in a state appropriate to the current mode of operation (e.g., that
cryptographic modules and removable hard disks are in place when in use, and
secured when not in use)

Security containers are properly secured, including the file cabinet storing sensitive
data and the safe containing backup material

Physical security systems including door locks are functioning properly

The area is secured against unauthorized access
An individual is assigned explicit responsibility for making these checks once a day.
This individual also ensures that the CA sign-out sheet is available and complete. A
record is kept that describes the type of checks performed, the time, the date, and the
person who performed them.
Note: ORC’s facility is continually alarmed and guarded.
5.1.3
Media Storage
ORC ensures that media is stored so as to protect it from accidental damage (water, fire,
electromagnetic). Backup tapes re stored at the same level of security as the computer
from which they were made. Weekly and monthly backup tapes and monthly archive
media are stored either on-site in a safe of fireproof cabinet or off-site in a safe deposit
box. Tapes and other media remain off-site until such time as they are to be reused or
additional data is to be appended.
5.1.4
5.1.4.1
Environmental Security
Power and Air Conditioning (Environmental Controls)
The ORC facilities have adequate power and backup power resources to provide
unlimited uptime to the Internet through a central UPS and backup diesel generator
power system, which also powers an independent air conditioner during a power disaster.
The power requirement covers any and all equipment required for the ORC ACES
system to provide all functionality indefinitely or to provide for a normal shutdown.
A separate air conditioning unit is used as required to maintain the operating
environment within normal operating temperatures (70 degrees Fahrenheit +/- 5) for the
equipment and personnel operating and administering the ORC ACES system. The
system is set so that at no time can the lack of air conditioning be able to damage the
equipment and cryptographic tokens.
106764133
77
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
5.1.4.2
Water Exposures
The ORC facility is located above ground and off of the floor by two feet to prevent
internal flooding from damaging this CA, IA and CSA equipment. All backup materials
and CA, IA and CSA documentation storage devices are located in areas not prone to
water damage.
5.1.4.3
Fire Prevention and Protection
The ORC facility complies with all applicable national, state, and local fire regulations
for a commercial office building. Fire prevention devices are enabled to eliminate or
reduce fire and smoke damage to the CA, IA and CSA equipment. Backup materials and
documentation are located in fire resistant storage devices to reduce or eliminate damage
to such materials.
5.1.4.4
Waste Disposal
Any media that contains privacy act or other sensitive information is crosscut shredded
or overwritten to be rendered unrecoverable prior to disposal.
5.1.5
Off-site Backup
Backup media for critical data and programs are stored in a secure, off-site location.
Backup media is rotated to ensure that the information contained is no more than one
week old. The SSP details tape rotation schedule and archive schedule for the CA, IA
and CSA. The backup is stored at a site with physical and procedural controls
commensurate to that of the operational system.
5.2 Procedural Controls
The ACES system is controlled in accordance with National Institute of Standards and
Technology (NIST), DoD, GSA, Association for Independent Certified Public
Accountants (AICPA), and National Security Agency (NSA) guidelines for certification
authority operations.
5.2.1
Trusted Roles
A trusted role is one whose incumbent performs functions that can introduce security
problems if not carried out properly, whether accidentally or maliciously. The people
selected to fill these roles have proven to be diligent and trustworthy as described in the
next section. The functions performed in these roles form the basis of trust in the entire
PKI. ORC uses two approaches to increase the likelihood that these roles can be
successfully carried out. The first approach is to ensure that the persons filling the roles
are trustworthy and properly trained. The second is to distribute the functions of the role
among several people, so that any malicious activity requires collusion. Details
regarding the design and configuration of the technology to avoid mistakes and counter
inappropriate behavior are described in Section 6.
106764133
78
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
The trusted roles are the CAA, the SA, IA, and the Certificate Status Authority
Administrator. Multiple trusted individuals are employed in a separation of
responsibilities. However, the CAA and Certificate Status Authority Administrator roles
are combined in one role for ORC. For the purposes of this document the
CAA/Certificate Status Authority Administrator roles are designated as CAA.
ORC maintains lists, including names, organizations, and contact information, of those
company individuals who act in trusted roles, and makes them available during
compliance audits.
5.2.1.1
CA Trusted Roles (Physical Security in CP)
To ensure that one person acting alone cannot circumvent safeguards, CA
responsibilities are shared between multiple roles and individuals. Access permissions
on the CA server are limited to capabilities required by the role.
There are three trusted roles relating to operation of the CA: the CAA, the SA, and the
Corporate Security Auditor. The Corporate Security Auditor examines system records or
audit logs to ensure that other persons are acting within the realms of their
responsibilities and within the stated security policy. Multiple individuals perform these
trusted roles.
The CAA and SA have administrative responsibility for the CA. Both roles are required
to stand down or stand up the CA. The CAA does not have access at the root level of the
operating system and the SA does not have the CA passwords. All certificates asserting
an ACES CP issued by ORC are issued by the ORC ACES PKI facility operating under
the control of ORC.
5.2.1.1.1
Certificate Authority Administrator (CAA)
Any ORC CAA who operates a CA that asserts a certificate policy OID defined in this
document is subject to the stipulations of this CPS. The ORC CAA(s) names are logged
and made available during compliance audits. CAA responsibilities ensure that the
following functions occur according to the stipulations of this policy:

Certificate generation and revocation of IA certificates

Approval of IA/RA certification (in writing)

Generation, distribution, and management of CRLs

CA re-keying, including key pair generation

Administrative functions associated with maintaining the CA database

Assisting in compromise investigations

Compromise reporting

Hardware cryptographic module programming and management
5.2.1.1.2
106764133
Systems Administrator (SA)
79
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
The SA is primarily responsible for administration of the CA, IA, and CSA host
computers and operating systems, including:

Initial configuration of the CA, IA and CSA server(s) system(s) including secure
boot start-up and shut down of the workstation

Initial setup of all new accounts

Initial network configuration setup

Creation of emergency system restart media to recover from catastrophic system loss

Performing system backups

Secure storage and distribution of backups and configurations to an off-site location

Holding keying material (not holding any keying material activation data)

Software upgrades

System recovery from backup media

Performing any required changes to the host name network address and

Archive and delete functions
5.2.1.1.3
Corporate Security Auditor
The ORC Corporate Security Auditor is a distinct individual who is not in the direct
reporting chain of the Information Technology or Operations departments and does not
perform any additional trusted roles. The Corporate Security Auditor is responsible for
backing up and archiving all audit data and reviewing the audit logs recorded by the CA,
IA and CSA. The Corporate Security Auditor reviews the logs for events such as the
following:

Repeated failed actions

Requests for privileged information

Attempted access of system files or databases

Receipt of improper messages

Suspicious modifications
The Corporate Security Auditor is also responsible for analyzing the certificate requests
to determine patterns of abuse.
5.2.1.1.4
Issuing Authority (IA)
IAs, at the discretion of the CAA, can assume the responsibility of issuing and revoking
certificates. IA responsibilities include:
106764133

Issuing certificates that have been properly validated (including CAA approval as
applicable)

Revoking certificates with properly validated revocation requests
80
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Validating the credentials of RAs

RA Training

Posting certificates
5.2.1.2
5.2.1.2.1
Other Trusted Roles
Registration Authority (RA) /Local Registration Authority (LRA)
ORC RAs and LRAs are designated trusted agents of ORC. The difference between RAs
and LRAs is that RA identity proofing and training are the responsibility of the IA, and
LRAs perform identity proofing only. RAs can designate LRAs and are responsible for
their identity proofing and training. LRAs may not designate other LRAs. RAs are
responsible for:

Authentication of user identity and organizational relationship upon notification of
certificate request

Processing and archiving notarized identity validation packages submitted by
applicants

Submittal of digitally signed validation approval to IA or CAA

Authentication of user identity upon revocation request

Submittal of digitally signed revocation requests to IA

Archival of user authentication information

Generation of certificate and revocation requests and processing of associated
responses
LRAs are responsible for:

Authentication of user identity and organizational relationship upon notification of
certificate request

Authentication of user identity upon revocation request
RAs and LRAs do not have privileged access to the CA.
5.2.1.2.2
Network/ Firewall Administrator
A Network/ Firewall Administrator is responsible for integrity, confidentiality and
availability of internal and external communications with the CA, in accordance with the
requirements of the CAA, and for the installation and operation of the CA firewall, in
accordance with the requirements of the CAA..
A Administrators are responsible
5.2.1.2.3
106764133
Certificate Status Authority (CSA)
81
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
The ORC CSA operating under this CPS is subject to the stipulations of this policy, and
of the GSA-approved CPS under which it operates. The CSA provides OCSP responses
to subscribers and is responsible for:

Providing certificate revocation status and/or complete certification path validation
(including revocation checking) to the Relying Parties upon request

Ensuring that the status and validation responses contain authentication and integrity
services commensurate with the assurance level of the certificate being checked

The CAA administers the CSA
5.2.1.2.4
PKI Sponsor
A PKI Sponsor fills the role of a subscriber for non-human system components and
organizations that are named as public key certificate subjects. The PKI Sponsor works
with the CAA, IA, and RA to register components (routers, firewalls, etc.) in accordance
with this CPS, and is responsible for meeting the obligations of subscribers as defined
throughout this document.
5.2.2
Number of Persons Required Per Task (Separation of Roles)
ORC implements commercially reasonable practices that ensure that one person acting
alone cannot circumvent safeguards. To increase the likelihood that these roles can be
successfully carried out the functions are distributed among more than one person, so
that any malicious activity would require collusion. Trusted roles include:
Administrators (ORC CAA) – authorized to install, configure, and maintain
the CMA software to include: the establishment and maintenance of privileged
user accounts, configuration of profiles and audit parameters, and generation of
component keys.
Officers (ORC IA) – authorized to request or approve certificates or certificate
revocations.
Auditors (ORC Corporate Security Auditor) – authorized to view and
maintain audit logs.
Operators (ORC SA) – authorized to install, configure, and maintain the CMA
hardware and operating systems to include: the establishment and maintenance
of privileged user accounts; configuration of profiles and audit parameters and
system archival, backup, and recovery.
Under no circumstances shall the incumbent of these roles perform their own auditing
function. No individual is assigned more than one trusted role.
There are three roles that have privileged access to the CA: the CAA, SA and IA. The
CAA requires the presence and participation of the SA to stand down or stand up the CA
and CSA. The CAA does not have access at the root level of the operating system and
the SA does not have the CA or CSA passwords. The SA must have either the Corporate
Security Auditor or CAA present for audit log handling operations. Corporate Security
106764133
82
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Auditors are not in any way under the control of CAAs, SAs and IAs. Nor are CAAs,
SAs and IAs under the control of Corporate Security Auditors. Under no circumstances
shall the incumbent of a CMA role perform its own compliance or security auditor
functions.
At least two parties are necessary to do any key management or log operations. CA/
CSA key-pair generation and initialization of CA/CSA tokens require the active
participation of at least a CAA and the SA or the Corporate Security Auditor. Startup of
the CA/ CSA systems require the active participation of a CAA and a SA. The
individual operator’s roles and responsibilities including separation of roles are detailed
in the “ORC PKI Roles Manual”. An IA, RA or LRA is not permitted to perform any
CAA, SA, or Corporate Security Auditor functions, or any compliance audit role.
5.2.3
Identification and Authentication for Each Role
All persons fulfilling one of the CMA roles defined in this CPS shall be capable of
identifying themselves to others with two forms of picture identification.
5.2.4
Hardware/Software Maintenance Controls
Areas of control include system software controls in accordance with Federal laws,
regulations, and guidelines and GSA security policy and supporting security guidelines.
The ORC CA equipment is hosted on evaluated platforms in support of computer
security assurance requirements, and the system (hardware, software, operating system)
is, when possible, operated in an evaluated configuration. At a minimum, the ORC CA
platform uses the same version of the computer operating system as that which was used
when it received the evaluation rating.
5.2.5
Documentation
Operations and maintenance documentation issupplied to authorized individuals
performing the roles of CAA and SA. An operations manual for CAAs and an
operations manual for SAs has been written and is managed for each logical instance of
the CMA and each physical instance of the CMA.
Documentation is provided to other personnel as required for fulfilling the requirements
of the role.
5.2.6
Security Awareness Training
All personnel, and contractors located or working on-site or accessing U.S. Government
IT resources, receive information systems security awareness training annually.
Additionally, periodic refresher training is provided to all personnel. The training
program covers the requirements of the Computer Security Act of 1987, Public Law 100235, which are adequately detailed in the Office of Personnel Management Computer
Security Awareness Training materials. The Security Auditor is responsible for
managing this training.
106764133
83
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Individuals responsible for administering the ORC ACES system, including CAAs, SAs,
IAs and Security Auditors, receive training. Reading requirements include the ACES
CP, this CPS, ORC Roles Manual, ORC ACES Installation Manual, ORC PKI
Operator’s Manual and ORC PKI Operational Test and Evaluation Test Plan and
Procedures. In accordance with ORC’s established training plan, training completed by
the above personnel is documented. The following training is conducted for all
individuals administering the ORC ACES system:

Training relative to the Privacy Act of 1974, information security, physical security,
personnel security, and operations security

Training relative to the activity’s particular information technology resources,
including operating systems analysis, hardware architecture, computer performance
evaluation, and network concepts and operations

Training relative to the stipulations of the ORC PKI system Guidelines and this CPS

National Industrial Security Program Awareness
Training in the following areas is required for CAA:

Training on administering CMA application software
Training in the following areas is required for SA:

Systems security training for the appropriate CMA platforms

Firewall administration training on the proper operations of the dedicated firewall
protecting the CA and CSA
Training in the following areas is required for IA:

Security awareness and proper protection for cryptographic devices

Training on IA responsibilities
Training in the following areas is required for RA and LRA:

Security awareness and proper protection for cryptographic devices

Training on RA/LRA respective responsibilities
5.2.7
Retraining Frequency and Requirements
Those involved in filling trusted roles are made aware of changes in the ORC ACES
operation. Any significant changes to the operation require retraining. ORC maintains a
file of signed and dated statements from the ACES personnel listing their names, roles,
re-training received, and date training completed. The ORC PKI Project Director
established a training plan and training completed by the above personnel is documented.
5.2.8
Job Rotation Frequency and Sequence
ORC ensures the continuity and integrity of the ORC ACES services.
106764133
84
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
5.2.9
Sanctions for Unauthorized Actions
Any unauthorized actions resulting in irreparable damage to the ACES system such as
compromising the private key shall be prosecuted to the fullest extent of the law. The
responsible individuals may be prosecuted to the maximum of extent that the law affords,
both criminal and civil.
Any unauthorized actions by an IA shall result in the immediate revocation of the IA
certificate and the removal of that individual from the IA role. Certificates issued by that
IA might also be revoked. The IA may be prosecuted for any damages caused to the
ORC ACES system.
Any unauthorized actions by an RA or LRA shall result in the immediate revocation of
the RA/ LRA certificate and the removal of that individual from the RA/ LRA role.
Certificates validated by that RA/ LRA might also be revoked. The RA/ LRA may be
prosecuted for any damages caused to the ORC ACES system.
5.2.10 Contracting Personnel Requirements
Any company subcontracting to provide services for any CMA role with regards to the
ORC ACES system is required to establish procedures, which is reviewed and approved
by ORC. The subcontractor shall require all employees delivering such services to be in
accordance with this CPS and the ACES CP, and subject to the compliance audit
requirements of this CPS.
5.2.11 Documentation Supplied to Personnel
Operations and maintenance documentation is supplied to authorized individuals
performing the roles of CAA and SA. An Operations Manual for CAA and an
Operations Manual for Systems Administration are written and managed for each logical
instance of the ORC ACES system and each physical instance of an ORC ACES system.
Documentation shall be provided to other personnel as required for fulfilling the
requirements of each role.
5.3 Personnel Security Controls
5.3.1
Access Authorization
The persons filling CMA roles are trustworthy, and of the highest integrity from a
financial perspective and selected on the basis of Loyalty to the United States of
America. The Board of Directors of Operational Research Consultants, Inc, administers
ORC ACES PKI operations. Personnel appointed to operate CMA equipment shall:
106764133

Have not knowingly been denied a security clearance, or had a security clearance
revoked

Have not been convicted of a felony offense
85
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Be appointed in writing by an approving authority or be party to a contract for PKI
services
5.3.2
5.3.2.1
Limited Access
Background Screening, Qualifications, Experience and Clearance
Requirements
All personnel performing of the roles identified in Section 5.2.1 are required to have a
personal security investigation that has been favorably adjudicated and be assigned to
sensitive positions. An active secret clearance shall be sufficient to meet this
requirement. For individuals who do not have an active clearance, ORC requests the
individual to provide references and sign a background verification disclosure and
authorization and release. As a member of the American Society of Industrial Security
(ASIS), ORC can access ASIS Online to complete Criminal History, Civil History,
Financial Status and Work History background checks. If additional detailed
investigation is required, ORC uses the Pinkerton Services Group (or equivalent) to
provide background checks covering the past seven years including: Criminal History,
Civil History, Financial Status and Work History.
ORC CAAs, IAs, SAs, and Security Auditors shall:

Be of unquestionable loyalty, trustworthiness, and integrity

Have demonstrated security consciousness and awareness in all daily activities

Have a strong background in information technology resource administration and
technical administration in either computer operations, system software, and/or
application software totaling 12 months

Not be assigned other duties that would interfere with their CAA, IA or SA duties
and responsibilities

Not knowingly have been previously relieved of a past assignment for reasons of
negligence or non-performance of duties

Be a U.S. citizens

Have demonstrated financial stability

Have valid personal security investigations favorably adjudicated and be assigned to
sensitive positions

Have received proper training in the performance of roles and duties. RAs and
LRAs are trained in the verification policies and practices of this CPS and are trained
in the performance of RA and LRA duties, respectively
In addition, CAAs and IAs have a technical understanding of the CA system and the
responsibilities of the IA within that system.
CAAs, IAs, SAs, and Security Auditors shall go through a thorough background check
performed by a qualified investigator, including, but not limited to:

106764133
Criminal history check that shows no misdemeanor or felony convictions
86
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

Civil lawsuit history checks and a social security number trace to confirm valid
number

Personal, financial, and work/job reference checks which show that the subject of the
check is competent, reliable and trustworthy

Financial status check showing that the subject of the check has not committed any
fraud or is other wise financially trustworthy

Education verification of highest or most relevant degree

DMV records shall demonstrate no pattern of violations

A residence check to demonstrate that the person is a trustworthy neighbor
An active secret clearance is sufficient to meet this requirement. The results of these
checks will not be released except as required by the ACES CP.
5.3.2.2
Least Privilege
Users must be restricted to data files, processing capability, or peripherals, and type of
access (read, write, execute, delete) to the minimum necessary for the efficient
completion of their job responsibilities. ORC provides physical access controls designed
to provide least privilege as stipulated in Section 5.1.1.
5.3.2.3
Separation of Duties
Critical functions are divided among individuals (separation of duties) to ensure that no
individual has all necessary authority or information access which could result in
fraudulent activity without collusion as stipulated in Section 5.2.2.
5.3.2.4
Individual Accountability
ORC provides physical access controls designed to provide individual accountability.
Individual accountability requires the linking of activities on the ORC ACES system to
specific individuals, and therefore, requires the system to internally maintain the identity
of all active users. ORC allows only one user per account and users never share user IDs
or passwords. Section 5.2 describes how the access control mechanism supports
individual accountability and audit trails.
106764133
87
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
6
Technical Security Controls
ORC and all authorized ORC IAs, RAs, CMAs, and Repositories, implements
appropriate technical security controls in accordance with protection under 15 U.S.C.
278g(3) and (4), the responding regulations relating to protection of these systems as set
forth in Appendix III (Security of Federal Automated Information Resources) to Office
of Management and Budget (OMB) Circular Number A-130 (Management of Federal
Information Resources), and the GSA ACES Contract.
6.1 Key Pair Generation and Installation
6.1.1
Key Pair Generation
Users generate the key pair as stipulated in Section 4.2.1. This is accomplished in a FIPS
140-1/2 Level 1 Approved Web browser (such as Netscape Communicator) for medium
assurance certificates or in a FIPS 140-1 Level 2 validated hardware token for medium
hardware assurance certificates. ORC’s CA certificate-signing keys are generated in
FIPS 140-1/2 Level 3 validated cryptographic Hardware Security Modules (HSM). The
CSA OCSP responder certificate signing keys are generated in a FIPS 140-1/2 Level 2
validated cryptographic HSM.
IA, RA, LRA, medium assurance hardware and Code Signing keys are generated on
cryptographic smart cards. ORC uses smart cards from a vendor(s) with certified FIPS
140-1/2 Level 2 compliance.
Subscribers may use software for medium assurance or hardware tokens for medium
assurance hardware, for key generation. In the case of medium hardware assurance
encryption key pairs generated off the token, ORC assures that no copies other than
authorized key escrow copies of the keys continue to exist after the generation and
insertion process has completed in accordance with the ORC KRPS. Medium hardware
assurance signature key pairs are be generated on the token, in the presence of an ORC
ACES RA or LRA.
For all key generation, random numbers are generated using a FIPS approved method.
A private key will never appear outside of the module in which it was generated in plain
text form.
6.1.2
Private Key Delivery to Entity
The ORC ACES subscriber’s private key is generated directly on the subscriber’s token,
or in a key generator that benignly transfers the key to the subscriber’s token. The
subscriber is in possession and control of the private key from the time of generation or
benign transfer.
106764133
88
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
6.1.3
Subscriber Public Key Delivery to Authorized CA (Certificate Issuer)
As part of the ACES Certificate application process, the subscriber’s public key is
transferred to the ORC ACES CAs in a way that ensures:

It has not been changed during transit

The sender possesses the private key that corresponds to the transferred public key

The sender of the public key is the legitimate user claimed in the certificate
application
Public keys are delivered to the certificate issuer in a PKCS#10 or Certificate Request
Message Format (CRMF) certificate request.
6.1.4
ORC ACES CA Public Key Delivery to Users
ORC delivers ORC ACES CA public keys via a web interface to a protected server using
SSL. The public key is stored such that it is unalterable and not subject to substitution.
Relying Parties must contact the help desk to receive the official certificate hashes to
compare them with the certificates downloaded from the site.
6.1.5
Key Sizes
All Rivest, Shamir, Adleman (RSA) keys currently use a 1024 bit modulus. Digital
Signature Standard (DSS) and Elliptic Curve are not supported. Certificates and CRLs
use signature keys of at least 2048 bits, in accordance with the requirements and
schedule stipulated in Section 6.1.5 of the X.509 Certificate Policy for the U.S. Federal
PKI Common Policy Framework, version 1.4, dated December 21, 2003.
For SSL ORC employs, at a minimum, three key triple-Data Encryption Standard (tripleDES) (or equivalent) for the symmetric key algorithm.
6.1.6
Public Key Parameters Generation
Public key parameters for use with the RSA algorithm defined in PKCS-1 are generated
and checked in accordance with PKCS-1.
6.1.7
Parameter Quality Checking
See Section 6.1.6 above.
6.1.8
Key Usage Purposes (X.509 V3 Key Usage Field)
ORC certifies keys for use in signing or encrypting, but not both. The use of a specific
key is determined by the key usage extension. The key usage extension isincluded in all
certificates and is always marked critical in order to limit the use of public key certificate
for its intended purpose.
106764133
89
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
6.1.9
Private Key Shared by Multiple Subscribers
ORC does not approve of any Private Key Shared by Multiple subscribers. Public keys
that are bound into subscriber certificates are used only for signing or encrypting, but not
both. Certificates issued for digital signatures (including authentication) assert the
digitalSignature and/or nonRepudiation bits. Certificates issued for key transport assert
the keyEncipherment bit.
6.1.10 Date/Time stamping
ORC ACES date/time stamps conform to the ITU-T Recommendation X.690 and the
X.690 v2, Information Technology – ASN.1 Encoding Rules, 1994.
6.2 Private Key Protection
An ORC CA signing private key never appears outside of the module in which it was
generated in plain text form.
6.2.1
Standards for Cryptographic Modules
The relevant standard for cryptographic modules is Security Requirements for
Cryptographic Modules [current version of FIPS140]. Cryptographic modules are
validated to the FIPS 140 Level identified in this section.
Subscribers shall use cryptographic modules that have been validated to meet at least the
criteria specified for FIPS 140 Level 1. FIPS 140 Level 2 must be used to receive a
Medium Hardware Assurance certificate.
All ORC CA certificates are signed using a hardware cryptographic module that has been
validated to meet FIPS 140 Level 3. The ORC CA private keys are protected by a
hardware cryptographic module that meets the criteria specified at FIPS 140-1/2 Level 3
for key storage, as listed on the NIST website.
CAA, IA, RA and LRA private keys (for identity and encryption certificates) are
protected by cryptographic hardware tokens that meet the criteria specified at FIPS 1401/2 Level 2, as listed on the NIST website.
All cryptographic modules are operated such that the private asymmetric cryptographic
keys are never being output in plaintext. No private key shall appear unencrypted
outside the ORC CA, IA or CSA equipment.
No one shall have access to a private signing key but the subscriber. Any private
encryption keys held by ORC are held in strictest confidence and controlled as described
in the ORC Key Recovery Practice Statement (KRPS). The ORC Key Recovery System
only employs cryptographic modules validated to the FIPS 140-1/2, as identified in this
section.
Section 6.1.1 stipulates cryptographic module requirements for key generation.
106764133
90
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
6.2.2
Private Key Backup
ORC recommends to users that they make backup copies of software based encryption
private keys and provides recommended procedures on the ACES website. Backup of
private signature keys for the sole purpose of key recovery shall not be made. Backup
copies are stored in an encrypted form and protected by a password from unauthorized
access. The subscriber (PKI Sponsor for Component) is responsible for ensuring that all
copies of private keys, including those that might be embedded in component backups,
are protected, including protecting any workstation on which any of its private keys
reside.
ORC may back up the CA private key on a separate cryptographic module in order to
alleviate the need to re-key in the case of cryptographic module failure. The backup
module is an HSM that meets FIPS 140 Level 3 requirements in general and Level 3 key
management requirements and under the protection of the CAA and the SA under lock
and key at all times, in accordance with Section 6.4.2. When ORC re-keys, the private
key in the backup module are zeroed or otherwise destroyed.
Subscribers are permitted to backup their own private keys.
6.2.3
Private Key Archival
Under no circumstances is a non-repudiation signature key archived. Archival of
confidentiality keys is recommended if any information encrypted with those keys is
archived in its encrypted state.
Escrowed keys are stored in a protected KED, in accordance with the ORC KRPS. The
KED consists of equipment dedicated to the key recovery and archival functions.
6.2.4
Private Key Entry Into Cryptographic Module
Private keys are generated by and in a cryptographic module. For the CA and CSA, the
cryptographic module must be a FIPS 140-1/2 Level 3 module. For IA/ RA/ LRA/
subscriber medium hardware assurance, the cryptographic module must be a FIPS 1401/2 Level 2 module. For subscriber medium assurance, the cryptographic module must
be a FIPS 140-1/2 Level 1 module.
In the event that a private key is to be transported from one cryptographic module to
another, the private key will be encrypted during transport using FIPS 140-1/2 protection
for the private key at the level commensurate with the level of the key to be transported;
private keys must never exist in plaintext form outside the cryptographic module
boundary, in accordance with the ORC KRPS.
IA, RA, and LRA identity certificate private keys are never transported. IA, RA, and
LRA key pairs for encryption certificates are generated, escrowed and stored (in the
same cryptographic module).
If a user, via a software process, generates the key, and the key will be stored by and
used by the application that generated it, no further action is required. Otherwise, the
106764133
91
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
key is extracted for use by other applications or in other locations (key extraction for use
by other applications is restricted to keys used with medium assurance certificates). Use
of a protected data structure (such as defined in [Public Key Certificate Standard,
PKCS#12]) is required. The resulting file may be kept on a magnetic medium.
6.2.5
Method of Activating Private Key
A password shall be used to activate the private key for IA, RA, LRA, subscriber
medium assurance and medium hardware assurance. Passwords shall be generated by
the subscriber and entered at the time of key generation (at the RA/LRA workstation in
the case of medium hardware assurance) and managed according to the FIPS 140-1/2
guidance for strong passwords in accordance with the subscriber obligation agreement.
Entry of activation data will be protected from disclosure. The strength of the passwords
and the controls used to limit guessing attacks shall have a probability of success of less
than 2-23 chance (1 chance in 8,338,608) of success over the life of the password. ORC
uses the NIST E-Authentication Token Strength Module (TSM) to calculate resistance to
online guessing. The strength of password shall be 8 characters with the following
diversity: one upper case alpha, one lower case alpha, one numeric, and one special.
The CA and CSA is activated by a hardware token activated by a password. ORC
ensures that generation, change, and management of private key activation data are in
accordance with FIPS 140-1/2. CA and CSA keys are generated and managed directly
on the hardware encryption module, stipulated in Section 6.2.1. The CA and CSA
hardware encryption modules activation mechanism is under two party controls, as
stipulated in the ORC PKI Roles Manual. The hardware encryption module activation
mechanism employed by ORC uses ‘k of m’ for administrator and operator cards,
whereby each card set includes ‘m’ number of cards and ‘k’ number of cards are required
for administration or operation actions (where ‘m’ must be an integer greater than 1 and
‘k’ must be an integer less than or equal to ‘m’). The hardware encryption module
requires that one card (representing the ‘k’) is required to an operation, where the SA
controls and protects the card and the CAA controls and protects the password. For
activation, the SA removes the appropriate card from the SA safe drawer and the CAA
supplies the card password. Key issuance can only occur once the module is activated
under this two party control.
6.2.6
Method of Deactivating Private Key
Cryptographic modules that have been activated shall not be left unattended or otherwise
active to unauthorized access. Private keys stored in hardware tokens, excluding end
user tokens, shall be removed from the token reader and stored in a locked container
when not in use. End users will protect there token in accordance with the subscriber
obligation agreement. The CA hardware token shall be stored in a locked container
when not in use.
Private keys stored in software shall be deactivated via a logout procedure. End entities
will be advised to also implement a time-out procedure for automatically deactivating
private keys after a period of 15 minutes of non-use.
106764133
92
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
6.2.7
Method of Destroying Private Key
Private keys shall be destroyed when they are no longer needed, or when the certificates
to which they correspond expire or are revoked. For software cryptographic modules, is
accomplished by overwriting the data. For hardware cryptographic modules, this is
accomplished by executing a “zero” command. Physical destruction of hardware should
not be required. Destruction of the private key is then documented via signed email, as
stipulated in Section 4.4.3.
6.3 Good Practices Regarding Key Pair Management
6.3.1
Public Key Archival
Archival of public keys is achieved via certificate archival.
6.3.2
Private Key Archival
ACES encryption keys are intended to provide for the confidentiality of data during
transmission, and not for the confidentiality of data at rest. Therefore, ACES does not
normally provide for the escrow of private keys. However, ACES may support the
escrow of encryption keys when this is required.
6.3.3
Usage Periods for the Public and Private Keys
Key usage periods are discussed in Sections 3.2 and 4.7.
6.3.4
Restrictions on CA's Private Key Use
The private key used by ORC for issuing ACES Certificates are used only for signing
such Certificates and, optionally, CRLs or other validation service responses.
A private key issued under this CPS and used for purposes of manufacturing ACES
Certificates is considered an ORC ACES CA signing key, and is held by an authorized
entity as a fiduciary, and shall not be used for any other purposes, except as agreed by
GSA and ORC. Any private key used for purposes associated with functions described
in this CPS shall not be used for any other purpose without the express permission of
ORC.
The private key used by each IA and RA employed by ORC in connection with the
issuance of ORC ACES Certificates are used only for communications relating to the
approval or revocation of such certificates.
6.3.5
Private Key Multi-person Control
A single person is not permitted to activate the CA signature key or access any
cryptographic module containing the complete CA private signing key. See Section
5.2.1. Access to the CA signing keys backed up for disaster recovery is under the same
multi-person control as the original CA signing key.
106764133
93
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
The CA and CSA private keys are controlled under a ‘k of m’ (two or more) person
control. The names of the individuals used for two-person control are maintained on a
list that is available for compliance audits.
The hardware encryption module activation mechanism employed by ORC uses ‘k of m’
for administrator and operator cards, whereby each card set includes ‘m’ number of cards
and ‘k’ number of cards are required for administration or operation actions (where ‘m’
must be an integer greater than 1 and ‘k’ must be an integer less than or equal to ‘m’).
The hardware encryption module requires that one card (representing the ‘k’) is required
to an operation, where the SA controls and protects the card and the CAA controls and
protects the password.
When not in use, the CA and CSA hardware cryptographic module tokens are stored in a
GSA-approved security container in accordance with the physical security requirements
of Section 5.1 of this CPS.
Private encryption keys requested by other than the subscriber/PKI sponsor may only be
extracted from key recovery databases under two-person control, as described in the
ORC KRPS. The names of the parties used for two-person control are maintained on a
list that is made available for inspection during compliance audits.
The private components of IA, RA, and LRA signature key pairs and encryption key
pairs are under single person control. When not in use, IA, RA, and LRA cryptographic
hardware tokens must be remove from the workstation/computer and kept in the
possession of the IA, RA, and LRA or stored in a locked container.
6.3.6
Private Key Escrow
Under no circumstances shall a non-repudiation signature key escrowed. ORC does not
require private key escrow for confidentiality keys. However, ORC recommends to EEs
that they locally escrow a copy of the confidentiality private key.
For some purposes (such as data recovery), some organizations may desire key archival
and key retrieval for the private component of the encryption certificate key pair. To
facilitate this, ORC offers a key escrow and recovery capability.
The method, procedures and controls which apply to the storage, request for, extraction
and/or retrieval, delivery, protection and destruction of the requested copy of an
escrowed key are described in the ORC KRPS.
6.4 Activation Data
6.4.1
Activation Data Installation and Generation
The CA, IA, RA, LRA, CSA and other end entities shall use passwords to protect access
to private keys. The passwords need not be automatically generated.
In addition, subscribers will sign and return a subscriber advisory statement to help
understand responsibilities for the use and control of the cryptographic module. Not all
106764133
94
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
software currently available allows for technically enforced password expiration.
Activation data (password or pass-phrase) is generated by the subscriber, in accordance
with the stipulations of the subscriber’s agreement.
6.4.2
Activation Data Protection
Cryptographic modules are used to protect activation data and other critical security
parameters in accordance with FIPS 140-1/2 requirements.
Only the CAA has access to and uses ORC ACES CA and CSA signing key passwords,
used to unlock the hardware token. The password is written down and secured on-site
and off-site, at a separate facility, stored in a GSA-approved security container (Mosler
Safe). Only the CAA has access to the GSA-approved security container.
The activation data protection mechanism for ORC’s CA, IA and CSA equipment or
applications is accomplished by distributing the functions of the role among several
people, so that any malicious activity requires collusion. All CA and CSA actions
require two party participation according to the ORC PKI Roles Manual. Activation
requires the SA who holds the hardware token in their individual safe drawer to provide
it to the CAA for activation of either the CA or CSA. The CAA, with the SA observing,
must then provide the token password to activate the FIPS 140-1/2 Level 3 cryptographic
module. For administrator logins, the witnessing party counts up to three attempts for a
successful login. If login fails after three attempts, the witnessing party terminates the
login session and report the problem to the Corporate Auditor.
The subscribers shall protect their activation data from access by others, in accordance
with the subscriber’s agreement. If the activation data is not entered directly in the
cryptographic module, protocol shall be used so that the activation data is protected
against eavesdropping and replay. Examples of protocol are encrypting the data with a
new random session key each time, and challenge response.
6.4.3
Other Aspects of Activation Data
All ORC CMA personnel are required to change their individual token passwords no less
than once every three months and log this action in the audit notebook.
6.5 Computer Security Controls
Upon establishment and periodically thereafter, the most current DoD system security
audit script are run on the ORC CA and CSA infrastructure.
6.5.1
Audit
The ORC ACES system creates, maintains, and protects from modification, unauthorized
access, or destruction an audit trail of accesses to the resources it protects in accordance
with Federal law, regulations, guidelines, as well as GSA security policy and supporting
security guidelines. Activity-auditing capabilities employed by ORC on the ACES
system maintain a record of system activity by system, application processes and by
users. The ORC ACES system protects the audit data from destruction and provides
106764133
95
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
alternative audit options when standard audit mechanism is unable to record events. The
ORC Corporate Security Auditor is responsible for changes in the ORC audit policies
and procedures and for the frequent review for signs of unauthorized activity or other
security vulnerabilities.
Access to the audit data and online audit logs is be strictly limited. ORC maintains a
separation of duties between security personnel who administer the access control
function and those who administer the audit trail. The audit data is protected by the
system so that read access to it is limited to authorized users; and processes ensure that
only authorized users and/or programs can enable or disable the audit mechanism. Only
authorized staff are be able to retrieve audit trail information and archive it.
Unauthorized attempts to change, circumvent, or otherwise violate security features are
detectable and reported within a known time by the system.
For each recorded event, the audit trail includes the following information:

Date and time of the event

Unique user identification

Type of event

Success or failure of the action

Terminal identification
The CMA equipment logging capability is used to monitor all communications activity
with the host, to determine system/network usage, identify user difficulties and uncover
intrusion attempts. The Corporate Security Auditor reviews reports to determine if there
have been repeated unsuccessful attempts to login to the network. System audit trails
and suspected or confirmed computer security violations shall be monitored and
appropriate corrective action shall be taken where necessary. Records are maintained of
system anomalies, such as software error conditions, software check integrity failures,
receipt of improper messages, misrouted messages, and uninterruptible power supply
failures.
The duration of storage of audit data is adequate to ensure recognition of security
incidents and subsequent analysis of their occurrence, a minimum of 30 days.
6.5.1.1
Specific Computer Security Technical Requirements
ORC PKI equipment uses a self-protecting operating system, that is, one that prevents
and detects attempts to alter it, or to disable its security functions. Audits are carried out
as described in Section 4.5. The operating system performs identification and
authentication for individuals and actively enforces discretionary access controls on
system, application software and data.
6.5.1.2
Computer Security Rating
ORC CA equipment meets and is operated at U.K. Information Technology Security
Evaluation and Certification E2/F-C2 rating. This equates with C2 in the U.S. TCSEC /
Orange Book. ORC CA and CSA equipment operating at C2 implement discretionary
106764133
96
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
access control, object reuse controls, individual identification and authentication, and a
protected audit record.
ORC’s suite uses the Solaris Basic Security Module (BSM), which provides the security
auditing features, required by the C2 class of the Trusted Computer System Evaluation
Criteria (TCSEC), that are not included in the standard Solaris release. The additional
features are the security auditing subsystem and a device allocation mechanism that
provides the required object reuse characteristics for removable or assignable devices.
C2 Level discretionary access control and identification and authentication features are
provided by the standard Solaris system.
The ORC CA software is Netscape CMS, which is evaluated at Common Criteria
Evaluation Assurance Level (EAL) 4.
6.5.2
Technical Access Controls
The ORC PKI suite provides technical access controls designed to provide least privilege
and protections against unauthorized access to ACES system resources. Technical
controls have been developed and are implemented in accordance with FIPS Publication
83, Federal law, regulations and guidelines in addition to GSA security policy and
supporting security guidelines. Technical security controls are detailed in the ORC SSP.
The ORC PKI suite supports a ‘lock-out’ threshold if excessive invalid access attempts
are input, and records when an administrator unlocks an account that has been locked as
a result or unsuccessful authentication attempts. User IDs must be revoked if a password
attempt threshold of three failed login attempts is exceeded.
6.5.3
Identification and Authentication
The ORC PKI suite employs proper user authentication and identification methodology.
This methodology includes the use of user ID/password, token-based, and/or digital
certificate authentication schemes. The use and enforcement of password security is in
accordance with GSA security policy and supporting security guidelines as stipulated in
Section 6.2.5.
Users are required to identify themselves uniquely before being allowed to perform any
actions on the system. The ORC ACES system internally maintains the identity of all
users throughout their active sessions on the system and is able to link actions to specific
users. Identification data is kept current by adding new users and deleting former ones.
User IDs that are inactive on the system for a specific period of three months are
disabled. Self-protection techniques for user authentication mechanisms, policies that
provide for bypassing user authentication requirements, single-sign-on technologies
(host-to-host authentication servers, user-to-host identifier, and group user identifiers),
and compensating controls are as stipulated in this CPS and the ORC SSP.
6.5.4
Trusted Paths
ORC PKI accountability covers a trusted path between the user and the system. A
trusted path is a secure means of communication between the user and the system.
106764133
97
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
6.6 Life Cycle Technical Controls
Individuals with trusted roles within the ORC facility use security management tools and
procedures to ensure that the operational systems and networks adhere to the security
requirements that check the integrity of the system data, software, discretionary access
controls, audit profiles, firmware, and hardware to ensure secure operation.
Security management control includes the execution of tools and procedures to ensure
that the operational system and network adhere to configured security. These tools and
procedures include checking the integrity of the security software, firmware, and
hardware to ensure their correct operation.
The ORC PKI suite is protected by a firewalls (as stipulated in Section 6.7) installed on
SUN hardware. Each firewall rule is monitored by a auditing module. ORC employs a
network traffic recording, intrusion detection, and forensic analysis system to monitor
intrusion attempts and policy verification.
The initial firewall, IDS, and network system configurations are detailed in the ORC PKI
installation plans and procedures document. Updates are controlled and documented via
this document. Weekly review of the firewall and network system configurations against
the ORC PKI installation plans and procedures document are made by the firewall
administrator and SA to ensure that no unauthorized changes are made to these systems.
The firewall administrator and SA are to ensure that no unauthorized services are
processed and to identify any potential hacking attacks during weekly review of the
firewall and IDS logs. Detailed procedures for maintaining and inspecting the
Firewall/IDS and network devices are documented in the ORC SSP.
Any anomaly detected is reported to the ORC Corporate Security Auditor via signed email.



106764133
Physical Safeguards: The physical security safeguards and access controls are
continuously provide for protection against access or modifications to
hardware/software by unauthorized individuals. In addition to the physical
safeguards detailed in Section 5.1, hardware tokens are stored in a security container.
The CA and firewall Central Processing Unit (CPU), Redundant Array of
Inexpensive Disks (RAID)/external drives, monitors, keyboards, and mice are sealed
with Tamper Resistant Seals in accordance with paragraph 8-308, ISM and Tab B,
Code A, Quantum Information and Computation (QUIC); in order to detect
surreptitious entry into the equipment and associated peripherals. The seal is
inspected (and results logged) every month to ensure that it serves its intended use
Access Controls: Unescorted entry to the facility or access to any of its system
components (hardware/software) is limited to personnel who are cleared for access
and whose need to access the CAA has confirmed
Equipment: The CA and CSA equipment is SUN hardware running the SOLARIS
operating system and RAID disk system from Inline. The server is dedicated to
administrating the PKI, has only CA software installed and is behind a firewall, also
on SUN hardware, that permits only OCSP, https (in and out) and LDAP/S (out) to
98
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT

and from the network. Restricted IA access to the CA is via a dedicated authenticated
VPN. All upgrades are from the original equipment manufacturers and software
vendors.
Upgrades: The CAA and SA in accordance with the Procedural Controls in Section
5.2 accomplish Hardware and Software upgrades
Equipment (hardware and software) procured to operate the CA (including IA
equipment) and the CSA, is purchased in a fashion to reduce the likelihood that any
particular component was tampered with, such as random selection. All hardware and
software is only identified as supporting the CA (including IA) and CSA when randomly
selected at the ORC facility supporting the CA and/or CSA function. Equipment
provisioning for the CA (including IA equipment) and CSA is developed in a controlled
environment, at the CA and/or CSA facility. CA, IA and CSA software, when first
loaded, is verified as being that supplied by the vendor, with no modifications, and be the
version intended for use. This is accomplished by only using original vendor read-only
media or software digitally signed by a validated medium hardware assurance code
signing certificate. The configuration of CA and CSA systems, as well as any
modifications or upgrades, is documented. These systems have the capability installed
and operating to detect unauthorized modifications to CA and CSA systems software and
configurations.
6.6.1
System Development Controls (Environment Security)
All assembly and maintenance of CA and CSA systems is accomplished in the controlled
environment of the SNOC as described in Section 5.1.1. Only personnel designated in
this CPS perform maintenance on the PKI systems. The CAA and SA in accordance
with the Procedural Controls in Section 5.2 accomplish hardware and software upgrades.
6.6.2
Security Management Controls
All ORC PKI system security features described in this CPS are configured and enabled.
The configuration of the ORC ACES system (including hardware, software, and
operating system) as well as any modifications and upgrades are documented and
controlled with mechanisms for detecting unauthorized modification to the software or
configuration.
ORC conducts design review and system tests prior to placing systems or system updates
into operation to assure that they meet security specifications. If new controls are added
to the application or the support system, testing of those new controls are performed to
ensure that the new controls meet security specifications and do not conflict with or
invalidate existing controls. The results of the design reviews and system tests are fully
documented, updated as new reviews or tests are performed, and maintained in the ORC
ACES build control documents.
ORC employs a formal configuration management methodology for installation and
ongoing maintenance of the ACES system. All CMA software, when first loaded, is
verified as being that supplied from the vendor, with no modifications, and being the
version intended for use. ORC CA and CSA systems Configuration Management (CM)
records are maintained by the Corporate Security Auditor as described in Section 5.2.1.
106764133
99
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
These records are stored in a locked container under the Security Auditor's control. CM
documents include the ORC CA signing key ceremony document, CA electronic forms,
and CA and CSA creation log and procedures.
ORC CA equipment is dedicated to administering a key management infrastructure does
not have installed applications or component software, which are not part of the PKI
configuration. Equipment (hardware and software) procured to operate a PKI is
purchased in a fashion to reduce the likelihood that any particular component was
tampered with, such as random selection. In the event that equipment is developed for a
PKI, it shall be developed in a controlled environment and the development process shall
be defined and documented.
All CMA hardware and software is shipped or delivered via controlled methods that
provide a continuous chain of accountability, from the location where it has been
identified as supporting a CMA function to the using facility.
For all entities responsible for local registration (including Federal, State and Local
Government agencies/personnel), reasonable care shall be taken to prevent malicious
software from being loaded on any equipment used in the registration process. Only
applications required to perform the organization's mission shall be loaded on these
computers, and all such software shall be obtained from sources authorized by local
policy. Data on such equipment shall be scanned for malicious code on first use and
periodically afterward.
Hardware and software updates shall be purchased or developed in the same manner as
original equipment, and be installed by trusted and trained personnel in a defined
manner, as stipulated in the ORC SSP.
6.6.3
Object Reuse
When a storage object (e.g., core area, disk file, etc.) is initially assigned, allocated, or
reallocated to a system user, the system is insured to cleared in accordance with Federal
law, regulations, and guidelines, as well as GSA security policy and supporting security
guidelines by the SA. The ORC SSP specifies procedures for sanitizing electronic media
for reuse (e.g., overwrite or degaussing of electronic media) and controlled storage,
handling, or destruction of spoiled media, or media that cannot be effectively sanitized
for reuse.
All magnetic media used to store sensitive unclassified information is purged or
destroyed when no longer needed. The ACES system ensures that a user is not able to
access the prior contents of a resource that has been allocated to that user by the system.
Care is taken to ensure that the Recycle Bin does not store deleted files and standard
industrial security procedures ensure the proper disposal of printed output based on the
sensitivity of the data.
6.7 Network Security Controls
Access to the CA data is protected by a firewall specifically allocated to protection of the
ORC PKI suite. Only required accounts are present on the firewall. HTTPS and OCSP
106764133
100
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
requests are the only type of data access that is allowed in. OCSP, HTTPS and LDAP/S
are the only packet types allowed out. The firewall is secured in the locked CA
environment area and not accessible over the network. Restricted IA access to the CA is
via a dedicated authenticated VPN. An approved trusted SA makes all changes at the
firewall station itself.
Access to the ORC IA workstations and workstations used by RAs on the ORC network
are protected by the ORC facility firewall. Only required accounts are present on the
firewall. The firewall is secured in the ORC SNOC. Only approved trusted SAs make
changes to the facility firewall.
ORC firewalls are used as boundary controllers, which are evaluated at Common Criteria
Evaluation Assurance Level (EAL) 4. All unused network ports and services shall be
turned off. Any network software present on ORC CA, IA or RA equipment is necessary
to the functioning of the PKI application.
Network security controls for LRA equipment are the responsibility of the LRA’s
organization, whether the LRA is an employee of ORC or another organization. The PKI
Sponsor shall ensure that the LRA equipment is protected, as specified in the U.S.
Government CA CP for CMA equipment. Where practical, the subscriber’s organization
will only allow services to and from LRA equipment limited to those required to perform
LRA functions. However, additional services consistent with the organization’s policy
may be enabled. Protection shall be provided against known network attacks. All
unused network ports and services shall be turned off. Any network software present on
LRA equipment shall be necessary to the LRA function. Boundary control devices used
to protect LRA equipment shall deny all but necessary services to the LRA equipment
even if those services are enabled for other devices on the network. Firewall shall meet
the security functional requirements as specified in the DoD for medium robustness
Firewall Protection Profile [FWPP]. Boundary control devices shall include an Intrusion
Detection capability that meets the security functional requirements as specified in the
Intrusion Detection System Protection Profile [IDSPP]. The PKI Sponsor will certify
compliance with these requirements, in writing to the ORC Corporate Security Auditor,
prior to approval of performing LRA functions and will certify compliance with these
requirements, in writing to the ORC Corporate Security Auditor, annually.
6.7.1
Remote Access/Dial-up Access
Remote access to the ORC CMA equipment is prohibited.
6.7.2
Firewalls
In the event that GSA systems interconnect to the ORC ACES system, the connection
will be via a secure methodology (such as a firewall) that provides security
commensurate with acceptable risk and limit access only to the information needed by
the other system. Telnet is restricted through firewalls into government servers.
106764133
101
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
6.7.3
Encryption
To assist in meeting the requirements outlined in this CPS, ORC maintains a website.
The majority of the information on the website is publicly accessible, although it
incorporates SSL to promote data integrity and to allow users to validate the source of
the information:

ORC SSL connections employ, at a minimum, three key triple-Data Encryption
Standard (triple-DES) (or equivalent) for the symmetric key algorithm.

ORC uses Hardware Security Modules for key protection and SSL acceleration

ORC ECA provides Federal Information Processing Standards (FIPS) 140-1/2 Level
3 SSL connections to the certification authority and FIPS 140-1/2 Level 2 SSL
connections to other services

Cryptographic key management procedures are as stipulated in Section 6.2
6.7.4
6.7.4.1
Interconnections
Connectivity with Internet and Other WANs
ORC is required to obtain written authorization from GSA prior to connecting with other
GSA systems. ORC provides the following information concerning the authorization for
the connection to other systems or the sharing of information:

List of interconnected systems (including Internet.)

Unique system identifiers, if appropriate

Name of system(s)

Organization owning the other system(s)

Type of interconnection (TCP/IP, Dial, SNA, etc.)

Discussion of major concerns or considerations in determining interconnection (do
not repeat the system rules)

Date of authorization

System of Record, if applicable (Privacy Act data)

Sensitivity level of each system

Interaction among systems

Security concerns and Rules of Behavior of the other systems that need to be
considered in the protection of this system
Access to and from other systems is controlled according to OMB circular A-130.
106764133
102
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
6.7.5
Router
The ORC SSP provides information regarding any port protection devices used to require
specific access authorization to the communication ports, including the configuration of
the port protection devices, and if additional passwords or tokens are required.
6.7.6
Inventory of Network Hardware/Software
ORC has developed and maintains a comprehensive inventory of ACES IT equipment,
hardware and software configurations (including security software protecting the system
and information), and major information systems/applications, identifying those
systems/applications which process sensitive information IAW Federal laws and
regulations and GSA security Policy and guidelines. This information can be found in
the ORC ACES build control documents.
6.8 Cryptographic Module Engineering Controls
Requirements for cryptographic modules are as stated above in Section 6.2.
106764133
103
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
7
Certificate And CRL Profiles
7.1 Certificate Profile
ORC ACES Certificates contain public keys used for authenticating the sender and
receiver of an electronic message and verifying the integrity of such messages, i.e.,
public keys used for digital signature verification.
ORC creates and maintains ACES Certificates that conform to the ITU-T
Recommendation X.509, “The Directory: Authentication Framework,” June 1997.
All ORC ACES Certificates include a reference to an OID for this CPS within the
appropriate field, and contain the required certificate fields according to this CPS and the
GSA ACES Contract.
Complete certificate profile information, including key generation methods, for ACES
certificates can be found in Attachment E, Certificate Profiles.
7.1.1
Version Numbers
ORC issues X.509 v3 ACES certificates (populate version field with integer 2).
7.1.2
Certificate Extensions
ORC ACES certificate profiles are in accordance with the requirements of the certificate
profiles described in the ACES CP. The profiles are described in Appendix E.
Access control information may be carried in the subjectDirectoryAttributes non-critical
extension. The syntax is defined in detail in [SDN702].
7.1.3
Algorithm Object Identifiers
Certificates issued by the ORC ACES CAs use the following OIDs for signatures.
sha-1WithRSAEncryption
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs1(1) 5}
Certificates under this Policy use the following OIDs for identifying the algorithm for
which the subject key was generated.
106764133
rsaEncryption
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs1(1) 1}
dhpublicnumber
{iso(1) member-body(2) us(840) ansi-x942(10046) numbertype(2) 1}
104
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
id-keyExchangeAlgorithm
{joint-iso-ccitt(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) algorithms(1) 22}
ORC certifies only public keys associated with the crypto-algorithms identified above,
and only uses the signature crypto-algorithms described above to sign certificates,
certificate revocation lists and ORC’s CSA OCSP responses.
7.1.4
Name Forms
Distinguished Names (DNs) are used by the CA in the issuer and in subject fields of the
certificates. X.500 Directories use the DN for lookups. All Relying Parties will have the
ability to process DNs. If communities request to use other names, for example
certificates used to implement a hardware protocol, where device addresses are most
useful and certificate lookup is not performed, ORC will define alternate name forms to
be included in the subjectAltName extension and provide the alternative name form to
the Policy Authority. Any name form defining GeneralName in [ISO9594-8] isused, in
accordance with the required profile (Section 7.1.2).
7.1.5
Name Constraints
FBCA cross certificates issued by an ORC CA contains the Name Constraints extension
set by the Policy Authority.
7.1.6
Certificate Policy Object Identifier
Certificates issued by the CA asserts the OID appropriate to the level of assurance with
which it was issued, as defined in Section 1.2.
7.1.7
Usage of Policy Constraints Extension
No Stipulation, unless cross-certification policy stipulates use of policy constraints.
7.1.8
Policy Qualifiers Syntax and Semantics
No Stipulation.
7.1.9
Processing Semantics for the Critical Certificate Policy Extension
ORC does not set the certificate policies extension to be critical. Relying Parties whose
client software does not process this extension do so at their own risk. Processing
semantics for the critical certificate policy extension used by the ORC conforms to
[FPKI-PROF].
7.2 CRL Profile
ORC ACES CRL profiles addressing the use of each extension are provided in Appendix
E and conform to the Federal PKI X.509 Certificate and CRL Extension Profile version
two (2) and RFC 3280.
106764133
105
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
7.2.1
Version Numbers
CRLs issued under this CPS assert a version number as described in the X.509 standard
[ISO9594-8]. CRLs assert Version 2.
7.2.2
CRL and CRL Entry Extensions
Detailed CRL profiles covering the use of each extension are available and described in
Appendix A and are in accordance with the ACES CP CRL profile. The CA supports
CRL Distribution Points (CRL DP) in all EE certificates. The CRL DP is as follows:
ldap://aces-ds.orc.com/cn=ORC ACES <CA Name>, o=ORC PKI,
c=US?certificaterevocationlist;binary
7.3 OCSP Request – Response Format
Appendix E contains the format (profile) for OCSP requests and responses.
106764133
106
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
8
CPS Administration
8.1 CPS Change Procedures
ORC will process any recommended changes communicated to the contact identified in
Section 1.4 by the Government. ORC may choose to update this CPS at any time, but
will submit draft changes to the Government for approval before incorporating in the
official CPS.
8.1.1
List of Items
Notice of all proposed changes to this CPS under consideration by GSA that may
materially affect users of this CPS (other than editorial or typographical corrections,
changes to the contact details, or other minor changes) will be provided to Authorized
CAs and Qualified Relying Parties, and will be posted on the GSA website. ORC posts
notice of such proposed changes and advise their subscribers of such proposed changes,
via the ORC ACES website.
8.1.2
Comment Period
Any interested person may file comments with GSA within 45 days of original notice. If
the proposed change is modified as a result of such comments, a new notice of the
modified proposed change is provide.
8.2 Publication and Notification Procedures
ORC shall notify the Policy Authority of any changes to this CPS. ORC posts
notification of changes on the website associated with the CA operations as applicable to
the CPS summary and other publicly available documentation. ORC notifies subscribers
via e-mail of any changes to subscriber obligations. ORC posts a summary of this CPS
on its ACES website. Subscriber obligation changes are published within seven (7) days.
8.3 CPS and External Approval Procedures
GSA will make the determination that this CPS complies with the policy identified in
Section 1.2.
8.4 Waivers
No Stipulation.
106764133
107
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Appendix A: Relying Party Agreement
Refer to the ACES Certificate Policy, Appendix A.
106764133
A-1
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Appendix B: Acronyms And Abbreviations
ACES
Access Certificates for Electronic Services
ACL
Access Control List
ACO
Administrative Contracting Officer
AICPA
American Institute of Certified Public Accountants
ANSI
American National Standards Institute
ASIS
American Society of Industrial Security
ASN.1
Abstract Syntax Notation One
BSM
Basic Security Module
C&A
Certification and Accreditation
CA
Certification Authority
CAA
Certificate Authority Administrator
CAM
Certificate Arbitrator Module
CARL
Certificate Authority Revocation List
CMA
Certificate Management Authorities
CMC
Certificate Management Messages over CMS (Cryptographic Message Syntax)
CMMF
Certificate Management Message Format
CMS
Certificate Management System
CN
Common NameCOTS Commercial Off The Shelf
CP
Certificate Policy
CPS
Certificate Practice Statement
CRL
Certificate Revocation List
CRL DP
CRL Distribution Point
CRMF
Certificate Request Message Format
CSA
Certificate Status Authority
CSAA
Code Signing Attribute Authority
CSOR
Computer Security Objects Register
DER
Distinguished Encoding Rules
DES
Data Encryption Standard
DN
Distinguished Name
DoD
Department of Defense
DRP
Disaster Recovery Plan
106764133
B-1
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
DSA
Digital Signature Algorithm
DSS
Digital Signature Standard
EAL
Evaluation Assurance Level
EE
End Entitiy
FAR
Federal Acquisition Regulation
FBCA
Federal Bridge Certification Authority
FIPS
Federal Information Processing Standard
FQDN
Fully Qualified Domain Name
FTP
File Transfer Protocol
FTS
Federal Technology Service
GSA
General Services Administration
GSII
Government Services Information Infrastructure
HSM
Hardware Security Module
HTTP
Hypertext Transfer Protocol
HTTPS
Transfer Protocol over Secure Sockets Layer
IA
Issuing Authority
IDS
Intrusion Detection System
IETF
Internet Engineering Task Force
IP
Internet Protocol
IPSEC
IP Security
ISO
International Standards Organization
ITU
International Telecommunications Union
ITU-T
International Telecommunications Union – Telecommunications Sector
ITU-TSS
International Telecommunications Union – Telecommunications Systems Sector
KED
Key Escrow Database
KRPS
Key Recovery Practices Statement
KRS
Key Recovery System
LDAP
Lightweight Directory Access Protocol
LRA
Local Registration Authority
NIST
National Institute of Standards and Technology
NSA
National Security Agency
OCSP
Online Certificate Status Protocol
OGP
Office of Government-wide Policy
106764133
B-2
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
OID
Object Identifier
OMB
Office of Management and Budget
ORC
Operational Research Consultants
PIN
Personal Identification Number
PKCS
Public Key Cryptography Standard
PKI
Public Key Infrastructure
PKIX
Public Key Infrastructure X.509
POP
Proof of Possession
PPP
Privacy Practices and Procedures
RA
Registration Authority
RAID
Redundant Array of Independent (or Inexpensive) Disks
RDN
Relative Distinguished NameRFC
RSA
Rivest Shamir Adleman
SA
System Administrator
SAS
Statement on Auditing Standards
SBU
Sensitive But Unclassified
SHA
Secure Hash Algorithms
SNOC
Secure Network Operations Center
SSL
Secure Sockets Layer
SSP
System Security Plan
TCSEC
Trusted Computer System Evaluation Criteria
TSM
Token Strength ModuleU.S.
U.S.C.
United States Code
UPS
Uninterruptible Power Supply
URL
Uniform Resource Locator
WWW
World Wide Web
106764133
Request For Comments
United States
B-3
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Appendix C: Auditable Events Table
Auditable Event
Type4
Area
M
M
Configuration
Management (CM)
Audit Log
M
M
M
Audit Log
CM
Audit Log
M
Audit Log
M
Audit Log
A&M
Installation & CM
M
A&M
Installation
Audit Log
A
CRL
M
Audit Log
A&M
RA Log
SECURITY AUDIT
Any changes to the Audit parameters, e.g., audit frequency, type of
event audited
Any attempt to delete or modify the Audit logs
IDENTIFICATION & AUTHENTICATION
Successful and unsuccessful attempts to assume a role
Change in the value of maximum authentication attempts
Maximum number of unsuccessful authentication attempts during user
login
An Administrator unlocks an account that has been locked as a result
of unsuccessful authentication attempts
An Administrator changes the type of authenticator, e.g., from
password to biometrics
KEY GENERATION
Whenever a CA generates a key. (Not mandatory for single session or
one-time use symmetric keys)
PRIVATE KEY LOAD & STORAGE
The loading of Component private keys
All access to certificate subject private keys retained within the
Authorized CA for key recovery purposes
TRUSTED PUBLIC KEY ENTRY, DELETION & STORAGE
All changes to the trusted public keys, including additions and
deletions
PRIVATE KEY EXPORT
The export of private keys (keys used for a single session or message
are excluded)
CERTIFICATE REGISTRATION
All certificate requests
CERTIFICATE REVOCATION
All certificate revocation requests
RA Log
CERTIFICATE STATUS CHANGE APPROVAL
The approval or rejection of a certificate status change request
A&M
RA Log
AUTHORIZED CA CONFIGURATION
Any security-relevant changes to the configuration of the Authorized
CA
CM
ACCOUNT ADMINISTRATION
Roles and users are added or deleted
Access control privileges of a user account or a role are modified
A&M
A&M
Audit Log
Audit Log
M
CM
CERTIFICATE PROFILE MANAGEMENT
All changes to the certificate profile
4
Automated (A) or Manual (M).
106764133
C-1
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Auditable Event
REVOCATION PROFILE MANAGEMENT
All changes to the revocation profile
Type4
Area
M
CM
M
CM
M
M
M
M
M
M
M
M
M
M
M
M
M
A&M
A&M
A&M
A&M
M
M
M
Installation & CM
Installation & CM
Installation & CM
CM
Audit Log
Audit Log
Audit Log
Audit Log
Audit Log
Audit Log
Installation & CM
Installation & CM
Installation & CM
Audit Log
Audit Log
RA Log
RA Log
RA Log
Audit Log
Installation & CM
M
M
M
M
M
CM
CM
CM
CM
CM
A&M
A&M
M
Audit Log
Audit Log
Audit Log
A&M
A&M
A&M
A&M
A&M
A&M
A&M
A&M
A&M
M
Audit Log
Audit Log
Audit Log
Audit Log
Audit Log
Audit Log
Audit Log
Audit Log
Audit Log
Audit Log
CRL PROFILE MANAGEMENT
All changes to the certificate revocation list profile
MISCELLANEOUS
Installation of the Operating System
Installation of the Authorized CA
Installing hardware cryptographic modules
Removing hardware cryptographic modules
Destruction of cryptographic modules
System Startup
Logon Attempts to Authorized CA Apps
Receipt of Hardware / Software
Attempts to set passwords
Attempts to modify passwords
Backing up Authorized CA internal database
Restoring Authorized CA internal database
File manipulation (e.g., creation, renaming, moving)
Posting of any material to a repository
Access to Authorized CA internal database
All certificate compromise notification requests
Loading tokens with certificates
Shipment of Tokens
Zeroizing tokens
Rekey of the Authorized CA
Configuration changes to the CA server involving:
Hardware
Software
Operating System
Patches
Security Profiles
PHYSICAL ACCESS / SITE SECURITY
Personnel Access to room housing Authorized CA
Access to the Authorized CA server
Known or suspected violations of physical security
ANOMALIES
Software Error conditions
Software check integrity failures
Receipt of improper messages
Misrouted messages
Network attacks (suspected or confirmed)
Equipment failure
Electrical power outages
Uninterruptible Power Supply (UPS) failure
Obvious and significant network service or access failures
Violations of Certificate Policy
106764133
C-2
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Auditable Event
Violations of Certification Practice Statement
Resetting Operating System clock
106764133
C-3
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
Type4
Area
M
A&M
Audit Log
Audit Log
DRAFT
Appendix D: Applicable Federal and GSA
Regulations
Refer to the ACES Certificate Policy, Appendix D.
106764133
D-1
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Appendix E: ORC ACES Profile Formats
E.1 ACES Root CA Self-Signed Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier
Subject key identifier
key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
Subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points5
Subordinate CA Value
V3 (2)
Unique
sha-1WithRSAEncryption {1 2 840 113549 1 1 5}
cn=ORC Government Root, o=ORC PKI, c=US
32-years
cn=ORC Government Root, o=ORC PKI, c=US
1024 bit RSA key modulus, rsaEncryption {1 2 840 113549 1 1 1}
Not Present
Not Present
sha-1WithRSAEncryption {1 2 840 113549 1 1 5}
Not Present
Octet String (20 byte SHA-1 hash of the binary DER encoding of the ACES
Root CA public key information)
Not Present
Not Present
Not Present
Not Present
Not Present
Not Present
Not Present
Not Present
c=no; cA=True; path length constraint = Not Present
Not Present
Not Present
Not Present
c=no; ldap://aces-ds.orc.com/ cn=ORC Government Root, o=ORC PKI,
c=US?certificaterevocationlist;binary
5
The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
106764133
E-1
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.2 Authorized CA Certificate Profile
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier
Subject key identifier
key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
Subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
Subject Information Access
CRL Distribution Points7
Subordinate CA Value
V3 (2)
Must be unique
sha-1WithRSAEncryption {1 2 840 113549 1 1 5}
cn=ORC Government Root, o=ORC PKI, c=US
6 years from date of issue in UTCT format
cn=ORC ACES <CA Name>, o=ORC PKI, c=US
1024 bit RSA key modulus, rsaEncryption {1 2 840 113549 1 1 1}
Not Present
Not Present
sha-1WithRSAEncryption {1 2 840 113549 1 1 5}
Octet String (20 byte SHA-1 hash of the binary DER encoding of the ECA
Root CA’s public key information)
Octet String (20 byte SHA-1 hash of the binary DER encoding of the ECA
public key information)
c=yes; digitalSignature, nonRepudiation, keyCertSign, cRLSign
Not Present
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 1 }
Not Present
Not Present
Not Present
Not Present
c=yes; CA=True
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES <CA Name>, o=ORC PKI, c=US?cacertificate;binary6
c=no; id-ad-caRepository=ldap://aces-ds.orc.com/
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES <CA Name>,
o=ORC PKI, c=US?certificaterevocationlist;binary
6
The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to the
CA that issued the certificate containing this extension.
7 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
106764133
E-2
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.3 Unaffiliated Individual Identity Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier8
Subject key identifier9
key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points11
Identity Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Unaffiliated CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<State or Country>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes;digitalSignature, nonRepudiation
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 2 }, id-fpki-common-policy::={2 16 840 1
101 3 2 1 3 6}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=False
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Unaffiliated CA, o=ORC PKI, c=US?cacertificate;binary10
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Unaffiliated
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
9 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key information.
10 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
11 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
8
106764133
E-3
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.3(a) Unaffiliated Individual Identity Certificate Hardware
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier12
Subject key identifier13
key usage
Extended key usage14
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points16
Identity Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Unaffiliated CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<State or Country>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes;digitalSignature, nonRepudiation
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 2 }, id-fpki-common-hardware::={2 16 840
1 101 3 2 1 3 7}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=False
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Unaffiliated CA, o=ORC PKI, c=US?cacertificate;binary15
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Unaffiliated
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
13 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
14
Microsoft Smart Card Logon MS- {1 3 6 1 4 1 311 20 2 2}, optional for medium hardware
12
assurance only.
15
The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
16 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
106764133
E-4
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.4 Unaffiliated Individual Encryption Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier17
Subject key identifier18
Key usage
Extended key usage19
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points21
Encryption Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Unaffiliated CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<State or Country>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 1 2 840 113549 1 1 5 }, id-fpki-common-policy::={2 16 840 1 101
3 2 1 3 6}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=false
Not Present
Not Present
c=no; ocsp=http://aceseva.orc.com, caIssuers=ldap://aces-ds.orc.com/
cn=ORC ACES Unaffiliated CA, o=ORC PKI, c=US?cacertificate;binary 20
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Unaffiliated
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
18 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
19
Microsoft Encrypted File System MS-EFS {1 3 6 1 4 1 311 10 3 4}, optional.
20 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
21 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
17
106764133
E-5
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.4(a) Unaffiliated Individual Encryption Certificate Hardware
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier22
Subject key identifier23
Key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points25
Encryption Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Unaffiliated CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<State or Country>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 1 2 840 113549 1 1 5 }, id-fpki-common-hardware::={2 16 840 1
101 3 2 1 3 7}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=false
Not Present
Not Present
c=no; ocsp=http://aceseva.orc.com, caIssuers=ldap://aces-ds.orc.com/
cn=ORC ACES Unaffiliated CA, o=ORC PKI, c=US?cacertificate;binary 24
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Unaffiliated
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
23 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
24 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
25 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
22
106764133
E-6
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.5 Business Representative Identity Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier26
Subject key identifier27
key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points29
Identity Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Business CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<Department>, ou=<State or Country>,
o=<Company Name>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes;digitalSignature, nonRepudiation
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 3 }, id-fpki-common-policy::={2 16 840 1
101 3 2 1 3 6}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=False
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/cn=ORC
ACES Business CA,o=ORC PKI, c=US?cacertificate;binary28
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Business CA,
o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
27 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
28 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
29 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
26
106764133
E-7
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.5(a) Business Representative Identity Certificate Hardware
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier30
Subject key identifier31
key usage
Extended key usage32
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points34
Identity Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Business CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<Department>, ou=<State or Country>,
o=<Company Name>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes;digitalSignature, nonRepudiation
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 3 }, id-fpki-common-hardware::={2 16 840
1 101 3 2 1 3 7}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=False
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/cn=ORC
ACES Business CA,o=ORC PKI, c=US?cacertificate;binary33
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Business CA,
o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
31 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
32
Microsoft Smart Card Logon MS- {1 3 6 1 4 1 311 20 2 2}, optional for medium hardware
30
assurance only.
33
The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
34 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
106764133
E-8
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.6 Business Representative Encryption Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier35
Subject key identifier36
Key usage
Extended key usage37
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points39
Encryption Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Business CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<Department>, ou=<State or Country>,
o=<Company Name>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 1 2 840 113549 1 1 5 }, id-fpki-common-policy::={2 16 840 1 101
3 2 1 3 6}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=false
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Business CA, o=ORC PKI, c=US?cacertificate;binary 38
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Business CA,
o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
36 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
37
Microsoft Encrypted File System MS-EFS {1 3 6 1 4 1 311 10 3 4}, optional.
38 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
39 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
35
106764133
E-9
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.6(a) Business Representative Encryption Certificate
Hardware
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier40
Subject key identifier41
Key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points43
Encryption Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Business CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<Department>, ou=<State or Country>,
o=<Company Name>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 1 2 840 113549 1 1 5 }, id-fpki-common-hardware::={2 16 840 1
101 3 2 1 3 7}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=false
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Business CA, o=ORC PKI, c=US?cacertificate;binary 42
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Business CA,
o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
41 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
42 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
43 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
40
106764133
E-10
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.7 Relying Party Application Identity Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier44
Subject key identifier45
key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points47
Identity Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Government CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Agency Application Name>, ou=<Agency Name>, o=U.S.
Government, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes;digitalSignature, nonRepudiation
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 4 }, id-fpki-common-devices::={2 16 840 1
101 3 2 1 3 6}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=False
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Government CA, o=ORC PKI, c=US?cacertificate;binary46
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Government
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
45 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
46 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
47 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
44
106764133
E-11
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.8 Relying Party Application Encryption Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier48
Subject key identifier49
Key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points51
Encryption Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Government CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Agency Application Name>, ou=<Agency Name>, o=U.S.
Government, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 4 }, id-fpki-common-devices::={2 16 840 1
101 3 2 1 3 6}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=false
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Government CA, o=ORC PKI, c=US?cacertificate;binary 50
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Government
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
49 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
50 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
51 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
48
106764133
E-12
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.9 Federal Employee Identity Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier52
Subject key identifier53
key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points55
Identity Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Government CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<Agency Name>, o=U.S. Government, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes;digitalSignature, nonRepudiation
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 6 }, id-fpki-common-policy::={2 16 840 1
101 3 2 1 3 6}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=False
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Government CA, o=ORC PKI, c=US?cacertificate;binary 54
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Government
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
53 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
54 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
55 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
52
106764133
E-13
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.9(a) Federal Employee Identity Certificate Hardware
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier56
Subject key identifier57
key usage
Extended key usage58
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points60
Identity Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Government CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<Agency Name>, o=U.S. Government, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes;digitalSignature, nonRepudiation
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 7 }, id-fpki-common-hardware::={2 16 840
1 101 3 2 1 3 7}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=False
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Government CA, o=ORC PKI, c=US?cacertificate;binary 59
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Government
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
57 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
58
Microsoft Smart Card Logon MS- {1 3 6 1 4 1 311 20 2 2}, optional for medium hardware
56
assurance only.
59
The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
60 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
106764133
E-14
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.10 Federal Employee Encryption Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier61
Subject key identifier62
Key usage
Extended key usage63
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points65
Encryption Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Government CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<Agency Name>, o=U.S. Government, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 6 }, id-fpki-common-policy::={2 16 840 1
101 3 2 1 3 6}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=false
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Government CA, o=ORC PKI, c=US?cacertificate;binary 64
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Government
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
62 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
63
Microsoft Encrypted File System MS-EFS {1 3 6 1 4 1 311 10 3 4}, optional.
64 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
65 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
61
106764133
E-15
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.10(a) Federal Employee Encryption Certificate Hardware
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier66
Subject key identifier67
Key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points69
Encryption Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Government CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<Agency Name>, o=U.S. Government, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 7 }, id-fpki-common-hardware::={2 16 840
1 101 3 2 1 3 7}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=false
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Government CA, o=ORC PKI, c=US?cacertificate;binary 68
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Government
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
67 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
68 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
69 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
66
106764133
E-16
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.11 Federal Agency Application Encryption (SSL) Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier70
Subject key identifier71
Key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
Subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points73
Component & Web Server Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Government CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Host URL | IP Address | Host Name>, ou=<Agency Name>, o=U.S.
Government, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment, digitalSignature, nonRepudiation
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 5 } id-fpki-common-devices::={2 16 840 1
101 3 2 1 3 6}
Not Present
c=no; URIName=https://<Server External IP Address>/
Not Present
Not Present
c=yes; cA=false
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Government CA, o=ORC PKI, c=US?cacertificate;binary72
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Government
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
71 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
72 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
73 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and cRLIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
70
106764133
E-17
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.12 State and Local Employee Identity Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier74
Subject key identifier75
key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points77
Identity Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Government CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<Agency Name>, o=<State>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes;digitalSignature, nonRepudiation
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 6 }, id-fpki-common-policy::={2 16 840 1
101 3 2 1 3 6}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=False
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Government CA, o=ORC PKI, c=US?cacertificate;binary 76
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Government
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
75 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
76 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
77 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
74
106764133
E-18
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.12(a) State and Local Employee Identity Certificate Hardware
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier78
Subject key identifier79
key usage
Extended key usage80
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points82
Identity Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Government CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<Agency Name>, o=<State>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes;digitalSignature, nonRepudiation
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 7 }, id-fpki-common-hardware::={2 16 840
1 101 3 2 1 3 7}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=False
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Government CA, o=ORC PKI, c=US?cacertificate;binary 81
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Government
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
79 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
80
Microsoft Smart Card Logon MS- {1 3 6 1 4 1 311 20 2 2}, optional for medium hardware
78
assurance only.
81
The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
82 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
106764133
E-19
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.13 State and Local Employee Encryption Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier83
Subject key identifier84
Key usage
Extended key usage85
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points87
Encryption Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Government CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<Agency Name>, o=<State>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 6 }, id-fpki-common-policy::={2 16 840 1
101 3 2 1 3 6}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=false
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Government CA, o=ORC PKI, c=US?cacertificate;binary 86
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Government
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
84 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
85
Microsoft Encrypted File System MS-EFS {1 3 6 1 4 1 311 10 3 4}, optional.
86 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
87 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
83
106764133
E-20
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.13(a) State and Local Employee Encryption Certificate
Hardware
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier88
Subject key identifier89
Key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points91
Encryption Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Government CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Subscriber Name>, ou=<Agency Name>, o=<State>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 7 }, id-fpki-common-hardware::={2 16 840
1 101 3 2 1 3 7}
Not Present
c=no; always present, contains RFC822 e-mail address
Not Present
Not Present
c=yes; cA=false
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Government CA, o=ORC PKI, c=US?cacertificate;binary 90
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Government
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
89 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
90 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
91 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and crlIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
88
106764133
E-21
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.14 State and Local Server (SSL) Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Extensions
Authority key identifier92
Subject key identifier93
Key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
Subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points95
Component & Web Server Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES Government CA, o=ORC PKI, c=US
2 years from date of issue
cn=<Host URL | IP Address | Host Name>, ou=<Agency Name>,
o=<State>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment, digitalSignature, nonRepudiation
c=no; {1 3 6 1 5 5 7 3 1}, {1 3 6 1 5 5 7 3 2}, {1 3 6 1 5 5 7 3 3}, {1 3 6 1
5 5 7 3 4}, {1 3 6 1 5 5 7 3 8}, {1 3 6 1 5 5 7 3 9}, {1 3 6 1 4 1 311 20 2
2}, {1 3 6 1 4 1 311 10 3 1}, {1 3 6 1 4 1 311 10 3 4}
Not Present
c=no; { 2 16 840 1 101 3 2 1 1 5 } id-fpki-common-devices::={2 16 840 1
101 3 2 1 3 6}
Not Present
c=no; URIName=https://<Server External IP Address>/
Not Present
Not Present
c=yes; cA=false
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES Government CA, o=ORC PKI, c=US?cacertificate;binary94
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES Government
CA, o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
93 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
94 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
95 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and cRLIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
92
106764133
E-22
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.15 Code Signing Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Authority key identifier96
Subject key identifier97
Key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
Subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points99
Code Signing Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES <CA Name>, o=ORC PKI, c=US
2 years from date of issue
cn=CS.<Code Signer Organization Name>.<optional number>, <ou=Code
Signer Company Name>, o=<Consistent with Subscriber Signing
Certificate> , c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; digitalSignature, nonRepudiation
c=yes; { iso(1) identified-organization(3) DoD(6) internet(1) security(5)
mechanisms(5) pkix(7) id-kp(3) id-kp-codesigning (3)}
Not Present
c=no; {2 16 840 1 101 3 2 1 12 1}, {2 16 840 1 101 3 2 1 12 2}, id-fpkicommon-hardware::={2 16 840 1 101 3 2 1 3 7}
Not Present
always present; c=no; cn=<private key holder name>, <ou=Code Signer
Company Name>, o==<Consistent with Signing Certificate>, c=US
Not Present
Not Present
Not Present
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES <CA Name>, o=ORC PKI, c=US?cacertificate;binary98
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES <CA Name>,
o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
97 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
98 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
99 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and cRLIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
96
106764133
E-23
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.16 Non Government Component Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Authority key identifier100
Subject key identifier101
Key usage
Extended key usage
Private key usage period
Certificate policies
Policy Mapping
Subject Alternative Name
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points103
Component & Web Server Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES <CA Name>, o=ORC PKI, c=US
2 years from date of issue
cn=<Host URL | IP Address | Host Name>, ou=<Host Company Name>,
o=<Organization>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment, digitalSignature
Not Present
Not Present
c=no; {2 16 840 1 101 3 2 1 12 1}, id-fpki-common-devices::={2 16 840 1
101 3 2 1 3 6}
Not Present
c=no; always present, Host URL | IP Address | Host Name
Not Present
Not Present
Not Present
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES <CA Name>, o=ORC PKI, c=US?cacertificate;binary102
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES <CA Name>,
o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
101 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
102 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
103 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and cRLIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
100
106764133
E-24
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.17 Domain Controller Certificate
Field
Version
Serial Number
Issuer Signature Algorithm
Issuer Distinguished Name
Validity Period
Subject Distinguished Name
Subject Public Key Information
Issuer Unique Identifier
Subject Unique Identifier
Issuer’s Signature
Authority key identifier104
Subject key identifier105
Key usage
Extended key usage
Component & Web Server Certificate Value
V3 (2)
Must be unique
sha-1WithRSAEncryption
cn=ORC ACES <CA Name>, o=ORC PKI, c=US
3 years from date of issue
cn=<Host URL | IP Address | Host Name>, ou=<Host Company Name or
agency>, o=<Organization>, c=US
1024 bit RSA key modulus, rsaEncryption
Not Present
Not Present
sha-1WithRSAEncryption
c=no; octet string
c=no; octet string
c=yes; keyEncipherment, digitalSignature
c=yes; {id-pkix id-kp(3) id-kp-serverauth(1)}, {id-pkix id-kp(3) id-kpclientauth(2)}
id-pkix OBJECT IDENTIFIER ::=
Private key usage period
Certificate policies
Policy Mapping
Subject Alternative Name
Certificate Template
{1.3.6.1.4.1.311.20.2.3}
Issuer Alternative Name
Subject Directory Attributes
Basic Constraints
Name Constraints
Policy Constraints
Authority Information Access
CRL Distribution Points107
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
Not Present
c=no; {2 16 840 1 101 3 2 1 12 1}, id-fpki-common-devices::={2 16 840 1
101 3 2 1 3 6}
Not Present
c=no; DNS Name=<fully qualified computer name> e.g. orc-01.orc.com
Other Name=DC GUID {1.3.6.1.4.1.311.25.1}=<GUID of Dom Cntlr>
c=no; BMPString: DomainController; The actual extension value in HEX:
1E200044006F006D00610069006E0043006F006E00740072006F006C006C00650072
Not Present
Not Present
Not Present
Not Present
Not Present
c=no; ocsp=http://eva.orc.com, caIssuers=ldap://aces-ds.orc.com/ cn=ORC
ACES <CA Name>, o=ORC PKI, c=US?cacertificate;binary106
c=no; always present, ldap://aces-ds.orc.com/ cn=ORC ACES <CA Name>,
o=ORC PKI, c=US?cacertificate;binary
The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the signing CA’s public key
information.
105 The value of this field is the 20 byte SHA-1 hash of the binary DER encoding of the subject’s public key
information.
106 The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to
the CA that issued the certificate containing this extension.
107 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the
URI name form. The reasons and cRLIssuer fields shall not be populated. The CRL shall point to a full and complete
CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).
104
106764133
E-25
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.18 ORC Government Root CRL
Field
Version
Issuer Signature Algorithm
Issuer Distinguished Name
thisUpdate
nextUpdate
Revoked certificates list
CRL extensions
CRL Number
Authority Key Identifier
CRL entry extensions
Invalidity Date
Reason Code
Subordinate CA CRL Value
V2 (1)
sha-1WithRSAEncryption
cn=ORC Government Root, o=ORC PKI, c=US
UTCT
UTCT; thisUpdate + 360 days
0 or more 2-tuple of certificate serial number and revocation date (in
UTCT)
Integer
Octet String (20 byte SHA-1 hash of the binary DER encoding of the ACES
CA public key information)
present when received
Present if Reason is not Unspecified
E.19 ORC ACES CA CRL
Field
Version
Issuer Signature Algorithm
Issuer Distinguished Name
thisUpdate
nextUpdate
Revoked certificates list
CRL extensions
CRL Number
Authority Key Identifier
CRL entry extensions
Invalidity Date
Reason Code
106764133
Subordinate CA CRL Value
V2 (1)
sha-1WithRSAEncryption
cn=ORC ACES <CA Name>, o=ORC PKI, c=US
UTCT
UTCT; thisUpdate + 7 days
0 or more 2-tuple of certificate serial number and revocation date (in
UTCT)
Integer
Octet String (20 byte SHA-1 hash of the binary DER encoding of the ACES
CA public key information)
present when received
Present if Reason is not Unspecified
E-26
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
E.20 OCSP REQUEST FORMAT
OCSP requests are not required to be signed. See RFC2560 for detailed syntax. The following
table lists which fields are provided by the ORC CSA OCSP Responder.
Field
Version
Requester Name
Request List
Signature
Extensions
Expected Value
V1 (0)
Not Required
List of certificates – generally this should be the list of two certificates:
ECA certificate and end entity certificate
Not Required
Not Required
E.21 OCSP Response Format
See RFC2560 for detailed syntax. The following table lists which fields are populated by an
OCSP Responder.
Field
Response Status
Response Type
Version
Responder ID
Produced At
List of Responses
Extension
Nonce
Signature Algorithm
Signature
Certificates
Expected Value
Successful | Malformed Request | Internal Error | Try Later
id-pkix-ocsp-basic {1 3 6 1 5 5 7 48 1 1}
V1 (0)
Hash of Responder public key
Generalized Time
Each response will contain certificate id; certificate status108, thisUpdate,
nextUpdate109,
Will be present if nonce extension is present in the request
sha-1WithRSAEncryption {1 2 840 113549 1 1 5}
Present
Applicable certificates issued to the OCSP Responder
108
If the certificate is revoked, the OCSP Responder will provide revocation time and revocation reason from CRL
entry and CRL entry extension.
109 The OCSP Responder will use thisUpdate and nextUpdate from CA CRL.
106764133
E-27
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Appendix F: Security Officer Appointment Letter
14 December 2000
From:
To:
Subject:
Daniel E. Turissini, President
Robert C. Eves
ACES Corporate Security Auditor Designation
In accordance with the requirements of the System Security Plan (SSP) for Operational Research
Consultants, Inc. (ORC) Access Certificates for Electronic Services (ACES), you are hereby
designated the ORC Corporate Security Auditor. In accordance with the SSP, the responsibilities
of Corporate Security Auditor are as follows:
To assign responsibility for security of the ORC ACES Certificate Authority to an individual
knowledgeable in the nature and processes supported and the management, personnel,
operational, and technical controls used to protect it;
To assure that effective security products and techniques are appropriately used in support of the
ORC ACES Certificate Authority;
To direct that he/she shall be contacted when a security incident occurs concerning the ORC
ACES Certificate Authority;
To direct the day-to-day management of the ORC ACES Certificate Authority; and,
To coordinate all security-related interactions among organizational elements involved in the
ORC ACES Certificate Authority program, as well as those external to ORC.
//signed//
Daniel E. Turissini
President
106764133
F-1
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Appendix G: References
The following documents contain information that provides background, examples, or details
about the contents of this policy.
Number
Title
Revision
Date
OMB
Circular
No. A-123
ABADSG
Digital Signature Guidelines
1 August
1996
http://www.abanet.org/scitech/ec/isc/dsgfree.html
FIPS140
Security Requirements for Cryptographic Modules
21 May
2001
http://csrc.nist.gov/publications/index.html
FIPS112
Password Usage
5 May 1985
http://csrc.nist.gov/
FIPS186-2
Digital Signature Standard
20 January
2000
http://csrc.nist.gov/fips/fips186-2.pdf
FOIAACT
5 U.S.C. 552, Freedom of Information Act
http://www4.law.cornell.edu/uscode/5/552.html
FPKI-Prof
Federal PKI Certificate and CRL Extensions Profile
31 May
2002
http://csrc.nist.gov/pki/
FWPP
U.S. Department of Defense Traffic-FilterFirewall
Protection Profile for Medium Robustness Environments
Version
1.4
1 May 2000
Version
1.4
4 February
2002
http://www.iatf.net
IDSPP
Intrusion Detection System Protection
http://www.iatf.net
ISO9594-8
106764133
Information Technology – Open Systems Interconnection –
The Directory: Authentication Framework
G-1
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
1997
DRAFT
Number
Title
Revision
Date
ftp://ftp.bull.com/pub/OSIdirectotry/ITU/97x509final.doc
ITMRA
40 U.S.C. 1452, Information Technology Management
Reform Act
http://www4.law.cornell.edu/uscode/40/1452.html
NAG69C
Information System Security Policy and Certification
Practice Statement for Certification Authorities,
Revision
C
November
1999
NS4009
NSTISSI 4009, National Information Systems Security
Glossary
January
1999
NSD42
National Policy for the Security of National Security
Telecom and Information Systems
5 July 1990
http://snyside.sunnyside.com/cpsr/privacy/computer_secur
ity/nsd_42.txt (redacted version)
PKCS-1
PKCS #1 v2.0: RSA Cryptography Standard
1 October
1998
http://www.rsa,com
PKCS-12
Personal Information Exchange Syntax Standard
April 1997
http://www.rsa.com/rsalabs/pubs/PKCS/html/pkcs-12.html
ACES CP
Revised Certificate Policy For Access Certificates for
Electronic Services
6 May ,
2004
Common
Policy
Framework
CP
X.509 Certificate Policy for the Common Policy
Framework
21December
2003
ECAKRP
Key Recovery Policy for External Certification Authorities
RFC2510
Certificate Management Protocol, Adams and Farrell
Version
1.0
4 June 2002
March 1999
http://www.ietf.org/rfc/rfc2510.txt
RFC2527
Certificate Policy and Certification Practices Framework,
Chokhani and Ford
March 1999
http://www.ietf.org/rfc/rfc2527.txt
106764133
G-2
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Number
SDN702
Title
Revision
SDN.702, Abstract Syntax for Utilization with Common
Security Profile (CSP), Version 3 X.509 Certificates and
Version 2 CRLs
Revision
3
Date
31 July
1997
http://www.armadillo.Huntsville.al.us/Forteza_docs/sdn70
2rev3.pdf
ORC SSP
Operational Research Consultants, Inc. Secure Network
Operations Center System Security Plan (SSP)
February
2004
ORC PPP
Operational Research Consultants, Inc. Privacy Policies
and Procedures (PPP)
February
2004
ORC KRPS
Key Recovery Practice Statement for External
Certification Authorities
106764133
G-3
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Appendix H: Glossary
ACES. Access Certificates for Electronic Services. This is a project of GSA’s Office of
Government wide Policy (OGP) and Federal Technology Service (FTS) that is aimed at
providing commercial public key certificate services to the American public.
ACES Certificates. Certificates issued by an Authorized CA in accordance with this
CPS, which certificates reference this CPS by inclusion of the ACES OID.
ACES CPS. An ACES CPS is a certification practice statement of the practices that an
Authorized CA employs in issuing, suspending, and revoking ACES Certificates and
providing access to the same.
Agency. A term used to identify all federal agencies, authorized federal contractors,
agency-sponsored universities and laboratories, and, when authorized by law or
regulation, state, local, and tribal Governments.
Agency Applications. See “Qualified Relying Party.”
Authenticate. Relates to a situation where one party has presented an identity and claims
to be that identity. Authentication enables another party to gain confidence that the claim is
legitimate.
Authorized CA. A certification authority that has been authorized by GSA to issue
ACES Certificates and provide Authorized CA Services.
Authorized CA Services. The services relating to ACES Certificates to be provided by
Authorized CAs (See Section 2.1.1).
Certificate Authority Administrator - A Certificate Authority Administrator (CAA) is
an individual who is the responsible party for a CA. The CAA possesses the private key
of the CA’s certificate. The CAA may be collocated with the CA, but may also perform
administration tasks remotely.
Certificate Policy - A Certificate Policy is a document that defines the policy
requirements that must be met by any CA implemented under the policy.
Certificate Practice Statement - A Certificate Practice Statement (CPS) is a document
which details the requirements and procedures that are followed by a CA in issuing and
maintaining certificates, and the purposes and allowed uses of those certificates.
Certificate. A data record that, at a minimum: (a) identifies the Authorized CA issuing
it; (b) names or otherwise identifies its subscriber; (c) contains a public key that
corresponds to a private key under the control of the subscriber; (d) identifies its
operational period; and (e) contains an ACES Certificate unique serial number and is
digitally signed by the Authorized CA issuing it. As used in this CPS, the term of
“Certificate” refers to certificates that expressly reference the OID of this CA in the
“Certificate Policies” field of an X.509 v.3 certificate.
106764133
H-1
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Certificate Management System (CMS). Netscape Certificate Management System
provides a highly scalable, easily deployable certificate infrastructure for supporting
encryption, authentication, tamper detection, and digital signatures in networked
communications. It is based on open standards and protocols such as Public-Key
Cryptography Standard (PKCS) #7, 10, 11, and 12, Secure Sockets Layer (SSL),
Lightweight Directory Access Protocol (LDAP), and the X.509 certificate formats
recommended by the International Telecommunications Union (ITU). Certificate
Management System is highly customizable and configurable, permitting rapid
integration with existing client and server software, customer databases, security
systems, and authentication procedures.
Certificate Manufacturing Authority (CMA). An entity that is responsible for the
manufacturing and delivery of ACES Certificates signed by an Authorized CA, but is not
responsible for identification and authentication of certificate subjects (i.e., a CMA is an
entity that is delegated or outsourced the task of actually manufacturing the Certificate
on behalf of an Authorized CA).
Certificate Practice Statement (CPS). A Certification Practice Statement is a
statement of the practices that a certification authority employs in issuing, suspending,
revoking, and renewing certificates and providing access to same, in accordance with
specific requirements (i.e., requirements specified in this CPS, requirements specified in
a contract for services).
Certificate Repository. A certificate repository is a system that holds certificates and
information about all active certificates including revocation information.
Certificate Revocation List. A Certificate Revocation List (CRL) is a list of certificates
that have been revoked but have not yet expired. A CRL should be digitally signed by
the CA to ensure its validity to relying parties.
Certification Authority. A certification authority is an entity that is responsible for
authorizing and causing the issuance of a Certificate. The actual certificate is from the
CMA.
Digital Certificate. A digital certificate is electronic information that indicates the
identity of the subscriber, the identity of the issuing CA, the operational period of the
certificate, and the public key of the subscriber. The certificate is digitally signed by the
issuing CA to show validity.
Digital Signature. A digital signature is a string of bits associated with a collection of
data (e.g., a file, document, message, transaction); this string of bits can only be
generated by the holder of a private key, but can be verified by anyone with access to the
corresponding public key. Note that some algorithms include additional steps (e.g., oneway hashes, timestamps) in this basic process.
End Entity. An end entity is any individual or server who holds a digital certificate.
See also subscriber.
Federal Information Processing Standards (FIPS). These are Federal standards that
prescribe specific performance requirements, practices, formats, communications
106764133
H-2
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
protocols, etc. for hardware, software, data, telecommunications operation, etc. Federal
agencies are expected to apply these standards as specified unless a waiver has been
granted in accordance to agency waiver procedures.
Government. Federal Government and authorized agencies and entities.
Hypertext Transfer Protocol over SSL (HTTPS). HTTPS is the use of Secure Socket
Layer (SSL) for data transfer via the World Wide Web. HTTPS uses port 443 instead of
HTTP port 80 in its interactions with the lower layer, TCP/IP. SSL uses a 128-bit key
size for the RC4 stream encryption algorithm, which is considered an adequate degree of
encryption for commercial exchange.
Identity Proofing. Method used for verifying the information provided on subscriber
application.
Internet Engineering Task Force (IETF). The Internet Engineering Task Force is a
large open international community of network designers, operators, vendors, and
researches concerned with the evolution of the Internet architecture and the smooth
operation of the Internet.
Issuing Authority. An Issuing Authority (IA) is an individual who is responsible for
granting certificate requests. There can be multiple IAs for a single CA. IAs can be
collocated with the subscribers requesting certificates, but can also issue certificates
remotely.
Key Changeover. The procedure used by an Authority to replace its own private key
(e.g., due to compromise) and replace current valid certificates issued with old key.
Key pair. Means two mathematically related keys, having the properties that (1) one
key can be used to encrypt a message that can only be decrypted using the other key, and
(2) even knowing one key, it is computationally infeasible to discover the other key.
Mutual Authentication. Parties at both ends of a communication activity authenticate
each other (see authentication).
Object Identifier (OID). An object identifier is a specially formatted number that is
registered with an internationally recognized standards organization.
Operational Period of an ACES Certificate. The operational period of an ACES
Certificate is the period of its validity. It would typically begin on the date the certificate
is issued (or such later date as specified in the certificate), and ends on the date and time
it expires as noted in the certificate.
Out-of-band. Communication between parties utilizing a means or method that differs
from the current method of communication (e.g., one party using U.S. Postal mail to
communicate with another party where current communication is online communication).
Policy Authority. The entity specified in Section 1.4 (the General Services
Administration).
106764133
H-3
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Private Key. The key of a key pair used to create a digital signature. This key must be
kept a secret.
Program Participants. Collectively, the Authorized CAs, Registration Authorities,
Certificate Manufacturing Authorities, Repositories, subscribers, Qualified Relying
Parties, and Policy Authority authorized to participate in the public key infrastructure
defined by this CPS.
Public Key. The key of a key pair used to verify a digital signature. The public key is
made freely available to anyone who will receive digitally signed messages from the
holder of the key pair. The public key is usually provided via an ACES Certificate
issued by an Authorized CA and is often obtained by accessing a repository. A public
key is used to verify the digital signature of a message purportedly sent by the holder of
the corresponding private key.
Public Key Infrastructure. A Public Key Infrastructure (PKI) is a system of policies,
CAs, certificates, information repositories, and trusted individuals, that is used to verify
and authenticate individuals and servers, and to encrypt and decrypt information
exchanged by these individuals and servers
Qualified Relying Party. A recipient of a digitally signed message who is authorized
by this CPS to rely on an ACES Certificate to verify the digital signature on the message.
Registration Authority (RA). An entity that is responsible for identification and
authentication of certificate subjects, and issues certificates (i.e., a Registration
Authority is delegated certain tasks on behalf of an Authorized CA). The RA functions
(verify and issue) can be split between the IA and LRA.
Relying Party. A relying party is any entity that relies on digital certificate credentials.
See also Qualified Relying Party.
Repository. A database containing information and data relating to certificates, and an
Authorized CA, as specified in this CPS.
Responsible Individual. A trustworthy person designated by a Sponsoring Organization
to authenticate individual applicants seeking certificates on the basis of their affiliation
with the sponsor.
Revoke a Certificate. Means to prematurely end the operational period of a Certificate
from a specified time forward.
Secure Sockets Layer. A protocol for providing data security layered between
application protocols (such as HTTP, Telnet, NNTP, or FTP) and TCP/IP. This security
protocol supports data encryption, server authentication, message integrity, and optional
client authentication for a TCP/IP connection.
Sponsoring Organization. A business entity, government agency, or other organization
with which a Business Representative is affiliated (e.g., as an employee, agent, member,
user of a service, business partner, customer, etc.).
106764133
H-4
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT
Subscriber. A subscriber is a person who (1) is the subject named or identified in an
ACES Certificate issued to such person and (2) holds a private key that corresponds to a
public key listed in that certificate, and (3) the person to whom digitally signed messages
verified by reference to such certificate are to be attributed.
Suspend a Certificate. Means to temporarily suspend the operational period of a
Certificate for a specified time period or from a specified time forward.
Trustworthy System. Means computer hardware, software, and procedures that: (a) are
reasonably secure from intrusion and misuse; (b) provide a reasonable level of
availability, reliability, and correct operation; (c) are reasonably suited to performing
their intended functions, and (d) adhere to generally accepted security procedures.
Valid Certificate. Means an ACES Certificate that (1) an Authorized CA has issued, (2)
the subscriber listed in it has accepted, (3) has not expired, and (4) has not been revoked.
Thus, an ACES Certificate is not “valid” until it is both issued by an Authorized CA and
has been accepted by the subscriber.
106764133
H-5
 Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
DRAFT