Operational Research Consultants, Inc.
(ORC)
External Certification Authority
(ECA)
Certification Practice Statement
Summary Version 2.1
May 13, 2004
This Page intentionally left blank.
ã Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
This document is proprietary and may not be disclosed to other parties, be it pursuant to the Freedom of Information Act or to any other law or regulation.
ORC ECA CPS Summary Version 2.1
TABLE OF CONTENTS
1 Introduction 1
1.1 Overview 1
1.2 Identification 3
1.3 Community and Applicability 3
1.3.1 Certificate Management Authorities under the ORC ECA 3
1.3.2 Trusted Agents 4
1.3.3 Related Authorities 6
1.3.4 End Entities 6
1.3.5 Applicability 7
1.4 Contact Details 10
1.4.1 Specification Administration Organization 10
1.4.2 Contact Personnel 10
2 GENERAL PROVISIONS 11
2.1 Obligations 11
2.1.1 ECA Obligations 11
2.1.2 IA Obligations 12
2.1.3 RA Obligations 12
2.1.4 LRA Obligations 13
2.1.5 Trusted Agent Obligations 14
2.1.6 Subscriber Obligations 14
2.1.7 Server Certificate Subscriber Obligations 14
2.1.8 Code Signer Attribute Authority 15
2.1.9 Code Signer Certificate Subscriber Obligations 16
2.1.10 Relying Party Obligations 17
2.1.11 Repository Obligations 18
2.1.12 Certificate Status Authority Obligations 19
2.2 Liability 19
2.2.1 Warranties and Limitations On Warranties 19
2.2.2 Damages Covered and Disclaimers 20
2.2.3 Loss Limitations 20
2.2.4 Other Exclusions 20
2.2.5 US Federal Government Liability 21
2.3 Financial Responsibility 21
2.3.1 Indemnification By Relying Parties and Subscribers 21
2.3.2 Fiduciary Relationships 21
2.3.3 Administrative Processes 21
2.4 Interpretation and Enforcement 22
2.4.1 Governing Law 22
2.4.2 Severability of Provisions, Survival, Merger, and Notice 22
2.4.3 Dispute Resolution Procedures 22
2.5 Fees 23
2.5.1 Certificate Issuance or Renewal Fees 23
2.5.2 Certificate Access Fees 23
2.5.3 Revocation or Status Information Access Fees 23
2.5.4 Fees for Other Services Such as Policy Information 23
2.6 Publication and Repository 24
2.6.1 Publication of ORC ECA Information 24
2.6.2 Frequency of Publication 24
2.6.3 Access Controls 24
2.6.4 Repositories 25
2.7 Compliance Audit 25
2.7.1 Frequency of Entity Compliance Audit 25
2.7.2 Identity / Qualifications of Compliance Auditor 26
2.7.3 Compliance Auditor’s Relationship to Audited Party 26
2.7.4 Topics Covered by Compliance Audit 26
2.7.5 Actions Taken as a Result of Deficiency 26
2.7.6 Communication of Results 27
2.8 Confidentiality 27
2.8.1 Types of Information to be Protected 27
2.8.2 Information Release Circumstances 28
2.9 Intellectual Property Rights 29
3 IDENTIFICATION AND AUTHENTICATION 30
3.1 Initial Registration 30
3.1.1 Types of Names 30
3.1.2 Need for Names to be Meaningful 30
3.1.3 Rules for Interpreting Various Name Forms 31
3.1.4 Uniqueness of Names 31
3.1.5 Name Claim Dispute Procedure 31
3.1.6 Recognition, Authentication and Role of Trademarks 31
3.1.7 Method to Prove Possession of Private Key 32
3.1.8 Authentication of Organizational Identity 32
3.1.9 Authentication of Individual Identity 32
3.1.10 Code Signer Authentication 34
3.1.11 Authentication of Component Identities 35
3.2 Certificate Renewal, Update, and Routine Re-Key 36
3.2.1 Certificate Re-Key 36
3.2.2 Certificate Renewal 37
3.2.3 Certificate Update 37
3.3 Obtaining a new Certificate After Revocation 38
3.4 Revocation Request 38
4 OPERATIONAL REQUIREMENTS 39
4.1 Certificate Application 39
4.1.1 Delivery of Subscriber’s Public Key to Certificate Issuer 40
4.1.2 Validation of Request 41
4.2 Certificate Issuance 41
4.2.1 Delivery of Subscriber’s Private Key to Subscriber 42
4.2.2 CA Public Key Delivery to Users 42
4.3 Certificate Acceptance 42
4.4 Certificate Suspension and Revocation 43
4.4.1 Revocation 43
4.4.2 Suspension 46
4.4.3 Certificate Revocation Lists 46
4.4.4 On-line Revocation/Status Checking 47
4.4.5 Other Forms of Revocation Advertisements Available 47
4.4.6 Special Requirements With Respect to Key Compromise 47
4.5 Security Audit Procedures 47
4.6 Records Archival 48
4.7 ECA Key Changeover 48
4.8 Compromise and Disaster Recovery 48
4.9 CA Termination 49
5 PHYSICAL, PROCEDURAL AND PERSONNEL SECURITY CONTROLS 50
5.1 Physical Controls 50
5.2 Procedural Controls 50
5.2.1 External Trusted Roles 50
5.2.2 Separation of Roles 51
5.3 Personnel Controls 51
5.3.1 Background, Qualifications, Experience and Clearance Requirements 51
5.3.2 Background Check Procedures 52
5.3.3 Training Requirements 52
5.3.4 Retraining Frequency and Requirements 52
5.3.5 Job Rotation Frequency and Sequence 52
5.3.6 Sanctions for Unauthorized Actions 52
5.3.7 Contracting Personnel Requirements 53
5.3.8 Documentation Supplied to Personnel 53
6 TECHNICAL SECURITY CONTROLS 54
6.1 Key Pair Generation and Installation 54
6.1.1 Key Pair Generation 54
6.1.2 Private Key Delivery to Subscriber 54
6.1.3 Public Key Delivery to Certificate Issuer 54
6.1.4 CA Public Key Delivery to Users 54
6.1.5 Key Sizes 55
6.1.6 Public Key Parameters Generation 55
6.1.7 Parameter Quality Checking 55
6.1.8 Hardware/Software Key Generation 55
6.1.9 Key Usage Purposes (X.509 V3 Key Usage Field) 55
6.2 Private Key Protection 56
6.2.1 Standards for Cryptographic Modules 56
6.2.2 Private Key Multi-person Control 56
6.2.3 Private Key Escrow 57
6.2.4 Private Key Backup 57
6.2.5 Private Key Archival 57
6.2.6 Private Key Entry Into Cryptographic Module 58
6.2.7 Method of Activating Private Key 58
6.2.8 Method of Deactivating Private Key 58
6.2.9 Method of Destroying Private Key 59
6.3 Other Aspects of Key Pair Management 59
6.4 Activation Data 59
6.4.1 Activation Data Installation and Generation 59
6.4.2 Activation Data Protection 59
6.4.3 Other Aspects of Activation Data 60
6.5 Computer Security Controls 60
6.6 Life Cycle Technical Controls 60
6.6.1 Development Environment Security 60
6.6.2 Configuration Management Security 60
6.7 Network Security Controls 60
6.8 Cryptographic Module Engineering Controls 61
7 CERTIFICATE AND CRL PROFILES 62
7.1 CERTIFICATE PROFILE 62
7.1.1 Version Numbers 62
7.1.2 Certificate Extensions 62
7.1.3 Algorithm Object Identifiers 62
7.1.4 Name Forms 63
7.1.5 Name Constraints 63
7.1.6 Certificate Policy Object Identifier 63
7.1.7 Usage of Policy Constraints Extension 63
7.1.8 Policy Qualifiers Syntax and Semantics 63
7.1.9 Processing Semantics for the Critical Certificate Policy Extension 63
7.2 CRL PROFILE 64
7.2.1 Version Numbers 64
7.2.2 CRL and CRL Entry Extensions 64
7.3 OCSP Request – Response Format 64
8 Certificate policy ADMINISTRATION 65
8.1 Specification Change Procedures 65
8.2 Publication and Notification Procedures 65
8.3 CPS and External Approval Procedures 65
APPENDIX A: Certificate And CRL Formats A.1
APPENDIX B: ElEments of Key Recovery Policy and Practices B.1
Appendix C: REFERENCES C.1
Appendix D: ACRONYMS AND ABBREVIATIONS D.1
Appendix E: IDENTITY PROOFING OF HOST NATIONALS E.1
i
ã Copyright 2004, Operational Research Consultants, Inc.
All Rights Reserved
This document is proprietary and may not be disclosed to other parties, be it pursuant to the Freedom of Information Act or to any other law or regulation.
ORC ECA CPS Summary Version 2.1
1 Introduction
This External Certification Authority (ECA) Certification Practice Statement (CPS) describes the establishment and operation of an ECA in support of the Department of Defense (DoD) Public Key Infrastructure (PKI) and the policies and procedures relating to holding or using certificates issued by the Operational Research Consultants, Incorporated (ORC) ECA. This CPS is applicable to all agencies and individuals that will be interacting with ORC and the ORC ECA, including DoD activities, other government agencies, and associated individuals and contractors. The purpose of this CPS is to inform individuals relying (Relying Parties) on Certificates issued by ORC and Subscribers (holders of ORC certificates) of their duties and obligations. It is also to advise those parties of the policies, practices and procedures that ORC uses for issuing, validating and revoking ORC ECA certificates. This CPS is structured in accordance with Request For Comment (RFC) 2527 of the Internet Engineering Task Force (IETF).
This CPS has been written by ORC in response to the United States (US) Government Certificate Policy (CP) for External Certification Authorities (ECA), Version 3.0, dated April 5, 2004. The US Government ECA CP takes precedence in any policy discrepancies. In the event that a provision of this CPS conflicts with a written, signed agreement, that provision of the written agreement or CP shall take precedence over this CPS, in that order.
This CPS describes all components, software, and procedures to:
· Install, operate and maintain the ORC ECA
· Request, issue, publish, revoke and recover certificates under the ORC ECA
· Protect the ORC ECA
· Verify validity of ORC ECA certificates
1.1 Overview
DoD recognizes the need to interoperate with individuals outside of the DoD domain and has a requirement to establish trust relationships with other Certification Authorities (CAs) that achieve a satisfactory assurance level. These “external” CAs will provide non-DoD personnel with certificate services that are interoperable with the DoD PKI.
This CPS applies to X.509 version 3 certificates with assurance levels as defined in the US Government ECA CP, as used to protect information up to and including Sensitive But Unclassified (SBU). The practices 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.
The ORC ECA has been established as a subordinate CA to the US Government ECA Root CA. The ORC ECA will continue to allow rapid support certification services to US Government contractors that are supporting specified programs currently requiring or will require PKI support. This CPS is the implementation document for the ORC ECA for the purpose of issuing certificates to individuals, contractor personnel and Foreign Nationals requiring access to government resources. The CPS describes the operations of the ORC ECA and the services that the ORC provides. These services include:
· Subscriber Registration: A subscriber or certificate applicant must appear in person before 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 ECA Policy Management Authority (EPMA), Issuing Authority (IA), approved Registration Authority (RA) or Local Registration Authority (LRA) and present valid government issued identification (driver’s license, passport, etc) and sign a responsibilities letter and mail the forms to ORC
· Subscriber Enrollment: The ORC ECA provides a 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 subscriber enrollment information is validated by the ORC ECA registration process (see above)
· Certificate Issuance: When notified by an RA of a valid enrollment request and approved by an ORC IA, the ORC ECA will issue the requested certificate to a FIPS 140-1/2 level 1 or 2 client. A FIPS 140-1 level 1 issuance does not require issuance to a token. The IA or RA will notify the subscriber of the issuance and provide instructions for receiving the certificate
· Certificate Publishing: When a certificate is issued, the ORC ECA will publish it to a Lightweight Directory Access Protocol (LDAP) directory. The directory may be accessed via a Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) gateway or via the LDAP protocol
· Encryption Key Storage: Optional storage of encryption keys
· Key Recovery: If encryption key storage is selected, refer to the ORC ECA Key Recovery Practice Statement (KRPS) for details
· 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 web site, which contains instructions, on-line forms, a summary of this CPS, compliance audit results, and copies of certificates and CRLs. The majority of the information on the web site 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 web site are access controlled and require certificate authentication for access to authorized individuals.
The ORC ECA is periodically audited by its independent auditor against this CPS and operates primary and secondary secure data centers in conformance with DoD, National Security Agency (NSA), US General Services Administration (GSA) and commercial practices.
1.2 Identification
ORC operates the ECA in a manner consistent with the practices established in the US Government ECA CP. Certificates created by the ORC ECA assert the policy Object Identifier (OID) for two levels of assurance as specified in the ECA Root CP:
id-eca-medium ::= {id-eca-policies}.1
id-eca-medium-hardware::= {id-eca-policies}.2
Where {id-certificate-policy} represents the prefix:
2{joint-iso-ccitt}.16{country}.840{us}.1{organization}.101{gov}.3{csor}.2{pki}.1{cert-policy}.12{eca-policies}
or, “2.16.840.1.101.3.2.1.12”
ORC ECA certificates contain one of the above policy OIDs. The ORC ECA and this CPS support the medium and medium-hardware assurance levels defined in the US Government ECA CP.
1.3 Community and Applicability
The ORC ECA supports non-DoD entities transacting electronic business with or for US Government entities. ORC ECA Subscribers may include contractors, vendors, allied partners, North Atlantic Treaty Organization (NATO) allies, Foreign Nationals, members of other Government agencies and their trading partners.
1.3.1 Certificate Management Authorities under the ORC ECA
Under this CPS the ORC ECA, Certificate Authority Administrators (CAAs), and IAs are considered “Certificate Management Authorities” (CMAs) and are the only authorities with direct trusted access to the ORC ECA application and keys. This CPS will use the term CMA when a function may be assigned to the ORC ECA, a CAA, or an IA, or when a requirement applies to the ORC ECA, CAAs and IAs. The division of Subscriber registration responsibilities between the ORC ECA, CAAs and RAa may vary among implementations of this certificate policy. This division of responsibilities is described in this CPS. ORC server based Certificate Status Authorities (CSAs) are also considered CMAs. This CPS ensures that all CMAs are in compliance with the US Government ECA CP.
1.3.1.1 Certification Authorities
The ORC ECA is a subscriber to the off-line US Government ECA Root CA. The US Government ECA Root CA has signed the ORC ECA signing certificate rendering the ORC ECA a subordinate of the “superior” US Government ECA Root CA. The ORC ECA generates and manages certificates and certificate revocation. It posts those certificates and CRLs to an LDAP directory. A CAA, as defined herein, administers the ORC ECA. CAAs are the only authorities authorized to administer the ORC ECA application. CAAs are designated directly by ORC’s President. ORC CAAs designate IAs and RAs and perform tasks required for CA/ CRL management.
1.3.1.2 Issuing Authorities
IAs are the only authorities authorized to approve the issuance of ORC ECA certificates. IAs approves the issuance of certificates to end entities upon receipt of an identity validation, digitally signed by an authorized RA. IAs 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 certificate issuing and in the practices and processes of this CPS prior to being issued IA certificates. IA duties are a primary job responsibility for these individuals. ORC IAs are employees of ORC or subcontract personnel only. ORC IAs approve the issuance of ORC ECA certificates by accessing the ECA from an ORC IA workstation that securely communicates with the ECA.