Government of Ontario Public Key Infrastructure …...Government of Ontario Public Key Infrastructure Preface Certificate Policy Version 3.2 November 17, 2008 Page ii Revision Control

Government of Ontario Public Key Infrastructure

Certificate Policy

Version: 3.2 (Final)

Issue Date: November 17, 2008

Corporate Security Branch Ministry of Government Services

Government of Ontario

Government of Ontario Public Key Infrastructure Preface Certificate Policy

Version 3.2 November 17, 2008 Page ii

Revision Control

Document Title: Certificate Policy for the Government of Ontario Public Key

Infrastructure (GO-PKI CP) Document Owner: Corporate Security Branch, Manager, Security Policy Document Version: Version 3.2 (Final) Document Release Date: November 17, 2008 Project: Government of Ontario Public Key Infrastructure (GO-PKI) Filename: Date Initials Description 1 March 2002 Sylvain Bigras First draft 13 March 2002 Karen Nemani

Sylvain Bigras Carl Rajack

First review

5 May 2002 Karen Nemani Carl Rajack Earl Kuntz Graham Stubbs Sylvain Bigras

Second Review

17 May 2002 Carl Rajack Sylvain Bigras

Third Review, minor typographical, wording changes and omissions from the Second Review

March 2008 Terry Sexsmith Re-formatted the previous version (July 2005) to RFC 3647

April 15, 2008 Pat Antliff Terry Sexsmith Earl Kuntz Bata Spasic Alberto Abes

Revised content to include sections as a result of RFC 3647.

May 25, 2008 Pat Antliff Revisions to provide document references and policy mapping for cross certification

June 17, 2008 Pat Antliff Tim Dafoe

Align policy section on cryptography with GO-ITS Cryptography policy (Draft)


Version 3.2 November 17, 2008 Page iii

Table of Contents

1 PREFACE .........................................................................................................................................1-1

CHAPTER 1 – PKI POLICY .................................................................................................................1-1

1 INTRODUCTION................................................................................................................................1-1 2 FOUNDATION FOR THE GO-PKI POLICY .........................................................................................1-1

2.1 Concept of Operations .............................................................................................................1-1 2.2 Governance..............................................................................................................................1-2 2.3 PKI Interoperability Framework .............................................................................................1-4 2.4 Earlier Policy Work .................................................................................................................1-4

3 GO-PKI OVERVIEW ........................................................................................................................1-4 3.1 Need for a Public Key Infrastructure.......................................................................................1-4 3.2 PKI in the Government of Ontario...........................................................................................1-5

3.2.1 Enhanced PKI Model ......................................................................................................................................1-5 3.2.2 Subscriber Registration ...................................................................................................................................1-5 3.2.3 Enrollment Within a Consistent Use Domain .................................................................................................1-6 3.2.4 Subscribers......................................................................................................................................................1-6 3.2.5 Maintaining Assurance and Trust ...................................................................................................................1-6

4 GO-PKI POLICY ..............................................................................................................................1-7 4.1 Policy Titles .............................................................................................................................1-7 4.2 Policy Objective.......................................................................................................................1-7 4.3 Policy Statement ......................................................................................................................1-7 4.4 Application...............................................................................................................................1-8 4.5 Effective Date...........................................................................................................................1-8 4.6 Roles and Responsibilities .......................................................................................................1-8

4.6.1 Policy Management Authority ........................................................................................................................1-8 4.6.2 Operational Authority .....................................................................................................................................1-8 4.6.3 Certification Authorities..................................................................................................................................1-8 4.6.4 Registration Authority.....................................................................................................................................1-8 4.6.5 Head LRA.......................................................................................................................................................1-9 4.6.6 LRA Administrators........................................................................................................................................1-9 4.6.7 Subscribers......................................................................................................................................................1-9 4.6.8 Relying Parties ................................................................................................................................................1-9 4.6.9 Sponsor ...........................................................................................................................................................1-9 4.6.10 Program Managers ........................................................................................................................................1-10 4.6.11 Program managers manage the use of certificates, keys, role identifiers, and attributes within their area of responsibility. Custodians of Information and Information Technology ........................................................................1-10

4.7 Accountability ........................................................................................................................1-10 4.8 Application Requirements......................................................................................................1-10

4.8.1 CA Applications............................................................................................................................................1-10 4.8.2 Ministries, agencies and the BPSBusiness Applications ...............................................................................1-10

4.9 Outsourcing ...........................................................................................................................1-10 5 INTEROPERABILITY STANDARD ....................................................................................................1-11

5.1 Introduction ...........................................................................................................................1-11 5.2 Recognition Agreements ........................................................................................................1-11 5.3 Convention .............................................................................................................................1-12 5.4 PKI Architecture ....................................................................................................................1-12 5.5 Trust Relationships ................................................................................................................1-13 5.6 Community .............................................................................................................................1-14

5.6.1 Policy Management Authority ......................................................................................................................1-14


Version 3.2 November 17, 2008 Page iv

5.6.2 Root Certification Authority .........................................................................................................................1-14 5.6.3 Certification Authority ..................................................................................................................................1-15 5.6.4 Registration Authority...................................................................................................................................1-15 5.6.5 Subscriber .....................................................................................................................................................1-15 5.6.6 Relying Party ................................................................................................................................................1-15 5.6.7 Sponsor .........................................................................................................................................................1-15

5.7 Interoperability Management Operations .............................................................................1-15 5.7.1 Request..........................................................................................................................................................1-15 5.7.2 Issuance.........................................................................................................................................................1-15 5.7.3 Renewal ........................................................................................................................................................1-16 5.7.4 Revocation ....................................................................................................................................................1-16 5.7.5 Recovery .......................................................................................................................................................1-16 5.7.6 Termination...................................................................................................................................................1-16

5.8 Certification Authority Requirements ....................................................................................1-16 5.8.1 Certificate Policy Standard ...........................................................................................................................1-16 5.8.2 On-line Revocation and Status Checking Availability ..................................................................................1-17 5.8.3 Network Infrastructures ................................................................................................................................1-17 5.8.4 Operational Requirements.............................................................................................................................1-17

5.9 Relying Party Obligations .....................................................................................................1-18 5.9.1 Use of CA Certificates and Cross-certificates for Appropriate Purpose........................................................ 1-18 5.9.2 Verification Responsibilities .........................................................................................................................1-18 5.9.3 Revocation Check Responsibility .................................................................................................................1-18

5.10 PKI Client Application Requirements ................................................................................1-18 5.10.1 Certificate Profile..........................................................................................................................................1-18 5.10.2 ARL Profile...................................................................................................................................................1-19 5.10.3 Validation......................................................................................................................................................1-19

5.11 Agreements .........................................................................................................................1-19 5.11.1 CA Certification and Intra-Domain Cross-Certification ...............................................................................1-19 5.11.2 Inter-Domain Cross-Certification .................................................................................................................1-19

5.12 Process ...............................................................................................................................1-20 5.12.1 CA Certification and Intra-Domain Cross-Certification ...............................................................................1-20 5.12.2 Inter-Domain Cross-Certification .................................................................................................................1-21

6 USING THE GO-PKI CERTIFICATE POLICY ...................................................................................1-22 6.1 Scope......................................................................................................................................1-22 6.2 Structure ................................................................................................................................1-23 6.3 Ministries, agencies and the BPS...........................................................................................1-23 6.4 Program Managers................................................................................................................1-23 6.5 Custodians .............................................................................................................................1-23 6.6 GO-PKI Policy Management Authority.................................................................................1-23 6.7 GO-PKI Operational Authority .............................................................................................1-23

7 INQUIRIES ......................................................................................................................................1-24

CHAPTER 2 – GO-PKI CERTIFICATE POLICY ............................................................................ 2–1

1 INTRODUCTION ......................................................................................................................... 2–1 1.1 Overview ................................................................................................................................. 2–2 1.2 Document Name and Identification ........................................................................................ 2–2 1.3 PKI Participants ..................................................................................................................... 2–3

1.3.1 Certification Authorities................................................................................................................................. 2–3 1.3.2 Registration Authorities ................................................................................................................................. 2–3 1.3.3 Subscribers..................................................................................................................................................... 2–4 1.3.4 Relying Parties ............................................................................................................................................... 2–4 1.3.5 Other Participants........................................................................................................................................... 2–5

1.4 Certificate Usage .................................................................................................................... 2–7 1.4.1 Appropriate Certificate Uses.......................................................................................................................... 2–8 1.4.2 Prohibited Certificate Uses ............................................................................................................................ 2–8

1.5 Policy Administration ............................................................................................................. 2–8


Version 3.2 November 17, 2008 Page v

1.5.1 Organization Administering the Document.................................................................................................... 2–8 1.5.2 Contact Person ............................................................................................................................................... 2–9 1.5.3 Organization/Role Determining CPS Suitability for the Policy .................................................................... 2–9 1.5.4 CPS Approval Procedures.............................................................................................................................. 2–9

1.6 Definitions and Acronyms....................................................................................................... 2–9 2 PUBLICATION AND REPOSITORY RESPONSIBILITIES ...................................................... 2–9

2.1 Repositories ............................................................................................................................ 2–9 2.2 Ministries, agencies and the BPSPublication of Certification Information ......................... 2–10 2.3 Time or Frequency of Publication ........................................................................................ 2–10 2.4 Access Controls on Repositories........................................................................................... 2–10

3 IDENTIFICATION AND AUTHENTICATION ........................................................................ 2–11 3.1 Naming.................................................................................................................................. 2–11

3.1.1 Types of Names ........................................................................................................................................... 2–11 3.1.2 Need for Names to be Meaningful ............................................................................................................... 2–11 3.1.3 Anonymity or Pseudonymity of Subscribers................................................................................................ 2–11 3.1.4 Rules for Interpreting Various Name Forms ................................................................................................ 2–11 3.1.5 Uniqueness of Names................................................................................................................................... 2–11 3.1.6 Recognition, Authentication, and Role of Trademarks ................................................................................ 2–11

3.2 Initial Identity Validation...................................................................................................... 2–12 3.2.1 Method to Prove Possession of Private Key................................................................................................. 2–12 3.2.2 Authentication of Organization Identity....................................................................................................... 2–12 3.2.3 Authentication of Individual Identity ........................................................................................................... 2–12 3.2.4 Non-verified Subscriber Information ........................................................................................................... 2–13 3.2.5 Validation of Authority ................................................................................................................................ 2–13 3.2.6 Criteria for Interoperation ............................................................................................................................ 2–13

3.3 Identification and Authentication for Re-key Requests......................................................... 2–14 3.3.1 Identification and Authentication for Routine Re-key ................................................................................. 2–14 3.3.2 Identification and Authentication for Re-key After Revocation................................................................... 2–14

3.4 Identification and Authentication for Revocation Request ................................................... 2–14 4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ........................................ 2–14

4.1 Certificate Application.......................................................................................................... 2–14 4.1.1 Who Can Submit a Certificate Application.................................................................................................. 2–14 4.1.2 Enrolment Process and Responsibilities....................................................................................................... 2–14

4.2 Certificate Application Processing ....................................................................................... 2–16 4.2.1 Performing Identification and Authentication Functions ............................................................................. 2–16 4.2.2 Approval or Rejection of Certificate Applications....................................................................................... 2–16 4.2.3 Time to Process Certificate Applications ..................................................................................................... 2–16

4.3 Certificate Issuance .............................................................................................................. 2–17 4.3.1 CA Actions During Certificate Issuance ...................................................................................................... 2–17 4.3.2 Notification to Subscriber by the CA of Issuance of Certificate .................................................................. 2–17

4.4 Certificate Acceptance.......................................................................................................... 2–17 4.4.1 Conduct Constituting Certificate Acceptance .............................................................................................. 2–17 4.4.2 Publication of the Certificate by the CA ...................................................................................................... 2–17 4.4.3 Notification of Certificate Issuance by the CA to Other Entities ................................................................. 2–17

4.5 Key Pair and Certificate Usage............................................................................................ 2–17 4.5.1 Subscriber Private Key and Certificate Usage ............................................................................................. 2–17 4.5.2 Relying Party Public Key and Certificate Usage.......................................................................................... 2–17

4.6 Certificate Renewal............................................................................................................... 2–18 4.6.1 Circumstance for Certificate Renewal.......................................................................................................... 2–18 4.6.2 Who May Request Renewal......................................................................................................................... 2–18 4.6.3 Processing Certificate Renewal Requests .................................................................................................... 2–18 4.6.4 Notification of New Certificate Issuance to Subscriber ............................................................................... 2–18 4.6.5 Conduct Constituting Acceptance of a Renewal Certificate ........................................................................ 2–18 4.6.6 Publication of the Renewal Certificate by the CA........................................................................................ 2–18 4.6.7 Notification of Certificate Issuance by the CA to Other Entities ................................................................. 2–18

4.7 Certificate Re-key ................................................................................................................. 2–18 4.7.1 Routine Re-Key ........................................................................................................................................... 2–18


Version 3.2 November 17, 2008 Page vi

4.7.2 Re-key After Revocation.............................................................................................................................. 2–19 4.7.3 Circumstance for Certificate Re-key............................................................................................................ 2–19 4.7.4 Who May Request Certification of a New Public Key................................................................................. 2–19 4.7.5 Processing Certificate Re-keying Requests.................................................................................................. 2–19 4.7.6 Notification of New Certificate Issuance to Subscriber ............................................................................... 2–19 4.7.7 Conduct Constituting Acceptance of a Re-keyed Certificate ....................................................................... 2–19 4.7.8 Publication of the Re-keyed Certificate by the CA ...................................................................................... 2–19 4.7.9 Notification of Certificate Issuance by the CA to Other Entities ................................................................. 2–19

4.8 Certificate Modification........................................................................................................ 2–19 4.8.1 Circumstance for Certificate Modification................................................................................................... 2–19 4.8.2 Who May Request Certificate Modification ................................................................................................ 2–20 4.8.3 Processing Certificate Modification Requests.............................................................................................. 2–20 4.8.4 Notification of New Certificate Issuance to Subscriber ............................................................................... 2–20 4.8.5 Conduct Constituting Acceptance of Modified Certificate .......................................................................... 2–20 4.8.6 Publication of the Modified Certificate by the CA....................................................................................... 2–20 4.8.7 Notification of Certificate Issuance by the CA to Other Entities ................................................................. 2–20

4.9 Certificate Revocation and Suspension ................................................................................ 2–20 4.9.1 Circumstances for Revocation ..................................................................................................................... 2–20 4.9.2 Who Can Request Revocation...................................................................................................................... 2–21 4.9.3 Procedure for Revocation Request ............................................................................................................... 2–21 4.9.4 Revocation Request Grace Period................................................................................................................ 2–21 4.9.5 Time Within Which CA Must Process the Revocation Request .................................................................. 2–21 4.9.6 Revocation Checking Requirement for Relying Parties ............................................................................... 2–22 4.9.7 CRL Issuance Frequency ............................................................................................................................. 2–22 4.9.8 Maximum Latency for CRLs ....................................................................................................................... 2–22 4.9.9 On-line Revocation/Status Checking Availability ....................................................................................... 2–22 4.9.10 On-line Revocation Checking Requirements ............................................................................................... 2–22 4.9.11 Other Forms of Revocation Advertisements Available................................................................................ 2–22 4.9.12 Special Requirements re: Key Compromise................................................................................................. 2–22 4.9.13 Circumstances for Suspension ..................................................................................................................... 2–23 4.9.14 Who Can Request Suspension...................................................................................................................... 2–23 4.9.15 Procedure for Suspension Request ............................................................................................................... 2–23 4.9.16 Limits on Suspension Period........................................................................................................................ 2–23

4.10 Certificate Status Services................................................................................................. 2–23 4.10.1 Operational Characteristics .......................................................................................................................... 2–23 4.10.2 Service Availability...................................................................................................................................... 2–23 4.10.3 Optional Features ......................................................................................................................................... 2–23

4.11 End of Subscription ........................................................................................................... 2–23 4.12 Key Escrow and Recovery................................................................................................. 2–24

4.12.1 Key Escrow and Recovery Policy and Practices .......................................................................................... 2–24 4.12.2 Session Key Encapsulation and Recovery Policy and Practices .................................................................. 2–25

5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS........................................ 2–25 5.1 Physical Controls.................................................................................................................. 2–25

5.1.1 Site Location and Construction .................................................................................................................... 2–25 5.1.2 Physical Access............................................................................................................................................ 2–25 5.1.3 Power and Air Conditioning ........................................................................................................................ 2–25 5.1.4 Water Exposures .......................................................................................................................................... 2–26 5.1.5 Fire Prevention and Protection..................................................................................................................... 2–26 5.1.6 Media Storage .............................................................................................................................................. 2–26 5.1.7 Waste Disposal............................................................................................................................................. 2–26 5.1.8 Off-site Backup............................................................................................................................................ 2–26

5.2 Procedural Controls ............................................................................................................. 2–26 5.2.1 Trusted Roles ............................................................................................................................................... 2–26 5.2.2 Number of Persons Required per Task......................................................................................................... 2–27 5.2.3 Identification and Authentication for Each Role .......................................................................................... 2–27 5.2.4 Roles Requiring Separation of Duties .......................................................................................................... 2–28

5.3 Personnel Controls ............................................................................................................... 2–29 5.3.1 Qualifications, Experience, and Clearance Requirements............................................................................ 2–29 5.3.2 Background Check Procedures .................................................................................................................... 2–30


Version 3.2 November 17, 2008 Page vii

5.3.3 Training Requirements................................................................................................................................. 2–30 5.3.4 Retraining Frequency and Requirements ..................................................................................................... 2–31 5.3.5 Job Rotation Frequency and Sequence......................................................................................................... 2–31 5.3.6 Sanctions for Unauthorized Actions............................................................................................................. 2–31 5.3.7 Independent Contractor Requirements ......................................................................................................... 2–31 5.3.8 Documentation Supplied to Personnel ......................................................................................................... 2–31

5.4 Audit Logging Procedures .................................................................................................... 2–32 5.4.1 Types of Events Recorded ........................................................................................................................... 2–32 5.4.2 Frequency of Processing Log....................................................................................................................... 2–33 5.4.3 Retention Period for Audit Log.................................................................................................................... 2–33 5.4.4 Protection of Audit Log ............................................................................................................................... 2–33 5.4.5 Audit Log Backup Procedures ..................................................................................................................... 2–33 5.4.6 Audit Collection System .............................................................................................................................. 2–33 5.4.7 Notification to Event-causing Subject.......................................................................................................... 2–33 5.4.8 Vulnerability Assessments ........................................................................................................................... 2–33

5.5 Records Archival................................................................................................................... 2–34 5.5.1 Types of Records Archived.......................................................................................................................... 2–34 5.5.2 Retention Period for Archive ....................................................................................................................... 2–34 5.5.3 Protection of Archive ................................................................................................................................... 2–34 5.5.4 Archive Backup Procedures ......................................................................................................................... 2–34 5.5.5 Requirements for Time-stamping of Records .............................................................................................. 2–34 5.5.6 Archive Collection System .......................................................................................................................... 2–35 5.5.7 Procedures to Obtain and Verify Archive Information ................................................................................ 2–35

5.6 Key Changeover.................................................................................................................... 2–35 5.7 Compromise and Disaster Recovery..................................................................................... 2–35

5.7.1 Incident and Compromise Handling Procedures .......................................................................................... 2–35 5.7.2 Computing Resources, Software, and/or Data are Corrupted....................................................................... 2–35 5.7.3 Entity Private Key Compromise Procedures................................................................................................ 2–35 5.7.4 Business Continuity Capabilities After a Disaster........................................................................................ 2–36

5.8 CA or RA Termination .......................................................................................................... 2–37 5.8.1 CA Termination ........................................................................................................................................... 2–37 5.8.2 RA Termination ........................................................................................................................................... 2–37

6 TECHNICAL SECURITY CONTROLS..................................................................................... 2–37 6.1 Key Pair Generation and Installation................................................................................... 2–37

6.1.1 Key Pair Generation..................................................................................................................................... 2–37 6.1.2 Private Key Delivery to Subscriber.............................................................................................................. 2–38 6.1.3 Public Key Delivery to Certificate Issuer..................................................................................................... 2–38 6.1.4 CA Public Key Delivery to Relying Parties ................................................................................................. 2–38 6.1.5 Key Sizes ..................................................................................................................................................... 2–38 6.1.6 Public Key Parameters Generation and Quality Checking........................................................................... 2–39 6.1.7 Key Usage Purposes..................................................................................................................................... 2–39

6.2 Private Key Protection and Cryptographic Module Engineering Controls ......................... 2–39 6.2.1 Cryptographic Module Standards and Controls ........................................................................................... 2–39 6.2.2 Private Key Multi-person Control................................................................................................................ 2–40 6.2.3 Private Key Escrow...................................................................................................................................... 2–40 6.2.4 Private Key Backup ..................................................................................................................................... 2–40 6.2.5 Private Key Archival.................................................................................................................................... 2–40 6.2.6 Private Key Transfer Into or From a Cryptographic Module ....................................................................... 2–40 6.2.7 Private Key Storage on Cryptographic Module ........................................................................................... 2–41 6.2.8 Method of Activating Private Key ............................................................................................................... 2–41 6.2.9 Method of Deactivating Private Key............................................................................................................ 2–41 6.2.10 Method of Destroying Private Key .............................................................................................................. 2–41 6.2.11 Cryptographic Module Rating...................................................................................................................... 2–42

6.3 Other Aspects of Key Pair Management............................................................................... 2–42 6.3.1 Public Key Archival..................................................................................................................................... 2–42 6.3.2 Certificate Operational Periods and Key Pair Usage Periods....................................................................... 2–42 6.3.3 Use of Other Algorithms.............................................................................................................................. 2–43

6.4 Activation Data ..................................................................................................................... 2–43 6.4.1 Activation Data Generation and Installation ................................................................................................ 2–43


Version 3.2 November 17, 2008 Page viii

6.4.2 Activation Data Protection........................................................................................................................... 2–44 6.4.3 Other Aspects of Activation Data ................................................................................................................ 2–44

6.5 Computer Security Controls ................................................................................................. 2–44 6.5.1 Specific Computer Security Technical Requirements .................................................................................. 2–44 6.5.2 Computer Security Rating............................................................................................................................ 2–45

6.6 Life Cycle Technical Controls .............................................................................................. 2–45 6.6.1 System Development Controls..................................................................................................................... 2–45 6.6.2 Security Management Controls.................................................................................................................... 2–45 6.6.3 Life Cycle Security Controls........................................................................................................................ 2–45

6.7 Network Security Controls.................................................................................................... 2–45 6.8 Time-stamping ...................................................................................................................... 2–45

7 CERTIFICATE, CRL, AND OCSP PROFILES .......................................................................... 2–45 7.1 Certificate Profile ................................................................................................................. 2–45

7.1.1 Version Number........................................................................................................................................... 2–45 7.1.2 Certificate Extensions .................................................................................................................................. 2–46 7.1.3 Algorithm Object Identifiers ........................................................................................................................ 2–46 7.1.4 Name Forms................................................................................................................................................. 2–46 7.1.5 Name Constraints......................................................................................................................................... 2–46 7.1.6 Certificate Policy Object Identifier .............................................................................................................. 2–46 7.1.7 Usage of Policy Constraints Extension ........................................................................................................ 2–46 7.1.8 Policy Qualifiers Syntax and Semantics....................................................................................................... 2–46 7.1.9 Processing Semantics for the Critical Certificate Policies Extension........................................................... 2–46

7.2 CRL Profile ........................................................................................................................... 2–47 7.2.1 Version Number........................................................................................................................................... 2–47 7.2.2 CRL and CRL Entry Extensions .................................................................................................................. 2–47

7.3 OCSP Profile ........................................................................................................................ 2–47 7.3.1 Version Number........................................................................................................................................... 2–47 7.3.2 OCSP Extensions ......................................................................................................................................... 2–47

8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS .......................................................... 2–47 8.1 Frequency or Circumstances of Assessment......................................................................... 2–47

8.1.1 CA Assessments........................................................................................................................................... 2–47 8.1.2 RA Assessments........................................................................................................................................... 2–48

8.2 Identity/Qualifications of Assessor ....................................................................................... 2–48 8.3 Assessor's Relationship to Assessed Entity ........................................................................... 2–48

8.3.1 CA Assessments........................................................................................................................................... 2–48 8.3.2 RA Assessments........................................................................................................................................... 2–48

8.4 Topics Covered by Assessment ............................................................................................. 2–48 8.4.1 CA Assessments........................................................................................................................................... 2–48 8.4.2 RA Assessments........................................................................................................................................... 2–49

8.5 Actions Taken as a Result of Deficiency ............................................................................... 2–49 8.5.1 CA Assessments........................................................................................................................................... 2–49 8.5.2 RA Assessments........................................................................................................................................... 2–49

8.6 Communication of Results .................................................................................................... 2–49 8.6.1 CA Assessments........................................................................................................................................... 2–49 8.6.2 RA Assessments........................................................................................................................................... 2–49

9 OTHER BUSINESS AND LEGAL MATTERS.......................................................................... 2–50 9.1 Fees....................................................................................................................................... 2–50

9.1.1 Certificate Issuance or Renewal Fees........................................................................................................... 2–50 9.1.2 Certificate Access Fees ................................................................................................................................ 2–50 9.1.3 Revocation or Status Information Access Fees ............................................................................................ 2–50 9.1.4 Fees for Other Services ................................................................................................................................ 2–50 9.1.5 Refund Policy............................................................................................................................................... 2–50

9.2 Financial Responsibility ....................................................................................................... 2–50 9.2.1 Insurance Coverage...................................................................................................................................... 2–50 9.2.2 Other Assets ................................................................................................................................................. 2–50 9.2.3 Insurance or Warranty Coverage for End-entities ........................................................................................ 2–50

9.3 Confidentiality of Business Information ............................................................................... 2–51


Version 3.2 November 17, 2008 Page ix

9.3.1 Scope of Confidential Information............................................................................................................... 2–51 9.3.2 Information Not Within the Scope of Confidential Information .................................................................. 2–51 9.3.3 Responsibility to Protect Confidential Information...................................................................................... 2–52

9.4 Privacy of Personal Information .......................................................................................... 2–52 9.4.1 Privacy Plan ................................................................................................................................................. 2–53 9.4.2 Information Treated as Private..................................................................................................................... 2–53 9.4.3 Information Not Deemed Private ................................................................................................................. 2–53 9.4.4 Responsibility to Protect Private Information .............................................................................................. 2–53 9.4.5 Notice and Consent to Use Private Information........................................................................................... 2–53 9.4.6 Disclosure Pursuant to Judicial or Administrative Process .......................................................................... 2–53 9.4.7 Other Information Disclosure Circumstances .............................................................................................. 2–53

9.5 Intellectual Property Rights.................................................................................................. 2–53 9.6 Representations and Warranties........................................................................................... 2–53

9.6.1 CA Representations and Warranties............................................................................................................. 2–54 9.6.2 RA Representations and Warranties............................................................................................................. 2–57 9.6.3 Subscriber Representations and Warranties ................................................................................................. 2–59 9.6.4 Relying Party Representations and Warranties ............................................................................................ 2–61 9.6.5 Representations and Warranties of Other Participants ................................................................................. 2–62

9.7 Disclaimers of Warranties .................................................................................................... 2–62 9.8 Limitations of Liability.......................................................................................................... 2–63

9.8.1 Requirements ............................................................................................................................................... 2–63 9.8.2 Disclaimers .................................................................................................................................................. 2–63 9.8.3 Limitations of Liability ................................................................................................................................ 2–63 9.8.4 Other Terms and Conditions ........................................................................................................................ 2–64

9.9 Indemnities............................................................................................................................ 2–64 9.9.1 Indemnification by Relying Parties.............................................................................................................. 2–64 9.9.2 Fiduciary Relationships................................................................................................................................ 2–65 9.9.3 Administrative Processes ............................................................................................................................. 2–65

9.10 Term and Termination....................................................................................................... 2–65 9.10.1 Term............................................................................................................................................................. 2–65 9.10.2 Termination.................................................................................................................................................. 2–65 9.10.3 Effect of Termination and Survival.............................................................................................................. 2–65

9.11 Individual Notices and Communications with Participants.............................................. 2–65 9.12 Amendments ...................................................................................................................... 2–65

9.12.1 Procedure for Amendment ........................................................................................................................... 2–65 9.12.2 Notification Mechanism and Period............................................................................................................. 2–66 9.12.3 Circumstances Under Which OID Must be Changed................................................................................... 2–66

9.13 Dispute Resolution Provisions .......................................................................................... 2–66 9.13.1 Name Claim Dispute Resolution Procedure................................................................................................. 2–66

9.14 Governing Law.................................................................................................................. 2–67 9.15 Compliance with Applicable Law ..................................................................................... 2–67 9.16 Miscellaneous Provisions.................................................................................................. 2–67

9.16.1 Entire Agreement ......................................................................................................................................... 2–67 9.16.2 Assignment .................................................................................................................................................. 2–67 9.16.3 Severability .................................................................................................................................................. 2–67 9.16.4 Enforcement (Attorneys' Fees and Waiver of Rights) .................................................................................. 2–68 9.16.5 Force Majeure .............................................................................................................................................. 2–68

9.17 Other Provisions ............................................................................................................... 2–68 10 REFERENCES ............................................................................................................................. 2–68 APPENDIX A – GLOSSARY ................................................................................................................... 2–69 APPENDIX B – LIST OF ACRONYMS..................................................................................................... 2–75 APPENDIX C - ROLES AND RESPONSIBILITIES .................................................................................... 2–76

10.1.1 Policy Management Authority ..................................................................................................................... 2–76 10.1.2 Operational Authority .................................................................................................................................. 2–77 10.1.3 Certification Authorities............................................................................................................................... 2–77 10.1.4 Registration Authority.................................................................................................................................. 2–77 10.1.5 Head LRA.................................................................................................................................................... 2–78


Version 3.2 November 17, 2008 Page x

10.1.6 LRA Administrators..................................................................................................................................... 2–78 10.1.7 Subscribers................................................................................................................................................... 2–79 10.1.8 Relying Parties ............................................................................................................................................. 2–79 10.1.9 Sponsor ........................................................................................................................................................ 2–79 10.1.10 Program managers manage the use of certificates, keys, role identifiers, and attributes within their area of responsibility. Custodians of Information and Information Technology ....................................................................... 2–79 10.1.11 Root Certification Authority .......................................................................................................................... 2–1


Version 3.2 November 17, 2008 Page 1-1

1 Preface

This manual contains the Government of Ontario’s policy on the management and use of its public key infrastructure (PKI), and the mandatory standards for its operations. Chapter 1 – PKI Policy introduces the reader to general PKI concepts and how they are implemented within the Government of Ontario. It then describes the policy for the management and use of the GO-PKI and the interoperability standard that has been adopted by the Government of Ontario for the GO-PKI. Chapter 2 – GO PKI Certificate Policy contains the certificate policy that has been adopted by the Government of Ontario for the GO-PKI. Appendix A and Appendix B at the end of this document contain the Government of Ontario’s PKI glossary and a list of acronyms used in this manual.

Chapter 1 – PKI Policy

1 Introduction

This chapter first introduces the reader to general PKI concepts and how they are implemented within the Government of Ontario to fit Ontario’s business environments and address its particular requirements. It then continues to describe the policy for the management and use of the GO-PKI, which specifies the policy for managing and using private and public keys and public key certificates within the GO-PKI environment. This chapter also specifies the policy for establishing interoperability within the GO-PKI as well as between the GO-PKI and external public and private sector partners, along with the interoperability standard that has been adopted by the Government of Ontario for the GO-PKI. The interoperability standard specifies the minimum operational requirements that the GO-PKI Certification Authority (CA) and consistent use domain secondary CAs must comply with when establishing interoperability agreements. It also specifies the process by which they must establish and maintain these agreements.

You may obtain copies of reference material and additional information by contacting the organization specified in Chapter 21.5.2.

2 Foundation for the GO-PKI Policy

2.1 Concept of Operations

The policy for the Government of Ontario’s PKI supports the requirements specified in the Concept of Operations (CONOP) for the Government of Ontario’s Public Key Infrastructure1. Building on preliminary work in this area completed in April 20002, the GO-PKI CONOP defines a PKI environment where the various GO information technology (IT) user communities register for primary certificates (and associate private keys) and subsequently obtain role identifiers and associated attributes, which relate or

1 Concept of Operations for the Government of Ontario’s Public Key Infrastructure, Version 0.43, January 30, 2001. 2 Conceptual Model for the Design of a GO-PKI, in the context of a broader Infrastructure Environment, Version 11.0,

April 12, 2000.



are specific to an administrative service (e.g., Finance, Human Resources), a service line (e.g., Integrated Justice), or governmental program (e.g., Health).

The GO-PKI CONOP itself supports a number of higher level principles and requirements from various sources. These principles and requirements include:

The preservation of trust, scalability, user ease-of-use, and the protection of privacy

The long-term view and objectives of the GO-PKI deployment as a government-wide security infrastructure, which meets government-wide business requirements

The need for role-based access control technologies, designed to address the business requirements of ministries, agencies, and program areas participating in the GO-PKI

The need for a stringent registration process, which establishes with certainty and reliability the identity of a person

The need for a stringent enrollment process, which a) associates with accuracy and trustworthiness a person’s identity with their role identifiers, and b) provides the ability to associate the person with their authorized access privileges to information resources and program services

The need for a secure mobile token to safely store a person’s primary keys and potentially their role identifiers and associated attributes

The need to comply with the privacy principles and requirements imposed by Ontario’s Freedom of Information and Protection of Privacy Act (FIPPA) and Municipal Freedom of Information and Protection of Privacy Act (MFIPPA)

The need for the GO-PKI to use Ontario’s integrated directory infrastructure as a certificate repository

2.2 Governance

The GO-PKI Policy also supports the governance structure specified in the Governance for the Government of Ontario’s Public Key Infrastructure3. The GO-PKI Governance Model, illustrated in Figure 1, recognizes two distinct governance roles: a GO-PKI Policy Management Authority and a GO-PKI Operational Authority. The Policy Management Authority (PMA) manages a formal accreditation process for certification authorities wishing to participate in the GO-PKI. This process identifies the level of government standards to which their facilities, policies, resources, procedures, and technologies need to conform in order to qualify for GO-PKI CA accreditation status. The GO-PKI Operational Authority has the overall responsibility for the day-to-day operations of the GO-PKI CA, and for establishing CA certification and cross-certification agreements when approved by the PMA. The roles and responsibilities of each GO-PKI participant are fully documented in the GO-PKI Certificate Policy (see Chapter 1, Section 4.6)

3 Governance for the Government of Ontario’s Public Key Infrastructure, Version 1.0, October 20, 2000.



PKI Policy Certificate

Policy

Operational Authority

(Corporate Security)

Policy Management Authority

Certifica-tion

Practice Statement

Head Local Registration Authorities

GO-PKI Certificate Authority

Registration AuthoritiesCorporate (OPS Domain)

Program Domains

Approves

Sets Policies

Documents

Sets Direction

RA/LRA Operating

Proce-dures

Sets Practices

Operates

CA Operating

Proce-dures

Approves

Approves

Local Registration Authorities

Approves

Subscribers

Manages

Sets Procedures

Sets Procedures

Subscriber Agreement

Signs

CertificateManagement

Trusted Agents

Figure 1: GO-PKI Governance Model

The GO-PKI Governance Model supports a number of higher level principles and requirements, which are:

The need for the governance to be flexible, responsive, and constantly aligned with evolving technology and with the broader government-wide organizational structures and GO IM/IT structures

The need to address the broad objectives of maintenance of trust and interoperability with other jurisdictions across Canada, including the Federal Government

The need to reflect the culture and operational realities of the Government of Ontario (i.e., they are to be defined in context of existing structures, policies, and practices) and truly portray the state of its security

The GO-PKI Governance Model addresses governance relationships between GO-PKI and the following:

Ontario Public Service (OPS) Domain (WIN/HR, Finance, e-mail, etc.)

Ontario Broader Public Service Domain (municipalities, hospitals, schools, universities, etc.) and GO Business Partner Domain (lawyers, doctors, Children’s Aid Society, etc.)



GO Citizens Domain (members of the public)

External domains (other provinces, Federal Government, banks, etc.)

2.3 PKI Interoperability Framework

The GO-PKI Policy is specified within the context of an interoperability framework4 that Management Board Secretariat has developed with the cooperation of the Quebec Government and the federal Communications Security Establishment. This framework specifies an operational standard for establishing and managing interoperability within and between Canadian public sector PKIs. Its purpose is to facilitate through the implementation of operational standards the interoperability between CAs of Canadian governments and private sector organizations that serve to support the secure electronic delivery of governmental programs and services. The initial specifications of the interoperability standard5 that were delivered as part of this initiative have served as the basis for specifying the Interoperability Standard in Section 5 of this chapter.

2.4 Earlier Policy Work

During 1999, Management Board Secretariat produced a preliminary version of the GO-PKI Policy6, which was based on RFC25277 — the IETF PKIX framework —and on the certificate policies of the Federal Government and of the Government of Quebec. Due to the evolution of the GO-PKI conceptual model and the GO-PKI Governance structure that followed its development, as well as the interoperability work, this preliminary GO-PKI policy no longer met Ontario’s requirements. Its technical aspects, however, were still valid, and formed the basis for specifying a Certificate Policy Standard.

In 2007 it was decided to perform a review the GO-PKI Policy and GO-PKI Certificate Policies to bring them into alignment with the then current policies and practices. The result of this review was to simply this manual into 2 Chapters, with Chapter 1 being the overriding GO-PKI Policy and Chapter 2 being the GO-PKI Certificate Policy. At the same time, the GO-PKI Certificate Policy was re-formatted in compliance with the IETF framework for certificate policies Ref: http://www.ietf.org/rfc/rfc3647.txt ]to permit mapping with other PKI jurisdictions, should such a need arise. The GO-PKI Certification Practice Statement was also re-formatted to comply with the revised certificate policy framework.

3 GO-PKI Overview

3.1 Need for a Public Key Infrastructure

Government programs require government employees to provide information to the public or receive information from the public in electronic form. In addition, a great deal of information is exchanged within government. Senders and recipients alike need to be sure of the source of the document or information, and to be sure that it has not changed since it was created. Many times, the information must be kept secret as well.

4 Framework for the Development of an Interoperability Standard, Version 2.2, January 31, 2000. 5 Operational Standard for Interoperability of Public Key Infrastructures in the Public Sector, Version 1.0, March 14,

2000. 6 Policy on the Management and Use of User Keys and Certificates, Version 0.97 (latest version), December 25, 1999. 7 Certificate policy and certification practices framework from the Internet Engineering Task Force (IETF). RFC2527

specifies a Internet framework for specifying certificate policies and certification practice statements.



A public key infrastructure (PKI) provides a method of providing that level of assurance in source and integrity, and supports secret (confidential) communications. It does so by a system of public key cryptography. Different programs may need more or less assurance in the PKI security services, because they are exposed to more or less risk. In some cases, the parties may not need to rely as heavily on the security services, because the information is trustworthy for other reasons.

A PKI is a system of hardware, software, rules, and practices that help permit the secure exchange of sensitive information and the conduct of business transactions over public and private networks, including Internet. Using these security services, organizations may improve their business processes and extend secure electronic service delivery to their business partners and to the communities they serve. The basic elements of a PKI are private and public keys and public key certificates.

3.2 PKI in the Government of Ontario

3.2.1 Enhanced PKI Model

Standard PKI implementations use a single set of keys and certificates, normally issued under the owner’s name. While these elements provide a good basis for validating access to IT resources and programs, the use of a single electronic identifier poses serious privacy issues. For example, a personal identifier shared across multiple programs or databases could be used to profile a citizen through their electronic interactions with the government.

To address this issue, the Government of Ontario issues a single, primary set of keys and certificates to each individual, and multiple sets of identifiers and attributes, one set for each role the individual plays, or one for each of the government programs to which the individual has entitlements. A role identifier8 and its associated attributes are issued under a specific service or program, and is not shared outside of the service’s or program’s domain. For this reason, a domain of related government programs or services (e.g., Health) is called a consistent use domain.

An individual obtains primary certificates (and associated private keys) from a Certification Authority (CA). The individual then becomes a subscriber of the GO-PKI. The primary certificates contain only basic identifying information about their owners. These certificates do not contain any details about the owner’s entitlements to government programs, or their health, or finances, or other information about their entitlements.

An individual obtains a role identifier and associated attributes from an enrollment authority operating within a consistent use domain. The role identifier is different than the subscriber’s name (i.e., the name that appears in the subscriber’s primary certificates). It contains the unique identifier that is used within the consistent use domain to identify that particular individual (e.g., Health number). An individual may also obtain from the consistent use domain a set of attributes, which will be subsequently used within the issuing consistent use domain to determine the subscriber’s access privileges or program entitlements.

3.2.2 Subscriber Registration

An individual obtains their primary certificates by undergoing a registration process. To establish a good degree of assurance that the name to appear in the individual’s primary certificate really belongs to that individual, the registration authority verifies proof of identity. Once assurance is established, the identity of the individual can be authenticated electronically with trust within the GO-PKI domain.

8 The use of role identifiers may raise privacy issues, which must be considered in light of the nature of the identifier and

the context in which it will be used. The GO-PKI Policy specifies minimum requirements for their use, which include the conduct of privacy impact assessments.



During the registration process, the private keys associated with the individual’s primary certificates may be stored in a software token (e.g., a computer file) or on a hardware token (e.g., a smart card). Regardless of the medium, such a token is referred to as a PKI profile.

From this point on, the GO-PKI subscriber’s primary certificates and PKI profile serve to:

1. Verify the identity of the subscriber before they are issued role identifiers and attributes during an enrollment process

2. Subsequent to enrollment, verify the identity of the subscriber when they request access to attributes

3. Secure the service delivery by providing authentication, integrity, non-repudiation, and confidentiality

3.2.3 Enrollment Within a Consistent Use Domain

Following registration, an individual is a GO-PKI subscriber and, as such, may obtain role identifiers and attributes by undergoing an enrollment process within GO consistent use domains. During this process, an enrollment authority authenticates the subscriber using GO-PKI, and then issues role identifiers and attributes for that consistent use domain. This process essentially extends the assurance established during the registration process to the consistent use domain where the service- or program-specific interactions with the subscriber occur.

During the enrollment process, the subscriber’s role identifier and attributes are created, and may be stored in a number of ways; for example, a directory or an authorization server if in software, or a smart card if in hardware. Subscribers may obtain role identifiers and associated attributes for a number of consistent use domains, depending on who they are and to what resources or programs they have entitlements.

When requesting access to resources or services within a consistent use domain, a subscriber is first authenticated using their primary certificate. The subscriber’s role identifier and attributes for that consistent use domain are then obtained or activated, and then used by applications, in conjunction with the primary certificates, to provide secure service delivery.

Within a consistent use domain, the role identifier and attributes serve to:

1. Identify the subscriber within the consistent use domain.

2. Determine the subscriber’s privileges or entitlements within that consistent use domain.

3.2.4 Subscribers

As a government-wide security infrastructure, the GO-PKI must support the various types of electronic communications, transactions, and exchanges within the GO public service as well as between the Government of Ontario and its partners in other jurisdictions and in the private sector. The GO-PKI must also support communications and exchanges between the Government of Ontario and its citizens.

To support these many relationships, the Government of Ontario will need to issue primary certificates, PKI profiles and role identifiers and attributes to its employees (and other agents) and to its citizens. The Government of Ontario will also need to establish interoperability between the GO-PKI and the PKIs of external organizations, including those of other governments, of financial institutions, and other business partners.

3.2.5 Maintaining Assurance and Trust

Maintaining assurance and trust in a PKI requires the specification of policies and standards, which in turn results in the construction of secure facilities, the installation and configuration of secure computer



systems, the appointment of trusted personnel, and the implementation of high-assurance operational procedures. These policies and standards must specify the rules for connecting or establishing interoperability of certification authorities within a PKI domain, as well as the rules for establishing interoperability with certification authorities operating outside of that PKI domain.

To establish trust, the GO-PKI Certification Authority must issue medium assurance certificates in accordance with the Certificate Policy specified in Chapter 2 of this manual. To maintain trust, these certification authorities must periodically demonstrate compliance with the Certificate Policy by conducting compliance audits. The GO-PKI Policy limits the use of primary certificates and PKI profiles to meet the requirements of Ontario.

Interoperability within the GO-PKI and between the GO-PKI and external CAs is established in accordance with the Interoperability Standard specified in Chapter 15. To maintain trust, the GO-PKI Policy specifies the rules by which interoperability is established for each of the possible CA-to-CA relationships.

4 GO-PKI Policy

4.1 Policy Titles

The name of this policy is Policy for the Management and Use of the Government of Ontario Public Key Infrastructure. It may also be referred to as the GO-PKI Policy.

This policy is to be read in conjunction with the Management Board Committee’s Information and Information Technology Security Directive [1].

4.2 Policy Objective

The objective of this policy is.

(a) Ensure uniformity and coherence in the practices of the GO-PKI operation, including the use of GO-PKI by ministries, agencies and service partners as approved by the PMA;

(b) Ensure that the issuance, management and use of GO-PKI certificates establish and maintain an acceptable level of assurance and trust;

(c) Provide the basis for the development of the Certification Practice Statement (CPS), other policy work, agreements and communications that are specific to the GO-PKI environment; and

(d) Facilitate cross-certification with other PKIs.

4.3 Policy Statement

It is the policy of the Government of Ontario to establish, manage, and use public key cryptography in a manner which:

(a) Promotes the adoption of technology to extend and improve electronic program service delivery and public administration and reduce government costs

(b) Provides timely and secure access to government services for those who choose to deal with the Government of Ontario electronically

(c) Provides an integrated, cost effective security infrastructure



(d) Offers high assurance, trustworthy security services

(e) Respects the requirements of its privacy legislation

(f) Promotes secure, electronic interoperability with other levels of governments, other jurisdictions, and partners in the private sector

4.4 Application

This policy applies to all ministries and all agencies previously classified as schedules I or IV, unless exempted by a memorandum of understanding. Although it does not apply to agencies previously classified as schedules II or III, these agencies are encouraged to adopt this policy to help ensure the interoperability of their PKI with the GO-PKI.

4.5 Effective Date

The GO-PKI policy became in force on August 1, 2001. Please refer to the Revision Control section for the current version and its effective date (Preface page ii).

4.6 Roles and Responsibilities

This section provides an overview of the GO-PKI participants and their responsibilities.

4.6.1 Policy Management Authority

The Policy Management Authority (PMA) is an individual or an organization that is responsible for specifying local policy requirements above those specified in this standard. The PMA may be part of the same organization as the subscribers, and may be part of the same organization as the other PKI entities. No matter what the arrangement, however, the relationship between the PMA and the other entities remains the same. The PMA specifies additional requirements that the CA, RAs, subscribers, or relying parties must comply with to support local requirements.

4.6.2 Operational Authority

The Operational Authority (OA) is an individual or an organization appointed by the PMA that is responsible for the management and operations of one or more Certification Authorities (CA). The Operational Authority’s responsibilities cover all aspects of CA operations, including administration, human resources, physical sites, hardware and software, change and problem management, maintenance, and support.

4.6.3 Certification Authorities

A certification authority (CA) is a PKI entity that is responsible for:

Creation and signing of certificates binding subscribers with their public keys

Creation of subscriber confidentiality key pairs (if required)

Promulgation of certificate status through certificate revocation lists or through an on-line service

4.6.4 Registration Authority

A registration authority (RA) is a PKI entity that is responsible for:



Authentication of applicants requesting certificate issuance

Authentication of subscribers requesting other subscriber management services

Subscriber management

An RA may perform duties on behalf of more than one CA, providing that in doing so it satisfies all the requirements of this standard.

More than one RA may support the same subscriber community. If the community is large or geographically dispersed, the RAs delegate a subset of their responsibilities to local registration authorities or a Head LRA. The RA requirements specified in the Certificate Policy apply equally to LRAs.

4.6.5 Head LRA

A Head LRA may be established by the RA. The RA may delegate some or all of their duties to the Head LRA. The Head LRA is responsible for: Authentication of LRAs Managing the LRA Network as directed by the RA Ensuring LRAs adhere to this policy when performing their duties Subscriber management

4.6.6 LRA Administrators

A local registration authority (LRA) administrator is an individual appointed by an RA or Head LRA to perform the day-to-day registration operations within an RA’s subscriber domain. Typically, an LRA administrator operates in a different geographical location than the RA to service a local community of subscribers.

4.6.7 Subscribers

A subscriber is a PKI entity to which the CA issues certificates for the purpose of using PKI security services (e.g., origin authentication, receiving encrypted communications).

4.6.8 Relying Parties

The responsibilities of a relying party who is a subscriber of the GO-PKI are the same as those specified for subscribers (Section 4.6.7 above). The responsibilities of a relying party who is a subscriber of an external CA must be specified in the cross-certification agreement between the Government of Ontario and the external CA in accordance with the Interoperability Standard.

4.6.9 Sponsor

A sponsor is an individual or an organization that authorizes the issuance of certificates to subscribers within the sponsor’s area of responsibility. The sponsor is often part of the same organization as the subscribers and relying parties.



4.6.10 Program Managers

4.6.11 Program managers manage the use of certificates, keys, role identifiers, and attributes within their area of responsibility. Custodians of Information and Information Technology

Custodians of information and information technology specify functional requirements for the integration of PKI security services into applications.

4.7 Accountability

Heads of Ministries, agencies and the BPS are accountable for the implementation of GO-PKI elements within their area of responsibility and for their compliance with this policy and its operational standards. Accountability may not be delegated.

4.8 Application Requirements

4.8.1 CA Applications

The GO-PKI Operational Authority must use CA software applications that meet the requirements of the Certificate Policy Standard and the certification management operations of the Interoperability Standard. In addition, CA software applications must provide operations for:

(a) Subscriber management (create, modify, purge, etc.)

(b) Database management (journaling, backup, recovery)

(c) Management reporting

4.8.2 Ministries, agencies and the BPSBusiness Applications

Ministries, agencies and the BPS must ensure that the business software applications that they use within a consistent use domain meet the requirements specified in Chapter 21.4 and Section 5.10 of the Interoperability Standard. For the purpose of this policy, a business software application means any software component, or combination of software components, which, collectively, have the necessary functionality to validate certificates, perform cryptographic operations using private and public keys, and perform key and certificate management operations with a CA.

4.9 Outsourcing

Proposals to outsource any part of the GO-PKI operation must be submitted to the GO-PKI PMA for approval. The accountability for certification, registration, and enrollment cannot be delegated through outsourcing agreements. Such agreements must require that the contractor provide satisfactory evidence of financial responsibility and adequate insurance. If the contractor is a government entity, it will also have to provide waivers of crown and legislative immunity. To qualify, service providers must meet the relevant portions of the GO-PKI Policy and its operational standards.

Furthermore, Ministries, agencies and the BPS must ensure that the contractor is aware that, as a result of the contracting arrangement, the contractor will have to comply with FIPPA in respect of personal information it has in its custody, and that the ministry or agency retains control of records in the contractor’s custody that are connected to the contracting arrangement. Therefore, in the event of a FIPPA request, records in the possession of the contractor would be subject to the request.



5 Interoperability Standard

Interoperability within the GO-PKI and between the GO-PKI and other PKIs is established and managed in accordance with the Interoperability Standard described in this section . To maintain assurance and trust within the GO-PKI domain, the Government of Ontario privileges certain agreements as further described below.

As the subscriber community grows, it may become necessary to split the GO-PKI CA into multiple physical CAs. To support such a configuration, it will be necessary for each physical CA to interoperate. Such interoperability may be established through CA certification (i.e., CA hierarchy) or intra-domain cross-certification (i.e., peer-to-peer).

The Government of Ontario establishes interoperability with CAs outside of the Ontario Public Service (GO OPS) — i.e., GO BPS domain and external domains — with the GO-PKI CA only, through inter-domain cross-certification agreements. If the GO-PKI CACA is implemented in multiple physical CAs, then one CA must act as a root or a bridge to the external CAs. Trust may be limited on a case-by-case basis so as to constrain interoperability to distinct communities or applications to meet confidentiality and privacy requirements.

5.1 Introduction

This section contains the interoperability standard that has been adopted by the Government of Ontario for the GO-PKI. It specifies the minimum operational requirements that the GO-PKI Certification Authority (CA) and consistent use domain secondary CAs must comply with when establishing interoperability agreements. It also specifies the process by which they must establish and maintain these agreements. This standard also contains specifications for the issuance, maintenance, and use of certification authority (CA) certificates and cross-certificates. Specifications for generating, securing, and renewing CA private-public signature key pairs and for all aspects of subscriber keys and certificates are addressed in Chapter 2 of this manual.

This standard supports different types of interoperability agreements, which must be used to support the following relationships within the GO-PKI environment:

CA certification or intra-domain cross-certification may be used by the GO-PKI operational authority to establish hierarchical or network relationships between the physical CAs that form the primary CA

Inter-domain cross-certification must be used to establish network relationships between the primary CA and CAs external to the GO-PKI

5.2 Recognition Agreements

The GO-PKI PMA may allow an external CA to be recognized as the primary CA by an enrollment authority workstation within a particular consistent use domain. When a ministry or agency determines that there may be benefits to do so, they must submit a recognition agreement request to the GO-PKI PMA. The request must specify, as a minimum:

(a) The target consistent use domain

(b) The target business applications

(c) The reason for the request and any expected benefits (e.g., reduced implementation costs)

(d) The required changes to the enrollment authority workstation application (if any)



(e) A description of any new enrollment procedures, or a description of any required changes to existing enrollment procedures

(f) An assessment of the risk to the GO-PKI

(g) An assessment of the impact on privacy

Approved recognition agreements may be implemented without PKI interoperability, in which case the enrollment authority workstation must point directly to the external CA. Recognition agreements may also be implemented through inter-domain cross-certification agreements with the primary CA, in which case the recognition agreement must follow the process specified in this Interoperability Standard for establishing such agreements.

5.3 Convention

In this standard, the term application is used to distinguish between a person or an organization that assumes a PKI role, and the software application that the person or organization uses in the performance of their duties. For example, the term certification authority means the person or organization responsible for certificate management, while the term certification authority application means the software application that the CA uses to manage certificates. Similarly, the term subscriber means the subject of a certificate, while subscriber application means the software application used by the subscriber to obtain PKI security services.

To differentiate between a CA that is having its public signature verification key certified by another CA, and the CA that is certifying the key and generating the certificate, the terms subject CA and issuing CA are used.

5.4 PKI Architecture

This standard has been specified for a PKI that is composed of the following architectural components:

A CA application, which issues public key certificates and performs other key, certificate, and subscriber management operations, either automatically or when requested by CA and registration authority (RA) personnel

An administration interface used by CA and RA personnel to request PKI management operations

A repository, which is used by the CA application to store public key certificates and certificate revocation lists

A PKI client application, which is composed of a cryptographic module and an application programming interface, and which is called by CA, RA, and subscriber applications to consume PKI security services, either transparently or following requests by PKI entities

This architecture is depicted in Figure 1 below.



CA

RootCA

CA

RA RARA

Repo-sitory

RA

PKIClient

Figure 2: Standard PKI Architecture

In this architecture, each CA hierarchy or domain is composed of a root CA at the top of the hierarchy, which certifies subordinate CAs operating under it. Subordinate CAs certify users within a given community. Each CA has one or more RAs connected to it, through which a CA’s subscriber community is managed. The architecture supports the certification of CAs by subordinate CAs in any number of levels.

As an alternative to the repository, this standard supports the use of an online certificate status service.

5.5 Trust Relationships

Interoperability within and between domains may be established following both the hierarchical trust model and the network trust model. In the hierarchical trust model, a CA certifies the public verification key of one or more subordinate CAs through a CA certification process. For each CA-to-subordinate-CA relationship, one CA certificate is generated and published by the certifying CA. Hierarchical trust relationships may only be established within a CA hierarchy (intra-domain).

In the network trust model, two CAs mutually certify their public verification keys through a cross-certification process. For each CA-to-CA (peer-to-peer) relationship, a pair of cross-certificates is generated and published. Network trust relationships are normally established between CA hierarchies (inter-domain), although they may be established within a CA hierarchy if the local policy allows it.



Figure 2 - Trust Relationships

5.6 Community

To maintain its broad applicability, this standard has been specified for a generic PKI community, which is composed of a policy management authority (one per CA domain), certification authorities (one of which may operate as a root CA), registration authorities, subscribers, relying parties, and sponsors.


The policy management authority (PMA) is an individual or an organization that is responsible for:

Identifying opportunities for inter-domain cross-certification and submitting requests

Negotiating and ratifying inter-domain cross-certification agreements

Approving CA certification and intra-domain cross-certification requests

Resolving disputes concerning CA certification and cross-certification

5.6.2 Root Certification Authority

The root CA is a PKI entity that operates a CA at the top of a CA hierarchy. The root CA is responsible for:

Assisting their PMA and the CAs operating within their domain with technical aspects of CA certification and cross-certification

Conducting compliance audits when CA certification and cross-certification requests require it

Specifying changes to the root CA when the implementation of CA certification and cross-certification requests require it

CA

RootCA

CA CA

RootCA

CA

Domain A Domain BDomain C(single CA)

CA

CACA

Legend:Hierarchical Trust RelationshipNetwork Trust Relationship



Implementing CA certification and cross-certification agreements

In the absence of a root CA, a certification authority operating within the domain assumes these responsibilities.

5.6.3 Certification Authority

A CA is a PKI entity that is responsible for:

Identifying opportunities for CA certification and intra-domain cross-certification and submit requests

Conducting compliance audits when CA certification and intra-domain cross-certification requests require it

Specifying and implementing changes to their CA when CA certification and intra-domain cross-certification requests require it

Implementing CA certification and intra-domain cross-certification agreements


This standard assumes that all interoperability operations are performed by CAs.

5.6.5 Subscriber

The subscriber has no responsibilities with respect to interoperability.

5.6.6 Relying Party

A relying party is a PKI entity that relies on, or that causes a PKI client application to rely on, a CA certificate or a cross-certificate when using PKI security services (e.g., verifying message origin, encrypting a communication).

5.6.7 Sponsor

A sponsor is an individual or an organization with PKI service requirements that may request interoperability to support a particular business requirement. The sponsor is often part of the same organization as a subscriber or relying party community.

5.7 Interoperability Management Operations

This section describes the interoperability management operations recognized by this standard. It also identifies who may request these operations and what PKI entity is responsible for processing them.

5.7.1 Request

The request operation consists of the submission of a request for CA certification or cross-certification. An interoperability request may be submitted by a PMA, a CA, or a sponsor, and is processed by the root CA.

5.7.2 Issuance

Issuance is the process by which a CA obtains a CA public verification key and generates a CA certificate or a cross-certificate. Issuance follows the approval of an interoperability request or when an interoperability agreement is renewed. Typically, the two CAs process the issuance operation.



5.7.3 Renewal

The renewal operation serves to update or re-issue a CA certificate or a cross-certificate that has expired. This operation also serves to issue a CA certificate or a cross-certificate when the subject CA has generated a new signature key pair. Renewal is initiated manually by the issuing CA and should be performed prior to the expiration of the CA certificate or the cross-certificate to avoid interoperability interruption.

5.7.4 Revocation

The revocation operation is used to inhibit the interoperability between CAs or between CA hierarchies:

When information contained in the certificate has changed (e.g., common name change)

Upon suspected or known compromise of the CA’s private key

When a CA fails to comply with the terms and conditions of an interoperability agreement

To terminate an interoperability agreement

Once revoked, the CA certificate’s or cross-certificate’s serial number is added to an authority revocation list (ARL) with an appropriate reason code and posted by the CA application to the revoking CA’s repository. Prior to using a certificate from a certified or cross-certified CA, PKI client applications must check the status of the CA certificate or cross-certificate against the ARL. If it finds the certificate, then it must react accordingly based on the reason code, the PKI security service called, and the business process involved. Alternatively, applications may obtain certificate status through an on-line certificate status service.

5.7.5 Recovery

CAs must keep a copy of the CA certificates and cross-certificates they issue for recovery purposes. The recovery operation is performed when recovering from hardware failures and other types of contingency. Recovery is initiated manually by the issuing CA, and results in the re-posting of the certificate to the issuing CA’s repository.

5.7.6 Termination

The termination operation consists of ending the interoperability association between two CAs and preventing further interoperability between their subscriber communities.

5.8 Certification Authority Requirements

5.8.1 Certificate Policy Standard

To establish trust relationships under this interoperability standard, CAs must perform Policy Mapping to determine corresponding Assurance Levels. Certificate and ARL Repository

5.8.1.1 Certificate Profile

CA applications must be capable of producing CA certificates and cross-certificates in an X.509 Version 3 format in accordance with the profile specified in Chapter 27.

5.8.1.2 ARL Profile

CA applications must be capable of producing ARLs in an X.509 Version 2 CRL format in accordance with the profile specified in Chapter 27.



5.8.1.3 Compatibility of CA Repositories

The CAs must ensure the compatibility of their repositories and the protocol used for the storage and retrieval of CA certificates, cross-certificates, and ARLs. Some interoperability agreements may require configuration changes, which must be specified during the interoperability implementation process.

5.8.2 On-line Revocation and Status Checking Availability

A CA may provide on-line revocation status checking for the CA certificates and cross-certificates that it issues. If so, the service must provide a level of assurance that is equivalent to a digitally signed ARL. The protocol described in RFC2560 [4] is suitable for this service.

5.8.3 Network Infrastructures

To interoperate, users of one CA must be able to access the repository or the on-line certificate status service of the other CA over a general-purpose IP network. This may require configuration changes to network hardware and software components, which must be specified during the interoperability implementation process.

5.8.4 Operational Requirements

5.8.4.1 Interoperability Request

A PMA, a CA, or a sponsor may submit a CA certification or a cross-certification request. Interoperability requests must follow the process specified in Section 5.7.

5.8.4.2 Issuance

A PMA must approve an interoperability request before the issuance of a CA certificate or cross-certificates.

The public signature verification key of a subject CA must be sent to the issuing CA in accordance with the process specified in RFC2510 [5], or via an equally secure out-of-band method. Once the certificate has been generated, the issuing CA must publish the CA certificate or the cross-certificate to its repository, or otherwise make its status information available to the relying parties.

5.8.4.3 Renewal

A subject CA must request renewal of its CA certificate or cross-certificate prior to the certificate’s expiry. The PMA of the issuing CA must approve the renewal operation. Any transfer of a CA’s public signature verification key as a result of a renewal operation must be in accordance with RFC2510, or it must be done via an equally secure out-of-band method.

Alternatively, an issuing CA may renew a CA certificate or a cross-certificate automatically prior to the certificate’s expiry, if such an operation is allowed by local policy.

5.8.4.4 Revocation

A PMA, a subject CA, an issuing CA, or a sponsor may request the revocation of a CA certificate or cross-certificate. They may request revocation for one of the following reasons:

When information contained in the CA certificate or cross-certificate has changed (e.g., common name change)

Upon suspected or known compromise of the associated private key

Upon suspected or known compromise of the medium (e.g., a diskette) holding the associated private key



When the subject CA fails to comply with its obligations describer in its agreement with the issuing CA

The issuing CA must revoke the CA certificate or the cross-certificate and add its serial number and an appropriate reason code to its ARL. It is possible for one cross-certificate from a cross-certificate pair to be revoked without having to revoke the other.

5.8.4.5 Recovery

The recovery operation is performed when a CA has to recover its repository due to a hardware failure or other types of contingency. CAs must keep a copy of the CA certificates and cross-certificates they issue for that purpose. Recovery of a CA certificate or cross-certificate is initiated by the issuing CA and results in the re-publishing of the certificate to the CA’s repository.

5.8.4.6 Termination

A PMA, a subject CA, an issuing CA, or a sponsor may request the termination of an interoperability agreement. If the agreement is CA certification, then the issuing CA must revoke the CA certificate. If the agreement is cross-certification, then each CA must revoke the cross-certificate of the other CA.

5.9 Relying Party Obligations

5.9.1 Use of CA Certificates and Cross-certificates for Appropriate Purpose

When using a CA certificate or cross-certificate issued under this standard, a relying party must ensure that it is used for its intended purpose.

5.9.2 Verification Responsibilities

To use a CA certificate or cross-certificate issued under this standard, a relying party must use a PKI client application that performs the certification path validation procedure specified in X.509 and RFC 3280 [3].

5.9.3 Revocation Check Responsibility

To use a CA certificate or cross-certificate issued under this standard, the relying party’s PKI client application must check the status of the certificate against the issuing CA’s current ARL. As part of this process, the relying party’s PKI client application must validate the issuing CA’s digital signature.

If the CA provides on-line certificate status checking, then the relying party may use a PKI client application that obtains certificate status information from that service.

5.10 PKI Client Application Requirements

This section specifies the minimum requirements for PKI client applications. The minimum requirements apply to PKI client applications used by all PKI entities, including subscribers, CA personnel, and RA personnel.

5.10.1 Certificate Profile

PKI client applications must recognize the basic certificate fields and the certificate extensions specified in RFC 3280 [3] [3].



5.10.2 ARL Profile

PKI client applications must recognize the basic CRL fields, the CRL extensions, and the CRL entry extensions specified in RFC 3280 [3].

5.10.3 Validation

PKI client applications must process CA certificates and cross-certificates in accordance with RFC 3280 [3]. The status of CA certificates and cross-certificates must be checked against an ARL or it may be obtained from an on-line service that provides an equivalent level of assurance.

5.11 Agreements

CAs that establish interoperability under this standard must agree on the terms and conditions of their relationship. These agreements may be formalized in memorandums of understanding, contracts, or any other form acceptable to the parties establishing an agreement. This section specifies the subjects that must be addressed in agreements when establishing interoperability under this standard.

For CA certification and intra-domain cross-certification, agreements will normally be between a PMA and a CA. For inter-domain cross-certification, agreements will normally be between two PMAs.

5.11.1 CA Certification and Intra-Domain Cross-Certification

At a minimum, agreements for CA certification and intra-domain cross-certification must address the following subjects:

Definition of services – The substantive terms, conditions, and obligations of the parties.

Standards of operation – Interoperability-specific standards of operation.

Changes to technical and operational specifications – Process to submit, review, and approve changes to technical and operational specifications.

Termination – The terms of the agreement’s earlier termination, if any.

5.11.2 Inter-Domain Cross-Certification

At a minimum, agreements for inter-domain cross-certification must address the following subjects:

Definition of services – The substantive terms, conditions, and obligations of the parties.

Confidentiality of information – Non-disclosure of confidential information.

Safeguarding of information – The protection and securing of personal and other confidential information in accordance with access to information and privacy legislation.

Record retention – Records to be kept by the parties and provision of access thereto.

Liability – The allocation of liability between the parties.

Indemnities – Indemnification for loss or liability, including those arising from claims by third parties.

Dispute resolution – Procedures for the appropriate resolution of disputes.

Audit – The right to conduct audits and inspections of systems and general contract compliance.

Standards of operation – interoperability-specific standards of operation.



Changes to technical and operational specifications – Process to submit, review, and approve changes to technical and operational specifications.

Governing laws – The application of laws of Canada and any applicable local laws, exclusive of any conflict of law principles.

User agreements – The obligation of the parties to bind users to responsibilities.

Assignment/Subcontracting – The subcontracting of services or assignment of agreement, and stipulating whether and what consents are required.

Rights of set-off – Any rights of set-off.

Notice of cross-certification – The disclosure and identification of entities with whom the parties have cross-certified at the time of agreement, and provision for consent to further such cross-certifications.

Standard contract provisions – Such as severability, merger, notice, nature of relationship.

Excusable delay/Force majeure – If any.

Termination – The terms of the agreement’s earlier termination, if any.

5.12 Process

This section describes the process to establish and maintain CA certification and cross-certification agreements. To preserve its broad applicability, the process is expressed at a high level, and organizations may submit and agree on complementary detailed procedures to address their own local policy requirements.

5.12.1 CA Certification and Intra-Domain Cross-Certification

The process for CA certification and intra-domain cross-certification is internal to an organization. The PMA, the root CA, and the requesting CA or CAs may participate. The process consists of the following stages: request, review, planning, agreement, specification, implementation, and maintenance.

5.12.1.1 Request

The process begins when a CA submits a request for CA certification or intra-domain cross-certification to its PMA. The request must be accompanied by a compliance audit report, which demonstrates that policy mapping has been completed between the GO PKI CA and the CA organization to determine the corresponding Assurance Levels..

5.12.1.2 Review

The PMA reviews the request and approves or rejects it. During its review, the PMA may request additional documentation from the CA organization (e.g., PKI or network design documents, certification practice statement, operational procedures).

The review process consist of the following activities:

The PMA confirms the requirement for CA certification or intra-domain cross-certification and validates the compliance audit report. The PMA may request or conduct additional reviews for any aspects as the CA operations.

The CAs (one of which may be the root) conduct initial testing to confirm the interoperability capability of their respective CA. These tests may be conducted using test or quality assurance platforms.



If the requesting CA is compliant and the interoperability testing is conclusive, the PMA approves the request.

5.12.1.3 Planning

The purpose of this phase is to develop an implementation plan and schedule for the remainder of the process. The schedule should identify all of the activities and tasks, their resources, and expected start and end dates.

5.12.1.4 Agreement

The PMA and the requesting CA (or the certifying CA and the requesting CA) negotiate and agree on the terms and conditions of their relationship. The agreement must address the subjects specified in Section 5.11.

5.12.1.5 Specification

The purpose of the specification phase is to specify configuration changes and the detailed implementation procedures. The activities to accomplish are:

The CAs review their network infrastructures and specify changes to existing hardware and software components or the addition of new components.

The CAs specify changes to PKI client applications, if required.

Based on the configuration changes and CA application documentation, the CAs specify detailed implementation procedures.

5.12.1.6 Implementation

The CAs implement necessary changes to their network infrastructures and issue a CA certificate or cross-certificates in accordance with the detailed implementation procedures.

5.12.1.7 Maintenance

During the maintenance stage, the parties conduct compliance audits, manage change and resolve problems, and conduct revocation, renewal, and recovery operations as required.

5.12.2 Inter-Domain Cross-Certification

The process for inter-domain cross-certification involves two organizations. Typically, their PMA and their root CA would be involved. The process consists of the following stages: proposal, review, planning, agreement, specification, implementation, and maintenance.

5.12.2.1 Proposal

The process begins when the PMAs express their intention to establish an inter-domain cross-certification agreement between their organization. The proposal may take any form that is acceptable to both parties. PMAs must establish a joint team, which will be responsible for the process.

5.12.2.2 Review

The purpose of the review is to demonstrate compliance to the Federated Certificate Policy Standard and confirm the interoperability capability of the CAs (or root CAs). To accomplish this, the team will have to examine a number of documentation items, including compliance audit reports for CAs within each hierarchy, PKI and network design documents, certification practice statements, and operational procedures. The review process consist of the following activities:



The team confirms the requirement for inter-domain certification and validates each organization’s compliance to the Federated Certificate Policy Standard. The team may request or conduct additional reviews for any aspects as the PKI operations.

The team conducts initial testing to confirm the interoperability capability of their respective PKI. These tests may be conducting using test or quality assurance platforms.

If the PKIs are compliant and the interoperability testing is conclusive, the team approves the proposal.

5.12.2.3 Planning

The purpose of this phase is to develop an implementation plan and schedule for the remainder of the process. The schedule should identify all of the activities and tasks, their resources, and expected start and end dates.

5.12.2.4 Agreement

The team negotiates and agrees on the terms and conditions of their relationship. The agreement must address the subjects specified in Section 5.11.

5.12.2.5 Specification

The purpose of the specification phase is to specify the configuration changes and the detailed implementation procedures. The activities to accomplish are:

The team reviews network infrastructures and specify changes to existing hardware and software components and the addition of components.

The team specifies changes to PKI client applications, if required.

Based on the configuration changes and CA application documentation, the team specifies detailed implementation procedures.

5.12.2.6 Implementation

The team implements necessary changes to their network infrastructures and issue cross-certificates in accordance with the detailed implementation procedures.

5.12.2.7 Maintenance

During the maintenance stage, the parties conduct compliance audits, manage change and resolve problems, and conduct revocation, renewal, and recovery operations as required.

6 Using the GO-PKI Certificate Policy

6.1 Scope

To ensure the proper operation of the GO-PKI, the GO-PKI Certificate Policy and its operational standards specify the main functions for the management and use of primary certificates and their associated PKI profiles:

Establishment and maintenance of the GO-PKI trust model

Identification and authentication practices

Primary key and certificate management and usage practices



Physical, personnel, and technical security requirements

Hardware and software requirements and related management practices

Compliance audit practices

CA certification and cross-certification practices

The GO-PKI Certificate Policy and its operational standards also specify minimum requirements to extend PKI trust and assurance into the consistent use domains.

6.2 Structure

The GO-PKI Certificate Policy consists of the following chapters:

Chapter 1 – GO-PKI Policy

Chapter 2 – Certificate Policy

6.3 Ministries, agencies and the BPS

Ministries, agencies and the BPS9 should use this Certificate Policy to establish, operate, and maintain enrollment authorities, assign PKI responsibilities, and conduct compliance audits.

6.4 Program Managers

Program managers should use this Certificate Policy to determine the suitability of keys and certificates to support a particular group of users or a particular program within their area of responsibility, ensure the compliance of applications and products with application-specific policy requirements, and identify and manage risk where applications and products do not meet policy requirements.

6.5 Custodians

Custodians of information and information technology resources should use this Certificate Policy to ensure the proper integration of GO-PKI services in in-house applications. Custodians must also evaluate information technology products in light of policy requirements and advise program managers as to the products’ level of compliance and as to the ministry’s or agency’s exposure to risk where products do not meet policy requirements.

6.6 GO-PKI Policy Management Authority

The GO-PKI PMA has the overall responsibility for the GO-PKI Policy and its operational standards. The PMA is responsible for the approval of this manual.

6.7 GO-PKI Operational Authority

The GO-PKI Operational Authority uses this manual to establish, operate, and maintain the GO-PKI CA, and to establish CA certification and cross-certification agreements. The GO-PKI Operational Authority is responsible for the maintenance of this manual.

9 In this document, the term Ministries, agencies and the BPS is used to mean ministries, agencies, boards, and

commissions.



7 Inquiries

You may contact the organization identified in Chapter 21.5.2 to obtain more information concerning this policy and its implementation.

Government of Ontario Public Key Infrastructure Chapter 2 Certificate Policy Certificate Policy Standard

Version 3.2 November 17, 2008 Page 2–1

Chapter 2 – GO-PKI Certificate Policy

FOREWORD

This chapter of the Government of Ontario public key infrastructure (GO-PKI) Certificate Policy contains the certificate policy that has been adopted by the Government of Ontario for the GO-PKI. It specifies the minimum requirements that Ministries, agencies and the BPS shall comply with when establishing and operating certification authorities, registration authorities, and local registration authorities. It also specifies the minimum requirements that business applications shall comply with when using GO-PKI certificates and associated public and private keys.

1 INTRODUCTION

This certificate policy specifies the minimum requirements that PKI entities shall comply with in order to operate under the GO-PKI Policy. PKI entities may address additional specifications in their implementation to meet local policy requirements, provided such local requirements do not contravene the requirements of the GO-PKI as stated in the GO-PKI Policy and GO-PKI Certificate Policy.

This certificate policy contains specifications for the management and use of keys and certificates issued to subscribers. It also specifies the requirements for the management and use of keys and certificates issued to CA and RA personnel for the performance of their duties.

This certificate policy does not address the requirements for the management and use of certificates issued to CAs, which are the subject of the Interoperability Standard in Chapter 15.

Unless otherwise indicated, the statements in this certificate policy specify the requirements to achieve all levels of assurance (basic, medium, and high). Statements are sub-divided by assurance levels where the requirements are specific to a particular assurance level and the differences from the medium assurance requirements are specified. Sub-divisions are normally presented in the following order: medium, high, basic.

The term application is used to distinguish between a person or an organization that assumes a PKI role and the software application that the person or organization uses in the performance of their duties. For example, the term certification authority means the person or organization responsible for certificate management, while the term certification authority application means the software application that the CA uses to manage certificates. Similarly, the term subscriber means the subject of a certificate, while subscriber application means the software application used by the subscriber to obtain PKI security services.



1.1 Overview

This certificate policy has been specified for a PKI that is composed of the following architectural components:

The GO-PKI CA application, which issues public key certificates and performs other key, certificate, and subscriber management operations, either automatically or when requested by CA and RA personnel

An administration interface used by CA and RA personnel to request PKI and subscriber management operations

A repository, which is used by the CA application to store public key certificates and certificate revocation lists

A PKI client application, which is composed of a cryptographic module and an application program interface, and which is called by business applications to consume PKI security services, either transparently or following a request by the subscriber

1.2 Document Name and Identification

The name of this certificate policy is Government of Ontario Public Key Infrastructure Certificate Policy. It may also be referred to as the GO-PKI CP. All uses of the word “section ” followed by a heading number are references to the sections within this certificate policy.

Certification authorities may issue public encryption key certificates and digital signature verification key certificates at three levels of assurance: basic, medium, and high. Certification authorities shall add to each certificate an object identifier (OID) as specified in Table 1 below when issuing certificates under this certificate policy.

Table 1 - GO-PKI Certificate Policy Object Identifiers

Certificate Type Policy OIDs

Basic assurance digital signature 2 16 124 8 101 8 1 6

Basic assurance confidentiality 2 16 124 8 101 8 1 2

Medium assurance digital signature 2 16 124 8 101 8 1 7

Medium assurance confidentiality 2 16 124 8 101 8 1 3

High assurance digital signature 2 16 124 8 101 8 1 8

High assurance confidentiality 2 16 124 8 101 8 1 4



1.3 PKI Participants

To maintain its broad applicability, this certificate policy has been specified for a generic PKI community, which is composed of a policy management authority, certification authorities, registration authorities, head local registration authorities, local registration authorities, subscribers, relying parties, and sponsors.


The GO-PKI CA consists of one or more self-signed Root CAs and one or more subordinate CAs. Where necessary, this certificate policy distinguishes the different users and roles accessing the CA functions. Where this distinction is not required, the term Certification Authority is used to refer to the total CA entity, including the hardware, software, personnel, processes, and its operations.

The GO-PKI Certification Authority (CA) is responsible for:

(a) Creation, signing, distribution, key recovery, and revocation of certificates binding the X.501 Distinguished Name of Subscribers and Registration Authorities with their respective signature verification key and their public encryption key;

(b) Delegation of limited authority to one or more Registration Authorities and Local Registration Authorities;

(c) Promulgation of certificate status through Certificate Revocation Lists (CRLs) and Authority Revocation Lists (ARLs); and

(d) Implementation and operation of its certification practices to achieve the requirements of this CP.

1.3.2 Registration Authorities

A Registration Authority (RA) is an individual appointed by the GO-PKI PMA who has the overall responsibility for the primary registration process within a subscriber domain. The RA’s responsibilities are to:

(a) Perform registration operations on behalf of the GO-PKI CA

(b) Verify eligibility and authorizations for primary certificate issuance

(c) Distribute initialization data and, optionally, PKI client software

(d) Open and update subscriber files

(e) Acquire and distribute hardware tokens when applicable

(f) Appoint Local Registration Authority (LRA) administrators to perform day-to-day registration operations within their subscriber domain

(g) Ensure that LRA administrators are informed of their respective responsibilities and obtain proper training

(h) Ensure that LRA administrators adhere to the relevant portions of this policy and its operational standards



The RAs operating under this certificate policy may require the services of other security, community, and application authorities, such as compliance auditors and trusted third parties. The CPS shall identify the parties responsible for providing such services, and the mechanisms used to support these services.

1.3.2.1 Head Local Registration Authorities

Head Local Registration Authorities (HLRA) are appointed by the RA and are responsible for the identification and authentication of LRA administrators, the approval of certificate management requests received from LRAs on behalf of subscribers and subscriber applicants, and the handling of instruments required by the processes for creating and issuing certificates to LRAs.

1.3.2.2 Local Registration Authorities

Local Registration Authorities (LRA) are appointed by the HLRA and are responsible for the identification and authentication of subscribers and the management of subscriber certificates within one or more consistent use domains. HLRAs may delegate identity proofing to approved Trusted Agents, in which case the RA must clearly document in its procedures the requirements the Trusted Agent shall meet.

1.3.2.3 Trusted Agents

Trusted Agents are recognized and approved by the PMA as having sufficient trustworthiness to represent a community of affiliated individuals or themselves are held to an acceptable ethical standard . Approved Trusted Agents are responsible for the identification and authentication of subscribers. After successful identity proofing, Trusted Agents submit certificate management requests to the LRA for processing.

The RA has approved Notary Publics in Canada as d Trusted Agents for the purpose of authenticating GO-PKI subscribers.

1.3.3 Subscribers

A GO-PKI subscriber is an individual who has received certificates from the GO-PKI CA. A subscriber may be an employee or other agent of the Government of Ontario, an employee or other agent of an external organization, or a member of the public.

A subscriber’s responsibilities are to:

(a) Use their GO-PKI certificates and keys for authorized uses as specified in this certificate policy

(b) Advise their LRA administrator of any changes that affect their subscriber status

(c) Protect activation codes and private keys in accordance with established procedures

(d) Meet their obligations as set out in their subscriber agreements or as otherwise required


A relying party is a PKI entity that relies on, or that causes a PKI client application to rely on, a certificate when using PKI security services (e.g., verifying message origin, encrypting a communication).

The responsibilities of a relying party who is a subscriber of the GO-PKI are the same as those specified for subscribers (see Chapter 21.3.3). The responsibilities of a relying party who is a subscriber of an



external CA shall be specified in the cross-certification agreement between the Government of Ontario and the external CA in accordance with the Interoperability Standard.

1.3.5 Other Participants

1.3.5.1 GO-PKI Policy Management Authority

The GO-PKI Policy Management Authority (PMA) is a committee chaired by the government’s Corporate Chief Information Officer, with members from participating Ministries, agencies and the BPS. It has the overall responsibility for the GO-PKI, including the promulgation and maintenance of this policy. It reports to the Chair of Management Board of Cabinet.

The GO-PKI PMA’s responsibilities are to:

(a) Ensure through policies, standards, and directives, the harmonized operation of the GO-PKI and the interoperability between its members

(b) Ensure that the GO-PKI operation is migrated to comply with this GO-PKI Policy in accordance with the Effective Date

(c) Accredit certification authorities and registration authorities

(d) Negotiate and approve cross-certification agreements with certification authorities external to the GO-PKI, including intergovernmental and international agreements

(e) Negotiate and approve GO-PKI CA recognition agreements with certification authorities external to the GO-PKI

(f) Ensure that certification authorities comply with the policies, standards, and directives regarding GO-PKI

(g) Appoint registration authority (RA) managers and determine the security safeguards for their operational sites

(h) Approve requests for exceptions by a ministry or agency to issue certificates at an assurance level other than medium

1.3.5.2 GO-PKI Operational Authority

The GO-PKI PMA shall appoint the GO-PKI Operational Authority, who is responsible for the operation of the GO-PKI GO-PKI CA. The GO-PKI Operational Authority’s responsibilities cover all aspects of the GO-PKI CA’s operations, including administration, human resources, physical sites, hardware and software, change and problem management, maintenance, and support.

The GO-PKI Operational Authority shall implement, manage, and operate the GO-PKI CA in accordance with the requirements specified this Certificate Policy.

The GO-PKI Operational Authority shall develop an operations manual that describes how the GO-PKI CA personnel operate the systems that compose the GO-PKI CA on a day-to-day basis.

To address inter-domain cross-certification requirements, the Operational Authority shall also develop the GO-PKI certification practice statement (CPS), which shall describe the practices that the GO-PKI CA, registration authorities, and Electronic Directory and Messaging Service (EDMS) follow to meet the requirements of this policy and its operational standards. The CPS shall follow the structure of the IETF’s PKIX framework [2]. The CPS shall be approved by the GO-PKI PMA.



The GO-PKI PMA shall accredit the GO-PKI CA before the commencement of its operations. If the primary CA is composed of more than one physical CA, then the GO-PKI PMA shall accredit each CA within the primary CA cluster, and any new CA that is added to the cluster to meet new demands.

The GO-PKI Operational Authority shall conduct compliance audits on the basis of the GO-PKI CA’s operations manual and in accordance with the frequency and requirements of the Certificate Policy.

In summary, the GO-PKI Operational Authority shall:

(a) Establish, operate, and manage the GO-PKI CA in accordance with the medium assurance requirements specified in this Certificate Policy

(b) Develop an operations manual

(c) Develop and maintain the GO-PKI certification practice statement (CPS)

(d) Implement, operate, and maintain the CA’s technological infrastructure

(e) Plan the technological infrastructure’s evolution

(f) Manage primary certificates, associated keys, and subscribers

(i) Ensure that the CA personnel and RAs are informed of their respective responsibilities and obtain proper training

(j) Ensure that the Primacy CA personnel and RAs adhere to this policy and its operational standards

(k) Conduct periodic compliance audits

(l) Specify, establish, and maintain interoperability agreements in accordance with the Interoperability Standard and as approved by the GO-PKI PMA

1.3.5.3 Ministries,Agencies and Broader Public Sector (BPS)

Ministries,agencies and BPS that wish to participate in the GO-PKI may operate one or more GO-PKI registration services for the community of information technology (IT) users within their area of responsibility. Alternatively, they may use the services of accredited RAs operating in other Ministries, agencies and the BPS. If they choose to operate one or more registration services, then they shall do so in accordance with the requirements specified in this certificate policy.

For each registration service that a ministry or agency implements, the GO-PKI PMA shall appoint an RA who will be responsible for the operation of the service. The RA shall develop an operations manual that describes how LRA administrators operate the registration service on a day-to-day basis.

The GO-PKI PMA shall accredit each registration service before the commencement of its operations. The GO-PKI Operational Authority shall conduct compliance audits on the basis of the RA’s operations manual and in accordance with the frequency and requirements of the Certificate Policy.

In summary, Ministries, agencies and the BPS shall:

(a) Establish, operate, and manage registration services in accordance with this certificate policy

(b) For each registration service, appoint an RA

(c) For each registration service, develop an operations manuals

(d) Conduct periodic compliance audits



(e) Alternatively, use the services of accredited registration services operating in other ministries or agencies

1.3.5.3.1 Program Managers

Program managers manage the use of certificates, keys, role identifiers, and attributes within their area of responsibility. They have the following responsibilities:

Determine for purposes of program delivery who within their area of responsibility is entitled to obtain certificates, keys, and attributesDetermine for what business processes certificates, keys, role identifiers, and attributes may be used

(c) Specify certificate, key, and role identifier usage and related procedures

(d) Adapt their business processes to make efficient use of PKI security services

(e) Authorize the issuance, use, suspension and revocation of certificates, keys, role identifiers, and attributes to subscribers

(f) Inform their enrollment authorities and their RA of subscriber affiliation changes or termination

(g) Inform subscribers and relying parties of uses of certificates and keys that they are authorized for

(h) Ensure the implementation and compliance of applications and products with application-specific policy requirements, and identify and manage risk where applications and products do not meet policy requirements

(i) Verify compliance with usage procedures

(j) Ensure adherence to this certificate policy within their area of responsibility

1.3.5.3.2 Ministries, agencies and the BPS Ministries, agencies and the BPSCustodians of Information and Information Technology

Custodians of information and information technology specify functional requirements for the integration of PKI security services into applications. Custodians are responsible for:

(a) Determining what different programs may require the security services of the GO-PKI, and integrate appropriate functions into in-house applications

(b) Evaluating information technology products in light of policy requirements and advising program managers as to their level of compliance

(c) Advising program managers as to the risk of implementing products that do not meet policy requirements

1.4 Certificate Usage

To support non-repudiation, this certificate policy specifies the use of two separate key pairs and associated public key certificates:

A public encryption key, a private decryption key, and an associated public encryption key certificate in support of confidentiality

A private digital signature key, a public verification key, and an associated public verification key certificate in support of authentication, integrity, and non-repudiation.



The GO-PKI CA shall advise its subscribers of the PKI client applications that may make use of the keys and certificates issued under this certificate policy.

1.4.1 Appropriate Certificate Uses

1.4.1.1 High Assurance

Encryption key pairs and public encryption key certificates issued under the high assurance specifications may be used for encryption key establishment when encrypting information that if compromised could reasonably be expected to cause extremely grave injury to one of the parties involved.

Digital signature key pairs and public verification key certificates may be used for authentication, integrity, and non-repudiation of business transactions within the originator’s approval limits and such that the falsification of the transaction would cause the loss of life, imprisonment, major financial loss, or require legal action for correction.

1.4.1.2 Medium Assurance

Encryption key pairs and public encryption key certificates issued under the medium assurance specifications may be used for encryption key establishment when encrypting information that if compromised could reasonably be expected to cause serious injury to one of the parties involved.

Digital signature key pairs and public verification key certificates may be used for authentication, integrity, and non-repudiation of business transactions within the originator’s approval limits and such that the falsification of the transaction would cause significant financial loss, or require legal action for correction.

1.4.1.3 Basic Assurance

Encryption key pairs and public encryption key certificates issued under the basic assurance specifications may be used for encryption key establishment when encrypting information that if compromised could reasonably be expected to cause minor injury to the parties involved.

Digital signature key pairs and public verification key certificates may be used for authentication, integrity, and non-repudiation of business transactions within the originator’s approval limits and such that the falsification of the transaction would cause only minor financial loss, or require only administrative action for correction.

1.4.2 Prohibited Certificate Uses

All uses not explicitly authorized for use with GO-PKI certificates by the PMA are prohibited.

1.5 Policy Administration

1.5.1 Organization Administering the Document

This certificate policy is administered by the GO-PKI Operational Authority as appointed by the PMA.



1.5.2 Contact Person

You may contact the following organization to obtain more information concerning this policy and its implementation.

Corporate Security Branch Ministry of Government Services 5th Floor 155 University Avenue Toronto, Ontario TEL.: (416) 327-0967 FAX : (416) 327-3262

1.5.3 Organization/Role Determining CPS Suitability for the Policy

The GO-PKI Certification Practice Statement is administered by the GO-PKI Operational Authority.

1.5.4 CPS Approval Procedures

The GO-PKI Certification Practice Statement is approved by the PMA.

1.6 Definitions and Acronyms

Refer to Appendix A – Glossary . Appendix B – List of Acronyms and Appendix C – Roles and Responsibilities

2 PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1 Repositories

The GO-PKI Operational Authority shall use the directory services of the Government of Ontario for publishing the primary certificates and the GO-PKI CA’s certificate revocation list (CRL) and authority revocation list (ARL). The GO-PKI Operational Authority shall ensure that a service level agreement is in place that satisfies the requirements specified in this Certificate Policy.

At a minimum, the Repository service level agreement shall specify:

(a) The expected performance of the directory services

(b) The responsibilities of each organization

(c) The logical access controls and privileges

(d) The minimum operational requirements (e.g., backup frequency, log processing, performance monitoring, etc.)

(e) The problem and configuration management controls

(f) The frequency and requirements for conducting compliance audits



Distinguished names used in the primary repository’s directory shall follow the rules specified in section 3.1. The distinguished name used for a subscriber in the primary repository’s directory shall not be used as a role identifier in a consistent use domain.

The CA shall implement sufficient contingency measures (e.g., redundancy, fail-over utility) to ensure a high repository availability and allow for contingency recovery within the appropriate CRL issuance period specified in section 4.9.7.

2.2 Ministries, agencies and the BPSPublication of Certification Information

This manual shall be published on the Government of Ontario’s intranet site for reference by internal subscribers and relying parties. It shall also be published on the Government of Ontario’s public web site for reference by external subscribers and relying parties.

The GO-PKI Operational Authority shall publish on the Government of Ontario’s public web site the GO-PKI CPS for reference by the subscriber communities of external CAs that have established cross-certification agreements with the GO-PKI.

The CA shall:

Include within any certificate it issues the URL of a web site maintained by, or on behalf of, the CA

Ensure the publication of this certificate policy and the GO-PKI CA’s CPS, digitally signed by an authorized representative of the CA, on the CA’s web site

Ensure, directly or through an agreement with an entity controlling the directory, that operating system and directory access controls will be configured so that only authorized CA personnel can write or modify the on-line version of this certificate policy

Provide a full text version of the CPS when necessary for the purposes of any audit and accreditation

The CA shall ensure, directly or through its agreement with an entity controlling the directory, that a relying party has the ability to verify individual certificates on the CRLs.

2.3 Time or Frequency of Publication

Certificates shall be published promptly on the directories upon issuance.

2.4 Access Controls on Repositories

Access controls may be instituted at the discretion of the CA with respect to individual certificates or on-line certificate status (if the CA provides the latter as a service).

The repository shall be protected by logical access controls such as user accounts and passwords so as to limit on-line access to authorized individuals. Access requirements are normally as follows:

Read access by relying parties and subscribers

Read and write access by CA and RA personnel



3 IDENTIFICATION AND AUTHENTICATION

3.1 Naming

3.1.1 Types of Names

Each certificate shall have a clearly distinguishable and unique X.501 DN in the subject name field in accordance with RFC 3280 [3]. Certificates may have an alternative name in the subject alternate name field, which shall also be in accordance with RFC 3280 [3]. The DN shall be in the form of an X.501 printable string and shall not be blank.

3.1.2 Need for Names to be Meaningful

The contents of each certificate subject and issuer name fields shall have an association with the authenticated name of the subscriber. In the case of individuals, the relative distinguished name (RDN) should be a combination of given name, surname, and, optionally, initials. In the case of an organization, the RDN will reflect its authenticated name.

Where a certificate is assigned to a role, a group, a device, or an application, the certificate shall not contain the identity of the individual who accepted responsibility for the PSE.

3.1.3 Anonymity or Pseudonymity of Subscribers

The GO-PKI CA shall not issue certificates to anonymous or pseudonymous subscribers..

3.1.4 Rules for Interpreting Various Name Forms

Rules for interpreting name forms shall be in accordance with the Certificate Profile, defined in section 7.1.

Standards may include:

X.501 for DN;

RFC 822 for email address; and

Appropriate IETF RFCs for URL and IP address..

3.1.5 Uniqueness of Names

Distinguished names shall be unique for all subscribers of the CA. For each subscriber, additional numbers or letters may be appended to the common name to ensure the RDN’s uniqueness. The unique identifiers’ capability to differentiate subscribers, for example by function, with identical names shall not be used.

3.1.6 Recognition, Authentication, and Role of Trademarks

The CA shall not knowingly assign names that contain trademarks. The CA need not seek evidence of trademark registrations nor in any other way enforce trademark rights.



3.2 Initial Identity Validation

3.2.1 Method to Prove Possession of Private Key

Prior to the issuance of a certificate, the CA and the subscriber shall confirm their respective identities through the use of a shared secret. The key transfer protocol described in RFC2510 is suitable for this requirement.

3.2.2 Authentication of Organization Identity

The PMA shall determine whether a PKI certificate may be issued to an organization.

3.2.2.1 Medium and High Assurance

The RA shall identify and authenticate an organization requesting certificates through one of the following means:

The RA shall examine notarized copies or original documentation providing evidence of the existence of the organization

If the sponsor has previously registered the organization using a process that satisfies the CA, and there have not been any changes in the organization’s information since that registration, then the RA may authenticate the organization on the basis of the privately shared information, providing the organization explicitly authorizes the use of this information by the RA

The RA shall also verify the identity of the individual acting on behalf of the organization as specified in section 3.2.3, and their authority to receive the keys on behalf of that organization.

The RA shall keep a record of the type and details of identification used.


For basic assurance certificates, the RA may accept organization documentation that has not been inspected for authenticity.

3.2.2.3 Authentication of Organizational Roles, Groups, Devices, and Applications

For these situations, an individual to which the signature of the organizational role, group, device, or application is attributable for the purposes of accountability shall submit a certificate issuance request, and the RA shall perform identification and authentication as specified in section 3.2.3.

3.2.3 Authentication of Individual Identity


The RA shall identify and authenticate prospective subscribers through one of the following means:

The RA/LRA shall check the identification of the prospective subscriber using two (2) pieces of identification (notarized copies or originals). The primary identification document shall be a government-issued identification with a photograph and document number that has been issued under a standardized registration process. The second document shall have a name and address consistent with the primary document.



In the event that the client does not have a primary piece of identification with a photo, he/she must present three pieces of approved identification that includes at least one primary piece plus a secondary with a photo.

If the sponsor has previously registered the prospective subscriber using a process that satisfies the CA, and there have not been any changes in the prospective subscriber’s information since that registration, then the RA may authenticate the prospective subscriber on the basis of the privately shared information, providing the prospective subscriber explicitly consents to the use of this information by the RA

The GO-PKI CPS shall provide details on the documentation that is acceptable for meeting the authentication of individual identity requirements.

The RA shall keep a record of the type of identification used and the details from the primary identification document. Any document protected by law shall be used only as a secondary identification document and only under circumstances where the prospective subscriber has volunteered the document and consented to its use as a secondary document.


For high assurance certificates, the RA shall issue PKI profiles on tokens (e.g. smart cards). Prospective subscribers shall present themselves in person to the RA for authentication before having their token initialized.


For basic assurance certificates, the RA may accept photocopies of the pieces of identification.

3.2.4 Non-verified Subscriber Information

The RA shall ensure that all subscriber information that is relevant to the identification or authentication of the Subscriber is inspected for authenticity.


For basic assurance certificates, the RA may accept information from a reliable source without additional verification.

3.2.5 Validation of Authority

The authority to create and manage the LRAs is delegated to the HLRA by the RA.

The authority to create and manage Subscribers within a domain is delegated to the LRAs by the HLRA.

3.2.6 Criteria for Interoperation

The PMA is responsible for establishing cross-certification agreements and the criteria for interoperability with CAs external to the GO-PKI CA. Refer to the Interoperability Standard specified in Chapter 15.



3.3 Identification and Authentication for Re-key Requests

3.3.1 Identification and Authentication for Routine Re-key

Identity for routine rekey shall be established either through the use of the current signature key, provided that it has not been revoked or expired, or through authentication data collected during the registration process.

3.3.2 Identification and Authentication for Re-key After Revocation

The RA shall authenticate the subscriber in the same manner as for initial registration. Any change in the information contained in the revoked certificate shall be verified by the RA before the new certificate is issued.

3.4 Identification and Authentication for Revocation Request

The RA shall authenticate the originator of a request for revocation or suspension of a certificate and handle the request following the process specified by the CA. Requests for the revocation or suspension of certificates shall be logged.

4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate Application

This operation consists of the submission of an application for a prospective subscriber to obtain an initial set of keys and certificates. Registration may be performed manually by the RA or through an automated pr ocess.

The CA shall ensure that all procedures and requirements with respect to an application for certificates are set out in its CPS. The CA shall accept applications only when approved by a recognized RA.

4.1.1 Who Can Submit a Certificate Application

Individuals and organizations who belong to a consistent use domain may request certificates. All certificate issuance requests shall be authorized by a sponsor recognized by the CA.

4.1.2 Enrolment Process and Responsibilities

To have a certificate issued, a prospective subscriber shall apply to the LRA in person following the process specified by the CA. The LRA may accept bulk requests only when bulk requests are authorized by the PMA.

The LRA shall ensure that subscribers obtain the information they need to make proper use of the PKI services. As a minimum, the LRA shall make available to subscribers the following information:

How to properly submit service requests to the LRA

How to obtain help during and after regular working hours



How to use PKI client applications (if required)

The LRA may provide such information through formal subscriber training, which may also be delivered by the sponsor who has received the requisite training by the LRA.

4.1.2.1 Non-individual Certificates

Ministries, agencies and the BPS may request certificates for the purpose of assigning them to a business unit, an organization, an organizational role, a group, a device, or an application rather than to an individual. For a certificate to be issued for such a purpose, the following rules apply:

(a) The ministry or agency shall appoint an individual who will accept responsibility and accountability for the certificate’s use.

(b) The issuance of certificate shall be based on a request that is signed by the appointee to acknowledge their responsibilities and authorized by a senior official (at least Director level).

(c) The appointee shall protect the PKI profile from unauthorized access by ensuring the implementation of physical access controls, logical access controls, or a combination thereof.

(d) The ministry or agency shall inform the CA when the responsibility for the PKI profile will change, and they shall provide the name, position and contact information of the new appointee.

(e) The CA shall keep a record of the appointee’s name, position and contact information. When notified of a change of appointee, the CA shall revoke and reissue the certificate with the appropriate reason code, and update the record for the new appointee.

4.1.2.1.1 Device and Application Certificates

For a certificate to be issued for a device or application, the following additional rules apply:

a) The appointee shall have a personal certificate at a medium level of assurance or higher and the device/application certificate agreement shall be bound to the appointee’s subscriber agreement.

b) The appointee shall ensure that the device/application certificate is deployed in compliance with implementation practices established by the CA.

c) If a unit operates the device/application, the appointee shall only release the certificate password to a unit member when needed for set-up or a key update, and log the unit member name and the date when the password is released.

d) The CA shall have a process described in the CPS to confirm accountability for all device/application certificates.

e) External organizations that request device/application certificates shall assume responsibility for any failure by their employee to comply with his or her obligations as set out in the Device/Application Certificate Agreement.

4.1.2.1.2 Group Certificates

For a certificate issued for a group, business unit, organization or organizational role (i.e. a group), the following additional rules apply:

a) The Corporate Security Branch shall do a security assessment that considers risk factors such as the size of the group and determines if a group certificate is the correct solution.



b) All members of the group shall have a personal certificate at a medium level of assurance or higher.

c) The appointee shall ensure that the certificate password is changed whenever the group membership changes and that a log of group membership changes is maintained.

d) The certificate shall be used only for encryption/decryption of transmissions sent to the group i.e. not enabled for identity authentication or digital signature.

e) The certificate shall be renewed annually after confirmation is received that it is still required.

4.2 Certificate Application Processing

This section is used to describe the procedure for processing certificate applications. The RA shall perform identification and authentication procedures to validate the certificate application. Following such steps, the CA or RA shall either approve or reject the certificate application.

4.2.1 Performing Identification and Authentication Functions

The LRA shall ensure that each request be vetted for:

Proof of the requester’s identity and, when applicable, of the organization’s identity;

The name of the organizational unit, role, group, device, or application, when applicable;

Proof of authorization for any requested certificate attributes;

Authorization for use for legitimate government business; and

A signed agreement of the applicable terms and conditions governing the use of the keys and associated certificates.

4.2.2 Approval or Rejection of Certificate Applications

Certificate applications shall be approved provided that the application has been completed and vetted in accordance with this certificate policy and the LRA is in good standing.

4.2.3 Time to Process Certificate Applications

There is no stipulation for the period between the receipt by the CA of a request and the issuance of the subscriber’s keys and certificates.


For a high level of assurance, the CA shall ensure that the subscriber completes the initialization process immediately upon receipt of the activation data.


The CA shall ensure that the subscriber completes the initialization process within two (2) working days of receiving the activation data.




For a basic level of assurance, the CA shall ensure that the subscriber completes the initialization process within five (5) working days of receiving the activation data.

4.3 Certificate Issuance

Certificate issuance is the process by which the GO-PKI CA generates and publishes a public key certificate.

4.3.1 CA Actions During Certificate Issuance

As part of the certificate issuance process, the CA may generate an encryption key pair on behalf of the subscriber, and transfer in a secure manner the private key to the subscriber’s PKI profile.

4.3.2 Notification to Subscriber by the CA of Issuance of Certificate

By issuing certificates to a subscriber, the CA certifies that it has issued the certificates to an authorized subscriber and that the information stated in the certificates was verified in accordance with this certificate policy.

4.4 Certificate Acceptance

This section specifies the actions of an applicant that shall be deemed to constitute acceptance of the certificate.

4.4.1 Conduct Constituting Certificate Acceptance

The CA shall provide a process by which its subscribers accept the issuance of their certificates. This process may be in the form of a computer message and response, or an acknowledgement in electronic or paper form.

4.4.2 Publication of the Certificate by the CA

All certificates issued by the CA and all CRLs relating thereto shall be published in the Repository.

4.4.3 Notification of Certificate Issuance by the CA to Other Entities

The CA shall not notify entities, other than the above mentioned Repository, of certificate issuance.

4.5 Key Pair and Certificate Usage

4.5.1 Subscriber Private Key and Certificate Usage

The intended scope of usage for a private key is specified through certificate extensions, including the keyUsage and extendedKeyUsage extensions, in the associated certificate.

4.5.2 Relying Party Public Key and Certificate Usage

Relying parties shall use certificates and public keys exclusively for the purposes stipulated in section 1.4. Relying parties shall comply with the representations and warranties stipulated in section 9.6.4.



4.6 Certificate Renewal

4.6.1 Circumstance for Certificate Renewal

Certificate renewal means the issuance of a new certificate to the subscriber without changing the subscriber’s public key or any other information in the certificate. The GO-PKI CA shall require certificate re-key prior to expiry, to enforce strong security practices, and shall not support certificate renewal.

4.6.2 Who May Request Renewal

No stipulation.

4.6.3 Processing Certificate Renewal Requests

No stipulation.

4.6.4 Notification of New Certificate Issuance to Subscriber

No stipulation.

4.6.5 Conduct Constituting Acceptance of a Renewal Certificate

No stipulation.

4.6.6 Publication of the Renewal Certificate by the CA

No stipulation.


No stipulation.

4.7 Certificate Re-key

Certificate rekey is defined as creating a new certificate that has the same characteristics and assurance level as the old one. However, the new certificate has a new, different public key (corresponding to a new, different private key), a different certificate serial number, and is assigned a new validity period.

An authenticated re-key request and any resulting actions taken by the CA shall be recorded and retained.

4.7.1 Routine Re-Key

The CA application may allow keys to be renewed automatically at the end of one of the key’s validity period. Prior to initiating a re-key, the CA application shall confirm the identity of the subscriber through the use of a shared secret. The key transfer protocol described in RFC2510 is suitable for this requirement.

The CA shall ensure that routine re-key occurs within three months prior to the expiration of one of the keys, provided the corresponding certificate has not been revoked.



4.7.2 Re-key After Revocation

The CA shall set out in its CPS the process by which it handles re-key after revocation.

4.7.3 Circumstance for Certificate Re-key

A re-key operation is initiated automatically at the scheduled key renewal time. In the following circumstances, this process may be initiated manually:

The subscriber may submit a re-key request to the LRA due to suspected key compromise or for recovery of activation data; and

The LRA may submit a re-key request on behalf of a subscriber to extend the subscriber’s membership in the GO-PKI or to effect a change in assurance level.

4.7.4 Who May Request Certification of a New Public Key

Certificate re-keying requests shall be initiated automatically by the subscriber’s PKI application or come from the LRA on behalf of subscribers.

4.7.5 Processing Certificate Re-keying Requests

Subscriber certificates shall be configured for either automated re-key or manual re-key. A certificate shall not be automatically re-keyed if the subscriber’s private signing key has expired.


No stipulation.

4.7.7 Conduct Constituting Acceptance of a Re-keyed Certificate

No stipulation.

4.7.8 Publication of the Re-keyed Certificate by the CA

All re-keyed certificates issued by the CA and all CRLs relating thereto shall be published in the Repository.



4.8 Certificate Modification

Certificate modification is defined as creating a new certificate that has the same key and a different serial number, and that differs in one or more other fields from the old certificate. The old certificate shall be revoked,.

Device certificates shall not be modified; an application for a new device certificate under the new device name shall be made instead. The certificate issued under the old device name shall be revoked at the time that the old device is removed from service or ceases to provide certificate-based functionality.

4.8.1 Circumstance for Certificate Modification

The CA shall permit certificate modification under the following conditions:



Current certificate requires an update or modification of information affecting the subject name (i.e. DN change).

4.8.2 Who May Request Certificate Modification

Certificate modification requests shall come from the LRA on behalf of subscribers.

4.8.3 Processing Certificate Modification Requests

Proof of a subscriber’s name change shall be provided to the LRA and the subscriber shall follow the re-key process.


No stipulation.

4.8.5 Conduct Constituting Acceptance of Modified Certificate

No stipulation.

4.8.6 Publication of the Modified Certificate by the CA

All modified certificates issued by the CA and all CRLs relating thereto shall be published in the Repository.



4.9 Certificate Revocation and Suspension

The revocation operation is used to prevent further use of a public key:



Upon suspected or known compromise of the medium (e.g. a diskette) holding the associated private key

When the subscriber fails to comply with his or her obligations

Upon request of an entity as listed in section 4.9.2.

The suspension operation is used to prevent use of a subscriber’s public key while they are on an extended leave (e.g., maternity/paternity leave, sabbatical), or during an investigation into a suspected misuse of the certificate.

4.9.1 Circumstances for Revocation

A certificate shall be revoked:





Upon suspected or known compromise of the medium (e.g., a diskette) holding the associated private key

When the subscriber fails to comply with their obligations described by policy, the subscriber’s agreement, or applicable law

Upon request of an entity as listed in section 4.9.2.

4.9.2 Who Can Request Revocation

The revocation or suspension of a certificate shall be requested through the RA and may be requested only by:

The individual under whose name the certificate was issued;

The sponsor;

The CA Operational Authority,

The CA; or

The subscriber’s RA/LRA.

4.9.3 Procedure for Revocation Request

The CA shall set out in its CPS the process by which it handles certificate revocations and suspensions, and the means by which it establishes the validity of the requests.

Where a subscriber’s certificate has been revoked as a result of non-compliance, the CA shall verify that all reasons for non-compliance have been addressed to its satisfaction prior to approving a re-key after revocation.

Authenticated revocation and suspension requests and any resulting actions taken by the CA shall be recorded and retained. The CA shall document the reason for the revocation or suspension.

All revocations and suspensions shall be published in a CRL.

Once revoked or suspended, the certificate’s serial number is added to a certificate revocation list (CRL) with an appropriate reason code and posted by the CA application to the CA’s repository.

4.9.4 Revocation Request Grace Period

Subscribers shall place a revocation request within four (4) hours of the time of discovery of a key compromise or certificate usage abuse. For other reasons leading to the need for revocation, the certificate revocation request shall be placed within 24 hours.

4.9.5 Time Within Which CA Must Process the Revocation Request

The CA shall provide a process for handling revocation requests outside normal business hours that require immediate processing.


Any action taken as a result of a request for the revocation of a certificate shall be initiated within the same business day.




For a high level of assurance, the action shall be initiated immediately upon receipt.


For a basic level of assurance, the action shall be initiated within the next business day.

4.9.6 Revocation Checking Requirement for Relying Parties

Prior to using a certificate, applications shall check the certificate’s status against the CRL. If it finds the certificate, then it shall react accordingly based on the reason code, the PKI security service called, and the business process involved. Before using a certificate, the PKI client application shall perform the certification path validation procedure specified in RFC 3280 [3]. The status of certificates may be checked against a CRL or it may be obtained from an on-line service that provides an equivalent level of assurance.

4.9.7 CRL Issuance Frequency

The CA shall ensure that it issues an up-to-date CRL at least every twelve (12) hours. When a certificate is revoked due to key compromise or security concerns, the updated CRL shall be issued immediately.

4.9.8 Maximum Latency for CRLs

The CA shall ensure that its CRL issuance is synchronized with any directory synchronization to ensure the accessibility of the most recent CRL to relying parties.

4.9.9 On-line Revocation/Status Checking Availability

The CA may provide on-line revocation status checking. If so, the service shall provide a level of assurance that is equivalent to a digitally signed CRL. The protocol described in RFC2560 [6] is suitable for this service.

4.9.10 On-line Revocation Checking Requirements

No stipulation.

4.9.11 Other Forms of Revocation Advertisements Available

No stipulation.

4.9.12 Special Requirements re: Key Compromise

In the event of a compromise or suspected compromise of the CA signing key, or of any other CA private key, the CA shall immediately notify the policy management authority and perform the recovery procedures specified in section 5.7.3.

The CA shall ensure that it’s CPS and appropriate agreements contain provisions outlining the means it will use to provide notice of compromise or suspected compromise.

The subscriber in whose name the revoked certificate has been issued may make a request for re-key after revocation. The re-key shall be authorized by the RA and be manually initiated by the RA. Such an operation shall be performed when a certificate is revoked for suspected or known key compromise.



4.9.13 Circumstances for Suspension

A certificate shall be suspended:

When the subscriber will be on an extended leave of more than two months (e.g., maternity/paternity leave, sabbatical), or

During an investigation into a suspected misuse of the certificate.

4.9.14 Who Can Request Suspension

As stipulated in section 4.9.2.

4.9.15 Procedure for Suspension Request

Refer to section 4.9.3.

4.9.16 Limits on Suspension Period

There is no fixed limit on the suspension period. In the case of extended leaves, suspensions should only be used in lieu of a termination when it is clear that the individual will return.

4.10 Certificate Status Services

4.10.1 Operational Characteristics

The CA shall publish its CRL to the Repository.

4.10.2 Service Availability

No stipulation.

4.10.3 Optional Features

No stipulation.

4.11 End of Subscription

The CA shall set out in its CPS the process by which it handles subscriber termination.

An authenticated termination request and any resulting actions taken by the CA shall be recorded and retained.

4.11.1.1 Circumstances for Subscription Termination

The subscriber termination operation shall be performed when the subscriber no longer needs or is not eligible to continue to be a subscriber of the PKI services.

4.11.1.2 Who Can Request Subscription Termination

A subscriber termination operation may only be requested by the subscriber, the sponsor, the CA or the subscriber’s RA.



4.11.1.3 Authentication for Subscription Termination

The RA shall authenticate the originator of a request for subscriber termination following the process specified by the CA.

4.12 Key Escrow and Recovery

4.12.1 Key Escrow and Recovery Policy and Practices

The CA shall set out in its CPS the process by which it handles key recovery requests and the means by which it establishes the validity of the request.

An authenticated recovery request and any resulting actions taken by the CA shall be recorded and retained.

The recovery operation may be required to recover private decryption keys backed up by the CA application. The recovery operation allows:

A subscriber to recover their private decryption keys when they have forgotten their PKI profile’s activation data (e.g., their password) or when their PKI profile has been lost or is otherwise irrecoverable

A sponsor to recover encrypted data for a person entitled to see the data when the subscriber is unavailable or unwilling to do so

If the request comes from a sponsor, and the operation causes the generation of a digital signature key pair and a corresponding digital signature verification certificate under the subscriber’s name, then the CA shall implement additional procedures to prevent the use of the subscriber’s digital signature private key.

4.12.1.1 Circumstances for Key Recovery

The recovery process applies to private decryption keys only.

The recovery operation may be performed when:

A subscriber has forgotten their PKI profile’s activation data (e.g., their password) or the PKI profile has been lost or is otherwise irrecoverable;

A sponsor needs to recover encrypted information when the subscriber is unavailable to do so; or

Access to subscriber data is required for forensic investigation purposes.

4.12.1.2 Who Can Request Key Recovery

A key recovery may only be requested by the subscriber, the sponsor (Director level and above), the CA Operational Authority or other person entitled by law.

4.12.1.3 Authentication for Key Recovery

The RA shall authenticate the originator of any request for recovery and the person’s authority to request recovery following the process specified by the CA.



4.12.2 Session Key Encapsulation and Recovery Policy and Practices

No stipulation.

5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

5.1 Physical Controls

5.1.1 Site Location and Construction

5.1.1.1 Certification Authorities

The following physical security safeguards shall be implemented at the CA site:

Manual and electronic monitoring for unauthorized intrusion at all times

Unescorted access to the CA system shall be limited to those personnel identified on an access list

Personnel not on the access list shall be properly escorted and supervised at all times

A site access log shall be maintained at all times and audited periodically

5.1.1.2 Registration Authorities

RA sites shall be located in operation zones with physical security safeguards normally implemented for such areas. As a minimum, an operation zone shall have the following characteristics:

Be accessible only from a reception zone

Access limited to personnel who work within the zone and to escorted visitors

Monitored for intrusion

If an RA workstation is used for requesting subscriber management operations on-line with the CA application, the RA site shall provide appropriate security protection of cryptographic modules, system software, and the RA personnel’s private keys. For example, cryptographic modules and media containing an RA administrator’s PKI profile could be stored in a secure container or safe when not in use.

5.1.2 Physical Access

The CA’s certificate and CRL repository shall be located in a security zone equipped with physical security safeguards normally implemented in rooms where information technology equipment such as file or application servers is operated.

5.1.3 Power and Air Conditioning

The CA shall ensure that the power and air conditioning facilities are secure and sufficient to support the operation of the CA systems.

The CA systems should be protected by emergency power generation equipment, such as uninterruptible power supplies and diesel generators.



5.1.4 Water Exposures

The CA shall ensure that the CA systems are protected from water exposure.

5.1.5 Fire Prevention and Protection

The CA shall ensure that the CA systems are protected with a fire alarm and suppression system.

5.1.6 Media Storage


The CA shall ensure that storage media used for the CA operations are protected from environmental threats such as temperature, humidity, and magnetism.

All removable media and paper containing sensitive plain text information shall be stored in secure containers. When recorded for contingency purposes, PINs or passwords shall be stored in a security container accessible only by authorized personnel.


RA administrators shall store in secure containers all removable media and paper containing sensitive plain text information, and dispose of such media and paper in a secure and complete manner (e.g., by shredding). When recorded for contingency purposes, PINs or passwords shall be stored in a secure container accessible only by authorized RA personnel.

5.1.7 Waste Disposal

All media used for the storage of information such as keys, activation data, or CA files are to be sanitized or destroyed before released for disposal.

Printed material containing sensitive information shall be disposed of in a secure and complete manner. Other directives, laws and regulations may provide for the disposal of media. Reference shall be made to ensure compliance.

5.1.8 Off-site Backup

The CA shall ensure that facilities used for off-site back-up have the same level of physical security as the CA site.

5.2 Procedural Controls

5.2.1 Trusted Roles


The CA shall ensure that all personnel performing duties with respect to the operation of the CA shall:

Be appointed in writing

Be bound by contract or statute to the terms and conditions of the position they are to fill

Have received comprehensive training with respect to the duties they are to perform



Be bound by contract or statute not to disclose sensitive information

Not be assigned duties or take on obligations that may cause a conflict of interest with their CA duties


The CA may delegate certain subscriber management operations to the RA. The extent of this delegation will depend largely on local policies, and may vary from basic to full subscriber management capabilities. If the RA is delegated the responsibility to assign trusted roles to RA personnel, then the RA shall ensure the separation of duties as specified below.

The RA shall ensure that all personnel performing duties with respect to the operation of the RA:

Are appointed in writing

Are bound by contract or statute to the terms and conditions of the position they are to fill

Have received comprehensive training with respect to the duties they are to perform

Are bound by contract or statute not to disclose sensitive information

Are not assigned duties or do not take on obligations that may cause a conflict of interest with their RA duties

5.2.2 Number of Persons Required per Task


Multi-person control is required for CA key generation.

The CA shall ensure that any verification process it employs provides for the oversight of all activities performed by all CA personnel.


In situations where a sponsor shall recover data that is encrypted for an absent subscriber, the request to recover the subscriber’s keys shall be submitted to the RA for authorization. The LRA and an individual designated by the sponsor shall be present when performing the key recovery operation.

All other duties associated with RA roles, including key recovery for other reasons than data recovery, may be performed by an individual operating alone.

The RA shall ensure that any verification process it employs provides for the oversight of all activities performed by all RA personnel.

5.2.3 Identification and Authentication for Each Role


The CA shall verify the identity and authorization of its personnel before they are:

Included in the access list for the CA site

Included in the access list for physical access to the CA system

Given a certificate for the performance of their CA role



Given an account on the CA system

Each of these certificates and accounts shall:

Be directly attributable to an individual

Not be shared

Be restricted to actions authorized for that role through the use of application access controls, operating system access controls, and procedural controls

The CA shall check the identity of its personnel using three (3) pieces of identification (notarized copies or originals). At least one of these shall be a government-issued identification containing a photograph.

CA operations shall be secured using mechanisms such as token-based strong authentication and encryption when accessed across a shared network.


The RA shall verify the identity and authorization of its personnel before they are:

Given a certificate for the performance of their RA role

Given an account on the CA system or application

Each of these certificates and accounts shall:

Be directly attributable to an individual

Not be shared

Be restricted to actions authorized for the PKI role through the use of application access controls, operating system access controls, and procedural controls

The RA shall check the identity of its personnel using three (3) pieces of identification (notarized copies or originals). At least one of these shall be a government-issued identification containing a photograph.

RA operations shall be secured using mechanisms such as token-based strong authentication and encryption when accessed across a shared network.

5.2.4 Roles Requiring Separation of Duties


The CA shall ensure a separation of duties for critical CA functions to prevent one person from having the capacity to maliciously use the CA system without detection. The system access for each such person is to be limited to those actions required to perform his/her responsibilities.

The CA shall provide for a minimum of three CA personnel, each with a distinct role, distinguishing between day-to-day operation of the CA system, the management and audit of those operations, and the management of substantial changes to requirements on the system, including policies, procedures, and personnel. The division of responsibilities among the three roles should be as follows:

PKI Master User:

Configuration and maintenance of the CA system hardware and software

Commencement and cessation of CA services



PKI Officer:

Management of PKI administrators and other PKI officers

Configuration of CA security policies

Verification of audit logs

Verification of certificate policy compliance

PKI Administrator:

Performance of CA functions

Distribution of tokens (where applicable)

Alternative divisions of responsibilities are permitted so long as they provide the same degree of resistance to insider attack.

Only those personnel responsible for the duties outlined for PKI master user, PKI officer, and PKI administrator are allowed to have access to the software that controls the CA operation.


The RA shall ensure a separation of duties for critical PKI functions to prevent one person from maliciously using the CA system without detection. Each RA personnel’s CA application access is to be limited to those actions that each user is required to perform in fulfilling their delegated responsibilities.

The RA shall provide for a minimum of two RA personnel, each with a distinct role, distinguishing between day-to-day operations, and the management and audit of those operations. The division of responsibilities between the two roles should be as follows:

RA:

Management of LRAs

Verification of audit logs

RA/Head LRA:

Performance of subscriber management operations (as delegated by the CA)

Distribution of tokens (where applicable)

5.3 Personnel Controls

5.3.1 Qualifications, Experience, and Clearance Requirements


The CA shall ensure that its personnel have the appropriate qualifications and experience to perform their duties.


The RA shall assign RA duties to trusted individuals having appropriate qualifications and experience.



5.3.2 Background Check Procedures


An enhanced reliability security screening is mandatory for all staff employed in the GO-PKI CA. Staff nominated to work in positions within GO-PKI shall successfully pass the screening before being employed in the position. This screening is composed of:

verification of personal data, education and professional qualification, employment data and references through the regular staffing process;

a declaration concerning any conviction for a criminal offence for which a pardon has not been granted, and

a criminal record name check.


An enhanced reliability security screening is mandatory for all staff employed in the GO-PKI RA/LRA network. Staff nominated to work in positions within GO-PKI shall successfully pass the screening before being employed in the position. This screening is composed of:

verification of personal data, education and professional qualification, employment data and references through the regular staffing process;

a declaration concerning any conviction for a criminal offence for which a pardon has not been granted, and

a criminal record name check.

5.3.3 Training Requirements


The CA shall ensure that all personnel performing duties with respect to the operation of the CA receive comprehensive training in:

PKI security principles and mechanisms

All software versions in use on the CA and RA system

All CA duties they are expected to perform

Roles and responsibilities of an RA

Disaster recovery and business continuity procedures


The RA shall ensure that all personnel performing duties with respect to the operation of the RA receive comprehensive training in the following areas as relevant to their duties:

The RA security principles and safeguards

All PKI software versions in use in the RA and subscriber environments

All RA duties they are expected to perform



Disaster recovery and business continuity procedures, if implemented

5.3.4 Retraining Frequency and Requirements


The requirements specified in section 5.3.3.1 shall be kept current to accommodate changes in the local PKI environment. The CA shall review these requirements at least once a year and conduct refresher training as required.


The requirements specified in section 5.3.3.2 shall be kept current to accommodate changes in the RA environment. The RA shall review these requirements at least once a year and conduct refresher training as required.

5.3.5 Job Rotation Frequency and Sequence

No stipulation.

5.3.6 Sanctions for Unauthorized Actions


In the event of actual or suspected unauthorized action by a person performing duties with respect to the operation of the GO-PKI CA, the CA may suspend their access to the CA site and related systems and applications.


In the event of actual or suspected unauthorized action by a person performing duties with respect to the operation of the RA, the RA may suspend their access to the RA site and related systems and applications.

5.3.7 Independent Contractor Requirements


The CA shall ensure that access to the CA site by personnel employed by third party contractors is in accordance with section 5.1.2.


The RA shall ensure that access to the RA site by personnel employed by third party contractors is in accordance with the requirements in this section .

5.3.8 Documentation Supplied to Personnel


The CA shall make available to its personnel any statutes, policies, contracts, hardware and software documentation, and operational procedures relevant to their position, except as restricted by law or contract.




The RA shall make available to its personnel any statutes, policies, contracts, hardware and software documentation, and operational procedures relevant to their position except as restricted by law or contract.

5.4 Audit Logging Procedures

5.4.1 Types of Events Recorded

The CA shall record in audit log files all events relating to the security of the CA system. These include such events as:

System start-up and shutdown

CA application start-up and shutdown

Attempts to create, remove, set passwords, or change the system privileges of user accounts

Changes to CA keys

Changes to certificate creation policies (e.g., validity period)

Login and logoff attempts

Unauthorized attempts at network access to the CA system

Unauthorized attempts to access system files

Generation of own and subordinate entity keys

Creation and revocation of certificates

Attempts to initialize, remove, enable and disable subscribers, and update and recover their keys

Failed read and write operations on the certificate and CRL directory

The CA shall also collect and consolidate, either electronically or manually, security information not generated by the CA system, such as:

Physical access logs

System configuration changes and maintenance

Personnel changes for the CA and RAs

Discrepancy and compromise reports

Records of the destruction of media containing key material, activation data, or personal subscriber information

All logs, whether electronic or manual, shall contain the date and time of the event and the identity of the entity which caused the event.

The CA shall ensure that its CPS indicates what information is logged.

To facilitate decision making, all agreements and correspondence relating to CA services shall be collected and consolidated, either electronically or manually, in a single location.



5.4.2 Frequency of Processing Log

The CA shall ensure that its audit logs are reviewed by CA personnel at least once every week, and that all significant events are explained in an audit log summary. Such reviews involve verifying that the logs have not been tampered with and then briefly inspecting all log entries, with a more thorough investigation of any alerts or irregularities in the logs.

Supporting manual and electronic logs from the CA and RA shall be compared where any action is deemed suspicious.

Actions taken from these reviews shall be documented.

5.4.3 Retention Period for Audit Log

The CA shall retain its audit logs on-site for at least two (2) months and subsequently archive them in the manner described in section 5.5.

5.4.4 Protection of Audit Log

The electronic audit log system shall include mechanisms to protect the log files from unauthorized viewing, modification, and deletion. Manual audit information shall be protected from unauthorized viewing, modification, and deletion.

5.4.5 Audit Log Backup Procedures

Audit logs and audit summaries shall be backed up or copied if in manual form.

5.4.6 Audit Collection System

The CA shall identify and describe its audit collection system in its CPS.

5.4.7 Notification to Event-causing Subject

Where an event is logged by the audit collection system, no notice shall be given to the entity that caused the event.

5.4.8 Vulnerability Assessments

Events in the audit process are logged, in part, to monitor system vulnerabilities. The CA shall ensure that a vulnerability assessment is performed, reviewed, and revised following an examination of these monitored events.

If, during a vulnerability assessment, a serious vulnerability for the CA operation is found, the CA shall immediately inform the PMA of the vulnerability and the action needed to address the vulnerability. Where the CA fails to take appropriate action and depending on the severity of the vulnerability, the PMA may:

Allow the CA to continue operations until the next planned upgrade to the CA operation

Allow the CA to continue operations for a maximum of thirty (30) days pending corrective action being taken prior to revoking the CA’s accreditation

Revoke the CA’s certificate



5.5 Records Archival

In addition to the records archival requirements specified in the Certificate Policy, Ministries, agencies and the BPS shall implement procedures to address the requirements of Ontario’s Archives Act [5].

5.5.1 Types of Records Archived

Encryption/decryption keys generated by the CA shall be archived for at least one (1) year after the expiration of the key material.

Private decryption keys stored by the CA never expire and shall be kept indefinitely on media that will remain readable and accessible. Private decryption keys that are backed up by the CA are to be protected at a level of physical and cryptographic protection equal to or exceeding that in place at the CA site.

CRLs generated by the CA shall be retained for at least seven (7) years after their expiration.

Audit information as detailed in section 5.4.1, subscriber agreements and acknowledgements and any identification and authentication information shall be retained for at least seven (7) years.

A second copy of all retained or backed up material shall be stored in a location other than the CA site and shall be protected either by physical security alone, or a combination of physical and cryptographic protection. Any such secondary site shall provide adequate protection from environmental threats such as temperature, humidity and magnetism.

The CA shall verify the integrity of the back-ups once every six (6) months. Material stored off-site shall be periodically verified for integrity.

5.5.2 Retention Period for Archive

The RA shall archive subscriber-related requests and all related correspondence for at least one (1) year after the termination of the subscriber’s association with the CA.

5.5.3 Protection of Archive

The CA shall protect the archived information captured electronically or manually from unauthorized viewing, modification, deletion or destruction. Access to archive records shall be restricted on a need-to-know basis and shall be protected by a combination of physical and logical security controls. Additionally, all archive media shall be provided adequate protection from environmental threats such as temperature, humidity, and magnetism.

5.5.4 Archive Backup Procedures

Certificates, CRLs, and keys shall be backed-up and stored locally. A copy of these items shall be made and sent to a secure archive facility. The backup procedure shall be tested quarterly and the backed-up information shall enable a complete restore of the system in case of a disaster.

For manual (i.e. paper) records, a copy of the document shall be made as it is received and sent to a secure archive facility. Original copies shall be kept locally.

5.5.5 Requirements for Time-stamping of Records

All archive data logs generated by GO-PKI CA shall be automatically time-stamped according to the system time. The GO-PKI CA system time shall be synchronized to a standard time source..



5.5.6 Archive Collection System

The archive collection system for GO-PKI CA shall be internal to the application that supports the GO-PKI CA.

5.5.7 Procedures to Obtain and Verify Archive Information

Material stored off-site shall be periodically verified for data integrity.

5.6 Key Changeover

To minimize risk from compromise of a CA’s private signing key, that key may be changed periodically; from that time on, only the new key shall be used for certificate signing purposes. The old, but still valid, certificate shall be available to verify certificates signed using the associated private key. If the old private key is used to sign CRLs, then the old key shall be retained and protected.

The CA shall publish a new certificate after key changeover and make it available to Subscribers as stipulated in section 6.1.4.

5.7 Compromise and Disaster Recovery

5.7.1 Incident and Compromise Handling Procedures

The Operational Authority shall designate a group with experience in IT security and forensics to be responsible for investigating and responding to incidents and compromises that impact the operations of the CA.

5.7.2 Computing Resources, Software, and/or Data are Corrupted

In the case of an event whereby the CA system is physically damaged or corrupted and becomes inoperative, but the CA signing key is available, the CA system shall be rebuilt and restored to the most recent known good condition


The CA shall establish business continuity procedures that outline the steps to be taken in the event of the corruption or loss of computing resources, software, or data. Where a repository (file or directory) is not under the CA’s control, the CA shall ensure that any agreement with the entity controlling the repository provides those business continuity procedures be established and documented by the repository.


The RA shall establish business continuity procedures that outline the steps to be taken in the event of the corruption or loss of computing resources, software, or data.

5.7.3 Entity Private Key Compromise Procedures


In the event of a compromise, or suspected compromise of the GO-PKI CA’s secret encryption-decryption key, the CA shall notify the PMA immediately.



In the event of a compromise of the CA’s private signing key and prior to restarting its operations, the CA shall:

Revoke all certificates issued using that key

Provide notice (see section 4.9.12)

After addressing the factors that led to the key compromise, the CA may:

Generate a new CA signing key pair

Re-issue certificates to all entities and ensure all CRLs are signed using the new private key

The CA shall ensure that its CPS and appropriate agreements contain provisions outlining the means it will use to provide notice of compromise or suspected compromise.

5.7.3.1.1 CA Certificate Revocation

In the event of the need for revocation of the CA’s digital signature certificate, the CA shall immediately notify:

The PMA

All of its RAs

All subscribers

All CAs that have been cross certified

The CA shall also publish the certificate serial number on the appropriate CRL.

After addressing the factors that led to revocation, the CA may:

Generate a new CA signing key pair

Re-issue certificates to all entities and ensure that all CRLs are signed using the new key


In the event of the compromise, or suspected compromise of an RA personnel’s private key, the RA shall notify the CA immediately prior to performing revocation and re-issuance operations. The CA shall ensure that its CPS outlines how it will provide notice of compromise or suspected compromise.

5.7.4 Business Continuity Capabilities After a Disaster


The CA shall establish a disaster recovery plan that outlines the steps to be taken to re-establish a secure facility in the event of a natural or other type of disaster. Where a repository (e.g. file or directory) is not under its control, the CA shall ensure that any agreement with the entity controlling the repository provides that a disaster recovery plan be established and documented by the entity to the CA’s satisfaction.


The RA shall establish business continuity procedures that outline the steps to be taken in the event of the corruption or loss of computing resources, software, or data.



5.8 CA or RA Termination

5.8.1 CA Termination

In the event that the CA ceases operation, it shall notify its RAs, subscribers and other CAs that have been cross certified immediately upon the termination of operations and arrange for the continued retention of the CA’s keys and all information controlled by the CA.

In the event of a change in management of its operations, the CA shall notify all entities for which it has issued certificates.

In the event of a transfer of its operations to another CA, the certificates issued by the CA whose operations are being transferred shall be revoked through a CRL signed by that CA prior to the transfer.

The CA’s archives shall be retained in the manner and for the time indicated in section 5.5.

5.8.2 RA Termination

The CA shall set out in its CPS the process by which it handles RA termination.

An authenticated termination request and any resulting actions taken by the CA shall be recorded and retained.

In the event that the RA ceases operation, it shall notify the CA and its subscribers prior to termination. The RA shall transfer all electronic and paper files to the CA in a secure manner. Where the RA is external to the Government, the CA shall notify subscribers of its collection of this information in accordance with FIPPA.

The RA shall obtain approval by the CA if it plans to transfer its operations to another RA. The RA shall notify its subscribers and transfer all electronic and paper files to the other RA in a secure manner. Where the RA is subject to privacy or other relevant legislation, it shall comply with the collection and disclosure obligations under this legislation.

6 TECHNICAL SECURITY CONTROLS

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation


The CA application may generate subscriber confidentiality key pairs. The CA application may also generate subscriber digital signature key pairs, providing the CA application also generates the subscriber’s PKI profile, and protects the PKI profile with an access control mechanism such as a temporary password.

For a basic level of assurance, the PKI client application shall generate key pairs using RSA 512, RSA 1024, or RSA 2048 in accordance with PKCS#1; or using DSA in accordance with DSS (FIPS PUB 186) and ANSI X9.30 (Part 1).




The CA application may generate subscriber confidentiality key pairs. The CA application may also generate subscriber digital signature key pairs, providing the CA application also generates the subscriber’s PKI profile, and protects the PKI profile with an access control mechanism such as a temporary password.

For a medium level of assurance, the PKI client application shall generate key pairs using RSA 1024 or RSA 2048 in accordance with PKCS#1; or using DSA in accordance with DSS (FIPS PUB 186) and ANSI X9.30 (Part 1).


The CA application may generate subscriber confidentiality key pairs. A digital signature key pair may only be generated by a cryptographic module within the key owner’s environment.

For a high level of assurance, the PKI client application shall generate key pairs using RSA 1024 or RSA 2048 in accordance with PKCS#1; or using DSA in accordance with DSS (FIPS PUB 186) and ANSI X9.30 (Part 1).

6.1.2 Private Key Delivery to Subscriber

The CA application shall deliver the private keys it generates to the subscribers’ PKI profiles in an on-line transaction in accordance with RFC2510 [2], or via an equally secure manner as specified by local policy.

6.1.3 Public Key Delivery to Certificate Issuer

The PKI client application shall deliver the public keys that it generates to the CA application for certification in an on-line transaction in accordance with RFC2510, or via an equally secure manner as specified by local policy.

6.1.4 CA Public Key Delivery to Relying Parties

The CA application shall deliver the CA’s public verification key to the subscribers’ PKI profiles in an on-line transaction in accordance with RFC2510, or via an equally secure manner as specified by local policy.

6.1.5 Key Sizes


For a basic level of assurance, the CA application shall generate the CA’s digital signature key pairs using RSA 1024 in accordance with PKCS#1.

The CA application may generate all other key pairs using RSA 512, RSA 1024, or RSA 2048 in accordance with PKCS#1; or using DSA in accordance with DSS (FIPS PUB 186) and ANSI X9.30 (Part 1).


For a medium level of assurance, the CA application shall generate the CA’s digital signature key pairs using RSA 1024 or RSA 2048 in accordance with PKCS#1.



The CA application may generate all other key pairs using RSA 1024 or RSA 2048 in accordance with PKCS#1; or using DSA in accordance with DSS (FIPS PUB 186) and ANSI X9.30 (Part 1).


For a high level of assurance, the CA application shall generate the CA’s digital signature key pairs using RSA 2048 in accordance with PKCS#1.

The CA application may generate all other key pairs using RSA 1024 or RSA 2048 in accordance with PKCS#1, or using DSA in accordance with DSS (FIPS PUB 186) and ANSI X9.30 (Part 1).

6.1.6 Public Key Parameters Generation and Quality Checking

The CA application shall generate DSA parameters in accordance with FIPS PUB 186.

A PKI client application shall generate DSA parameters in accordance with FIPS 186.

6.1.7 Key Usage Purposes

The CA application shall populate the certificate key usage field in all of the certificates it issues in accordance with RFC 3280 [3]. The key usage purposes are as follows:

Subscriber public verification keys may be used for authentication, non-repudiation, and message integrity. They may also be used for session key establishment.

Subscriber public encryption keys may be used for exchange and establishment of keys used for session and data confidentiality

The CA’s public verification key shall only serve for signing certificates and CRLs

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic Module Standards and Controls


For a basic level of assurance, CA cryptographic operations shall be performed in a software or hardware cryptographic module rated to at least FIPS 140-1 Level 2, or otherwise verified to an equivalent level of functionality and assurance.

For a basic level of assurance, the CA application may generate key pairs in a software or hardware cryptographic module.

Cryptographic operations for PKI client applications used by all PKI entities, including subscribers, CA personnel, and RA personnel shall be performed in a software or hardware cryptographic module rated to at least FIPS 140-1 Level 1, or otherwise verified to an equivalent level of functionality and assurance.


For a medium level of assurance, CA cryptographic operations shall be performed in a hardware cryptographic module rated to at least FIPS 140-1 Level 2, or otherwise verified to an equivalent level of functionality and assurance.



For a medium level of assurance, the CA application shall generate the CA’s digital signature key pairs in a hardware cryptographic module. It may generate key pairs for all other PKI entities in a software or hardware cryptographic module.

Cryptographic operations for PKI client applications used by all PKI entities, including subscribers, CA personnel, and RA personnel shall be performed in a software or hardware cryptographic module rated to at least FIPS 140-1 Level 1, or otherwise verified to an equivalent level of functionality and assurance.


For a high level of assurance, CA cryptographic operations shall be performed in a hardware cryptographic module rated to at least FIPS 140-1 Level 3, or otherwise verified to an equivalent level of functionality and assurance.

For a high level of assurance, the CA application shall generate key pairs for all PKI entities in a hardware cryptographic module.

For a high level of assurance, cryptographic operations for PKI client applications used by all PKI entities, including subscribers, CA personnel, and RA personnel shall be performed in a hardware cryptographic module rated to at least FIPS 140-1 Level 2, or otherwise verified to an equivalent level of functionality and assurance.

6.2.2 Private Key Multi-person Control

Multiple person control is required for CA key generation operations. Two staff performing duties associated with the roles of PKI master user or PKI officer shall participate or be present.

Multiple person control is also required for key recovery when such operations are for data recovery purposes. Two staff performing duties associated with the roles of PKI master user, PKI officer, or PKI administrator shall participate or be present.

6.2.3 Private Key Escrow

There is no requirement for private key escrow; therefore, it shall not be supported.

6.2.4 Private Key Backup

The CA can back up private decryption keys only for key recovery purposes. The CA shall not back up private digital signature keys. Backed-up keys shall be stored in encrypted form and protected at a level of assurance no lower than stipulated for the original version of the key.

6.2.5 Private Key Archival

See section 5.5.

6.2.6 Private Key Transfer Into or From a Cryptographic Module

Private keys shall be entered into the CA’s cryptographic module in accordance with FIPS 140-1.

The PKI client application shall enter private keys into the cryptographic module in accordance with FIPS 140-1.



6.2.7 Private Key Storage on Cryptographic Module

The GO-PKI shall generate, transfer, store, and protect subscriber private keys in accordance with the requirements specified in the Certificate Policy, and as further defined below.

To address the requirement for a secure, mobile environment to store the credentials of users participating in electronic service delivery requests or transactions, this policy allows for the use of software tokens (e.g., computer file) and hardware tokens (e.g., PC cards, smart cards, USB tokens) to store the PKI profile for a subscriber. To satisfy privacy requirements, however, the following restrictions with respect to tokens shall be enforced:

(a) The private keys associated with the primary certificates may be stored on a hardware token that is kept by the subscriber.

(b) Other credentials such as role identifiers may be stored on a hardware token that contains primary private keys to support the access requirements of a program.

The CA shall control the ability of subscribers to export their GO-PKI profile to a format other than PKCS#7.

Before subscribers can export their GO-PKI profile to a format other than PKCS#7, they shall:

Have a certificate at a medium level of assurance (LOA) or higher.

Sign a request that has been approved by their manager. The request shall outline their responsibilities with regard to:

o the need to re-export their GO-PKI profile in the event of a key recovery or key update, and

o the protection of their GO-PKI profile, its password and the device on which the exported GO-PKI profile is stored.

6.2.8 Method of Activating Private Key

The PKI client application shall authenticate the subscriber before the activation of their private keys. This authentication may be in the form of a password. When deactivated, private keys shall be kept in encrypted form only.

6.2.9 Method of Deactivating Private Key

When deactivating private keys, the PKI client application shall clear the private keys from memory and before the memory is de-allocated. Any disk space where keys were stored shall be overwritten before the space is released to the operating system. The cryptographic module shall automatically deactivate the private key after a pre-set period of inactivity.

6.2.10 Method of Destroying Private Key

Upon termination of use of a private key, all copies of the private key in computer memory and shared disk space shall be securely destroyed using overwriting. Private key destruction procedures shall be described in the CPS.



6.2.11 Cryptographic Module Rating

Cryptographic module requirements are stipulated in Chapter 2 6.2.1.

6.3 Other Aspects of Key Pair Management

6.3.1 Public Key Archival

The CA shall retain all public verification keys. There is no requirement for public encryption keys.

6.3.2 Certificate Operational Periods and Key Pair Usage Periods

The CA application shall enforce the key usage periods specified in Table 2.

Table 2 - Key Usage Periods

Certificate Assurance

Level Key Size Entity Key Type Maximum

Validity Period

Public verification two (2) years

Private signing one (1) year

Public encryption two (2) years Basic 1024 End entities

Private decryption no expiry

Public verification twenty (20) yearsCA Private signing ten (10) years

Public verification two (2) years

Private signing one (1) year

Public encryption two (2) years

1024 (see note)

End entities


Public verification twenty (20) yearsCA

Private signing ten (10) years

Public verification three (3) years

Private signing two (2) years

Public encryption three (3) years

Medium

2048

End entities


Public verification twenty (20) yearsCA

Private signing ten (10) years

Public verification three (3) years

High 2048

Other entities

Private signing two (2) years



Certificate Assurance

Level Key Size Entity Key Type Maximum

Validity Period

Public encryption three (3) years


Note: Use of RSA 1024-bit keys for the medium assurance level shall be discontinued by January 1, 2010 and replaced with 2048. For further information on cryptographic standards see: Security Requirements for the Use of Cryptography GO-ITS 25.12

6.3.3 Use of Other Algorithms

6.3.3.1 Digital Signature

The CA application shall generate digital signatures using SHA-1 in accordance with FIPS PUB 180-2.

The PKI client application shall generate digital signatures using SHA-1RSA in accordance with FIPS PUB 180-2. .

6.3.3.2 Data Encryption

The CA application is capable of generating symmetric keys using any one of the following algorithms:

DES in accordance with FIPS PUB-46-2 et ANSI X3.92

CAST in accordance with RFC2144

Triple-DES in accordance with ANSI X9.52

RC2 in accordance with RFC2268

IDEA in accordance with ISO/IEC 9979

The PKI client application shall generate symmetric keys using AES 256 in accordance with FIPS-197. In approved business circumstances the PKI client application can generate symmetric keys using any one of the following:

Triple DES in accordance with ANSI X9.52

CAST in accordance with RFC2144

6.4 Activation Data

6.4.1 Activation Data Generation and Installation

Initialization codes that the CA application generates for certificate initializations including certificate recoveries shall be unique and unpredictable, and shall only be valid until used for its intended purpose.



The CA shall ensure that such initialization codes will expire within the required timeframe of its issuance, as follows:

• High LOA – Within 24 hours (high LOA certificates are activated immediately)

• Medium LOA – Within 21 calendar days

• Basic LOA – Within 30 calendar days

Any activation data that the subscriber uses to activate the PKI client application shall be unique and unpredictable. Where passwords are used, the PKI client application shall provide the capability for the subscribers to change a password at any time.

6.4.2 Activation Data Protection

The CA shall protect initialization codes from unauthorized access.

The PKI client application shall protect the subscriber’s private keys from unauthorized use using cryptographic mechanisms. The level of protection shall be adequate to deter a motivated attacker with substantial resources. If a reusable password scheme is used, the PKI client application shall include a facility to temporarily suspend the subscriber after a predetermined number of failed login attempts.

6.4.3 Other Aspects of Activation Data

No stipulation.

6.5 Computer Security Controls

6.5.1 Specific Computer Security Technical Requirements

The CA system shall include the following functionality, either provided by the operating system, or through a combination of operating system, PKI software application, and physical security safeguards:

Access control to CA services and PKI roles

Enforced separation of duties for PKI roles

Identification and authentication of PKI roles and associated identities

Object re-use or separation of CA random access memory

Use of cryptography for session communication and database security

Archive of key history (CA and other entities) and audit data

Audit of security related events

Self-test of security related CA services

Trusted path for identification of PKI roles and associated identities

Recovery mechanisms for keys and the CA system

For the issuance of high assurance certificates, enforcement of domain integrity for security-critical processes



6.5.2 Computer Security Rating

No stipulation.

6.6 Life Cycle Technical Controls

6.6.1 System Development Controls

The CA shall use CA software applications that have been designed and developed under a formal development methodology and that are supported by configuration management tools and third party verification of process compliance.

6.6.2 Security Management Controls

The CA shall ensure that it has a configuration management process and a problem management process in place for the installation and on-going maintenance of the CA systems.

The CA application shall provide a method for CA personnel to verify that the CA application originated from the software developer, that it has not been modified prior to installation, and that it is the version intended for use. The CA shall monitor the configuration of the CA systems and periodically verify the integrity of the CA software application (weekly for medium assurance and daily for high assurance). The CA shall document these integrity controls in its CPS.

6.6.3 Life Cycle Security Controls

No stipulation.

6.7 Network Security Controls

The CA system shall be protected from attack through any open or general-purpose network with which it is connected. Such protection shall be provided through the installation of a device configured to allow only the protocols and commands required for the operation of the CA. The CA shall ensure that its CPS defines what those protocols and commands are.

6.8 Time-stamping

The CA shall time-stamp all issued certificates and recorded transactions. The systems that support the CA, RA, and other infrastructure components shall be synchronized to standard time sources through the Network Time Protocol.

7 CERTIFICATE, CRL, AND OCSP PROFILES

7.1 Certificate Profile

7.1.1 Version Number

The CA shall issue X.509 [4] Version 3 certificates in accordance with RFC 3280 [3].

The PKI client application shall support X.509 Version 3 certificates.



7.1.2 Certificate Extensions

The CA shall support the base (non-extension) X.509 fields:

Signature : CA signature to authenticate certificate

Issuer : Name of CA

Validity : Activation and expiry date for certificate

Subject : Subscriber’s distinguished name

Subject Public Key Information : algorithm ID, key

Version : Version of X.509 certificate, version 3 (2)

Serial Number : Unique serial number for certificate

The CA shall specify in its CPS the certificate extensions it supports. The CA application shall populate certificate extensions as specified in RFC 3280 [3].

7.1.3 Algorithm Object Identifiers

The CA shall ensure that its certificates contain the appropriate algorithm OIDs as specified in the CPS.

7.1.4 Name Forms

Every distinguished name (DN) shall be in the form of an X.501 [5] printable string.

7.1.5 Name Constraints

The CA shall ensure that Subject and Issuer DNs comply with PKIX standards and are present in all name Constraints extention cross-certificates.

7.1.6 Certificate Policy Object Identifier

The CA shall ensure that its certificates contain the appropriate certificate policy OID as specified in section 1.2.

The certificate policies extension shall be used in all certificates..

7.1.7 Usage of Policy Constraints Extension

The CA shall populate the policy Constraints extension.

7.1.8 Policy Qualifiers Syntax and Semantics

The CA application shall populate the CPSuri pointer and the user notice qualifiers of the certificate policies extension in all of its certificates in accordance with RFC 3280 [3]. The CPS pointer shall contain the URL of the CA’s CPS location. The user notice shall contain the text specified in section 9.8.2.

7.1.9 Processing Semantics for the Critical Certificate Policies Extension

This CP does not require the certificate policy extension to be critical. Relying parties that do not process this extension do so at their own risk.



7.2 CRL Profile


The CA shall issue X.509 Version 2 CRLs in accordance with RFC 3280 [3].

If the PKI client application verifies the status of certificates against a CRL, then it shall support X.509 Version 2 CRLs.

7.2.2 CRL and CRL Entry Extensions

The CA application shall populate CRL extensions in accordance with RFC 3280 [3]. The CA shall specify in its CPS the extensions it supports.

7.3 OCSP Profile

No stipulation.


7.3.2 OCSP Extensions

8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS

The GO-PKI PMA will oversee compliance with this policy and its operational standards through periodic checks that Ministries, agencies and the BPS shall conduct when operating elements of the GO-PKI.

The purpose of a compliance audit is to provide the assurance that the GO-PKI CA’s actual performance meets the standards established in its CPS and satisfies the requirements of this certificate policy for the certificate types it supports. The minimum requirements below may be enhanced to meet local policies.

The purpose of a compliance audit is to provide the assurance that an RA’s actual performance satisfies the requirements of this certificate policy and of any additional requirements established by the CA or CAs for which the RA is providing subscriber management services.

8.1 Frequency or Circumstances of Assessment

8.1.1 CA Assessments

For a medium and high level assurance, the CA shall conduct a compliance audit every twelve (12) months.

For a basic level of assurance, the CA shall conduct a compliance audit every two (2) years.



8.1.2 RA Assessments

For a medium and high level assurance, the RA shall be subject to a compliance audit every twelve (12) months.

For a basic level of assurance, the RA shall be subject to a compliance audit every two (2) years.

8.2 Identity/Qualifications of Assessor

The audit function within each ministry or agency is responsible for compliance audits. The audit section shall conduct compliance audits in accordance with the Certificate Policy, and shall follow guidelines established by their relevant ministry or agency, subject to approval by the GO-PKI PMA.

Any person seeking to perform a compliance audit shall possess significant experience with PKI and cryptographic technologies as well as the operation of relevant PKI software.

8.3 Assessor's Relationship to Assessed Entity

The audit section shall comply with the provisions of the regulations to Ontario’s Public Service Act [6] and Management Board Directives, pertaining to conflict of interest and post-employment restrictions. In addition, no person may be appointed an auditor who is, whose partner is, or a member of whose firm is:

(a) A member of the family of any minister or of colleagues in the Government of Ontario legislature

(b) Employed in or a member of the immediate family of a person referred to above where such family members are employed in a senior position of authority in a non-government organization


The auditor shall be independent of the CA and accredited to perform audits.


The auditor shall be independent of the RA and approved by the CA to perform such audits.

8.4 Topics Covered by Assessment


As a minimum, the process shall assess whether:

The CPS outlines, in sufficient detail, the technical, procedural, and personnel policies and practices of the CA that meet this certificate policy’s requirements for the certificate types the CA issues

The CA implements and complies with those technical, procedural, and personnel policies and practices




As a minimum, the process shall assess whether the RA implements and complies with the technical, procedural, and personnel policies and practices of this certificate policy and of any related practices of the CA’s CPS.

8.5 Actions Taken as a Result of Deficiency


If, during a compliance audit, irregularities are found, the auditor shall submit a report to the PMA indicating any action that the CA will or has been instructed to take in response to the irregularities. Where the CA or auditor fails to take appropriate action and depending on the severity of the irregularities, the PMA may:

Allow the CA to continue operations until the next programmed compliance audit

Allow the CA to continue operations for a maximum of thirty (30) days pending correction of any problems prior to revoking the CA’s accreditation

Revoke the CA’s certificate


If, during a compliance audit, irregularities are found, the auditor shall submit a report to the PMA indicating any action that the RA will or has been instructed to take in response to the irregularities. Where the RA fails to take appropriate action and depending on the severity of the irregularities, the PMA may:

Allow the RA to continue operations until the next programmed compliance audit

Allow the RA to continue operations for a maximum of thirty (30) days pending correction of any problems prior to revoking the RA’s accreditation

Suspend or terminate the RA immediately

8.6 Communication of Results


The CA shall provide the PMA with a copy of the results of the compliance inspection. These results should not be made public unless required by law, or in response to local access to information policies.


The RA shall provide the PMA with a copy of the results of the compliance inspection. These results should not be made public unless permitted by law, or as authorized by the PMA.



9 OTHER BUSINESS AND LEGAL MATTERS

This section contains provisions relating to the obligations of the GO-PKI CA, its RA agent, LRAs, subscribers, relying parties, and other issues pertaining to law and dispute resolution.

9.1 Fees

The charging of fees for GO-PKI services is subject to appropriate legislative authority and policy.

This certificate policy does not proscribe the charging of fees for CA services. Notice of any fee charged to a subscriber or relying party shall be brought to the attention of that party.

Any fees chargeable by the GO-PKI CA to the subscriber or sponsoring program will be published . The subscriber or sponsoring program shall ensure that any fees relevant to the use of the GO-PKI services are paid when due.

9.1.1 Certificate Issuance or Renewal Fees

Please refer to your Program Profile

9.1.2 Certificate Access Fees

There is no fee associated with certificate access.

9.1.3 Revocation or Status Information Access Fees

There is no fee associated with the revocation service and status Information access.

9.1.4 Fees for Other Services

Please refer to the appropriate Program Profile for the detailed fee structure.

9.1.5 Refund Policy

There is no refund policy.

9.2 Financial Responsibility

The GO-PKI CA that contracts for the provision of its CA services shall require that any CA it uses provides satisfactory evidence of financial responsibility and waiver of any legislative immunity, if applicable.

9.2.1 Insurance Coverage

9.2.2 Other Assets

9.2.3 Insurance or Warranty Coverage for End-entities



9.3 Confidentiality of Business Information

The confidentiality and privacy of the audit results are regulated in accordance with the Ontario’s Freedom of Information and Protection of Privacy Act (FIPPA) [ Reference L] and the Municipality Freedom of Information and Protection of Privacy Act [Reference M].

9.3.1 Scope of Confidential Information

All personal or corporate information held by the GO-PKI CA (e.g., registration and revocation information, logged events, correspondence between the subscriber and the CA or RA, etc.) should be considered sensitive and should not be disclosed without the prior consent of the subscriber, unless required by law.

Audit information should be considered sensitive and should not be disclosed to anyone for any purpose other than audit purposes or where required by law.

All personal or corporate information held by an RA (e.g., subscriber requests, correspondence between the subscriber and the RA, etc.) should be considered sensitive.

Subscribers shall keep the CPS confidential except for the public excerpt that may be published on the GO-PKI web site.

Each subscriber’s private signing key is confidential to that subscriber. The GO-PKI CA and Government of Ontario are not provided any copies or access to this key.

Confidential, personal and corporate information passed between subscribers and the GO-PKI CA shall be kept confidential by the recipient of the information unless it:

Goes into the public domain otherwise than by a breach of this section .

Is developed independently by the recipient.

Is provided to the recipient by a third party who is legally entitled to do so otherwise than under an obligation of confidentiality.

Its release is required by law to the extent so required, such release being made (to the extent possible) under undertakings of confidentiality.

Audit information should be considered confidential and should not be disclosed to anyone for any purpose other than for legal reason.

9.3.2 Information Not Within the Scope of Confidential Information

Since they shall be posted and available to relying parties, certificates and CRLs are not considered sensitive from a confidentiality perspective. To avoid disputes, the CA should not put personal or otherwise sensitive information in the certificates and CRLs it issues.

Information included in certificates and CRLs is not considered confidential.

9.3.2.1 Disclosure of Certificate Revocation/Suspension Information

When a certificate is revoked by the GO-PKI CA, a revocation reason code is included in the CRL entry for the revoked certificate. This revocation reason code is not considered confidential and can be shared with all other subscribers and relying parties. However, no other details concerning the revocation is disclosed.



9.3.3 Responsibility to Protect Confidential Information

Subscribers shall keep their private keys confidential. Disclosure of a private key by the subscriber is at the subscriber’s own risk. The digital signature private key of each subscriber is to be held only by the subscriber. Confidentiality private keys may be backed-up by the CA or another party on behalf of the CA, in which case these keys shall be protected in accordance with section 6.3, and shall not be disclosed to any other party without the prior consent of the subscriber or, for the purpose of data recovery, the sponsor, unless required by law.

Audit information should be considered sensitive and should not be disclosed to anyone for any purpose other than audit purposes or where permitted by law. Any requests for the disclosure of information shall be signed and delivered to the RA.

9.4 Privacy of Personal Information

The collection, use, disclosure, retention, and access provisions of Ontario’s Freedom of Information and Protection of Privacy Act (FIPPA) [3] and Municipal Freedom of Information and Protection of Privacy Act (MFIPPA) [4] shall be taken into account when implementing GO-PKI CAs, registration authority units, and enrollment authority workstations. How these provisions are satisfied has a direct impact on the government’s ability to preserve privacy within the GO-PKI itself, and within and between the systems and applications that use GO-PKI services.

When implementing certification and registration authorities, Ministries, agencies and the BPS shall address the operational requirements for:

(a) The collection, use, disclosure, and retention of private keys

(b) The use and disclosure of, or FIPPA requests for access to, certificates

(c) The disclosure of information contained in directories, the public availability of directories, FIPPA requests for access to directories in their entirety, in electronic format

(d) FIPPA requests by subscribers for access to their own personal information

(e) Requests by individuals for information about subscribers and private keys

(f) Requests for access to information about the government’s PKI implementation or management

Since they are responsible for satisfying these requirements, CAs, RAs, and EAWs have a concomitant institutional responsibility for ensuring compliance with FIPPA, within their area of authority.

In addition to the confidentiality requirements of the Certificate Policy, Ministries, agencies and the BPS shall consider the following privacy principles when implementing CAs, RAs, and EAWs:

(a) Limit the information collected during the registration and enrollment processes

(b) Obtain the consent of the individual to collect the information

(c) Limit the use of a role identifier to its consistent use domain

(d) Notify the subscriber of the information’s intended use

(e) Limit the information published in certificates

(f) Implement controls in directories to limit as much as possible access to certificates



9.4.1 Privacy Plan

No stipulation

9.4.2 Information Treated as Private

No stipulation

9.4.3 Information Not Deemed Private

No stipulation

9.4.4 Responsibility to Protect Private Information

Personal information should not be disclosed without the prior consent of the subscriber, unless required by law.

9.4.5 Notice and Consent to Use Private Information

Information pertaining to the CA’s management of a subscriber’s certificates may only be disclosed to the subscriber, the subscriber’s sponsor, or where required by law. Any requests for the disclosure of information shall be signed and delivered to the CA.

Information held by the RA pertaining to a subscriber may only be disclosed to the subscriber, or where permitted by law.

9.4.6 Disclosure Pursuant to Judicial or Administrative Process

Parties other than the subscribers will only be provided with a subscriber’s private encryption key under the following conditions:

Release to Senior member of Program in accordance with the terms defined in the appropriate Program Profile; and

Release to a Canadian municipal, provincial or federal law enforcement entity based on a valid warrant.

In both cases the subscriber will be informed of the disclosure of its private encryption keys in accordance with the terms and regulations of the Freedom of Information and Protection of Privacy Act (FIPPA) [Reference L].

9.4.7 Other Information Disclosure Circumstances

No Stipulation

9.5 Intellectual Property Rights

Certificates, CRLs, DNs and this CP are the property of Government of Ontario, and may be used by LRAs and subscribers only in accordance with this CP and any other contract between the parties.

9.6 Representations and Warranties

Ministries, agencies and the BPS shall address the obligations set out in the Certificate Policy. In addition, Ministries, agencies and the BPS shall operate CAs, and RAs, in accordance with the laws of Ontario.



9.6.1 CA Representations and Warranties

The CA represents and warrants that:

The CA shall operate in accordance with its CPS, this certificate policy, any applicable local policies and laws, and the laws of Canada. CA personnel shall be individually accountable for actions they perform. Individually accountable means that there shall be evidence that attributes an action to the person performing that action.

When the GO-PKI CA issues a certificate under this certificate policy , it certifies only that it has issued a certificate to a subscriber and that the information stated in the certificate was verified in accordance with this certificate policy.

The CA shall ensure that each subscriber enters into an agreement that sets out the subscriber’s rights and obligations under this certificate policy; an acceptable use policy; a description of the allowed uses of keys and certificates; the subscriber’s obligations concerning key protection; and procedures for communication between the subscriber and the CA or RA, including communication of changes in service delivery or changes to this policy. The subscriber agreement shall also provide the procedures for dealing with suspected key compromise, key renewal, service cancellation, and dispute resolution.

The CA shall ensure that any notice of the subscriber’s rights and obligations includes a description of a relying party’s obligations with respect to the use, verification, and validation of certificates.

The CA shall ensure that its subscribers enter into an agreement or abide by an acceptable use policy that outlines the terms and conditions of use, including permitted applications and purposes.

The CA shall ensure that the private keys it holds and activation data are protected in accordance with this certificate policy, including subscriber private decryption keys that it has backed-up or archived. The CA shall ensure that any disclosure of private decryption keys is done so in accordance with the confidentiality provision set out in section 9.3 of this certificate policy.

The CA shall ensure that subscribers are aware of their obligations concerning the protection of their private keys.

The CA shall ensure that its private signing key is used only to sign certificates and CRLs.

The CA shall ensure that private keys issued to its personnel to access and operate CA applications are used only for such purposes. If required, its personnel would be issued subscriber keys and certificates to be used for purposes other than CA use.

The CA shall ensure that the availability of its repository is appropriate for the subscriber and relying party communities it supports.

The GO-PKI CA’s obligations are to: Publish a non-sensitive version of its CPS ;

Issue keys and certificates in accordance with the certificate policies it supports;

Ensure that its LRAs are aware of, and agree to abide with, the stipulations concerning their functions in the CPS and associated Program profiles;



Ensure that subscribers are aware of, and agree to abide with, the stipulations in the certificate policies under which they received keys and certificates and the GO-PKI subscriber agreement;

Provide notice of limitations of liability to subscribers;

Establish that any CA with whom it cross-certifies complies with all certificate policies that are mutually recognized;

Issue cross-certificates to other CAs in accordance with the GO-PKI cross-certification policy; and

Through compliance audit, verify that it complies with its certificate policies.

The GO-PKI CA is responsible for:

Providing subscriber initialization and repository services 24 hours a day, 7 days a week;

Identifying, authenticating and certifying GO-PKI subscribers (this service may be delegated to other approved LRAs);

Identifying, authenticating and certifying LRAs and GO-PKI CA personnel;

Issuing certificates to subscribers and RA/LRAs;

Notifying subscribers of certificate issuance;

Revoking certificates upon receipt of a valid request;

Issuing and publishing CRLs and ARLs;

9.6.1.1 Notification of Certificate Issuance and Revocation

The GO-PKI subscriber registration form contains a notice of certificate issuance. Subscribers shall read, understand and agree to the terms and conditions contained within and sign an acknowledgement of having done so prior to the initial issuance of their certificates. Immediately following issuance, confidentiality certificates are automatically published by the GO-PKI CA application in the X.500 directory, and the signature verification certificates are automatically sent to the subscribers by the GO-PKI CA application. The GO-PKI CA notifies the subscriber and the subscriber’s LRA when a certificate is revoked. The serial numbers of revoked certificates are added to a certificate revocation list (CRL), which is posted immediately to the X.500 directory. The GO-PKI CA makes CRLs available to subscribers and relying parties as specified in Chapter 2 paragraph 4.9.7 CRL Issuance Frequency..

9.6.1.2 Accuracy of Representation

In publishing a confidentiality certificate in the X.500 directory, the GO-PKI CA certifies that it has issued a certificate to a subscriber, or the individual responsible for a certificate issued to a device or application, and that the subscriber or responsible individual has accepted the certificate. It also certifies that the information stated in the certificate was verified in accordance with the CPS. Publication of the confidentiality certificate in the X.500 directory constitutes notice of such verification.



When a digital signature certificate is issued to a subscriber at the same time as the confidentiality certificate, as is the case during initialization, publication of the confidentiality certificate in the public repository constitutes notice of such verification. Subscriber notice of the subscriber’s rights and obligations are in accordance with Section 2 paragraph 1.3 PKI Participants. .

9.6.1.3 Time Between Certificate Request and Issuance

GO-PKI CA Staff issue and return the subscriber’s activation data to the LRA as soon as possible after reception of a valid request from an LRA. The time between the receipt of a subscriber certificate request and the time of issuance are defined in the specific Program Profiles. The LRA will notify the subscriber as soon as possible after reception of the subscriber’s activation data. The GO-PKI CA forces its subscribers to initialize within four weeks of the activation data generated. In the event that the subscriber has not initialized within the prescribed period, the activation data will expire – rendering the activation data unusable. The subscriber shall re-submit a certificate request via his/her LRA – as per the original certificate request process. The GO-PKI CA issues certificates immediately following subscriber initialization.

9.6.1.4 Certificate Revocation and Renewal

Revocation requests received by an LRA are immediately forwarded to the GO-PKI CA and processed in accordance with this CPS. If certificates are to be reissued, the subscriber is marked for key recovery by the GO-PKI CA after the certificates are revoked. Activation data is distributed in accordance with the processes defined in the appropriate Program Profile. The GO-PKI CA ensures that notice of revocation of a certificate is written to the CRL as stated in Chapter 2 paragraph 4.9.7 CRL Issuance Frequency.. All subscriber certificates contain the location of the associated CRL, where a relying party can verify if the certificate being used has been revoked. The LRA requesting the revocation is notified of the completed revocation in accordance with the process described in the appropriate Program Profile. The GO-PKI CA supports manual and automatic certificate renewals. Please refer to the processes defined in the appropriate Program Profile for the manual renewal processes. GO-PKI CA’s automatic certificate renewals are initiated by the subscriber PKI application when specific conditions are met – refer 4.7 of the CPS for the details of the automatic certificate renewal conditions. The subscriber’s PKI application establishes a secure connection with the GO-PKI Certification Authority and requests certificate renewals. New encryption and signature keys are generated and the public keys are certified (signed) by the CA. The subscriber signature certificate is used to authenticate the subscriber to the CA. A subscriber cannot renew its certificates if its signature certificate is expired. If the subscriber signature certificate is expired, the subscriber shall follow the manual certificate renewal processes, in accordance with the appropriate Program Profile.

9.6.1.5 Protection of Private Keys

The GO-PKI CA protects its private signing key in accordance with Chapter 2 Section 6.2 Private Key Protection and Cryptographic Module Engineering Controls of the CP. Subscriber activation data and confidentiality decryption keys, which are backed-up and archived by the GO-PKI CA, are protected as per Chapter 2 Section 6.2.4 Private Key Backup and the practices described in the CPSsection GO-PKI stores it’s signing private key into a FIPS140-1-level 3 rated hardware module – Chrysalis LunaCA3 token. All signatures using the GO-PKI CA signing key are performed inside the hardware token, hence



preventing the plain signing private key from being exposed to outside environments (OS, system bus, etc). Subscribers protect their private keys and activation data in accordance with stipulations in the CPS and any special requirements identified in the appropriate Program Profiles.

9.6.1.6 Restrictions on CA’s Private Key Use

The GO-PKI CA uses the GO-PKI CA private signing key solely for signing certificates, CRLs, ARLs, cross-certification certificates and Policy Certificates. Access to the GO-PKI CA signing key is controlled and enforced by the GO-PKI CA application and the Hardware Security Module (HSM): Entrust/Authority and the Chrysalis LunaCA3 token. The GO-PKI CA application makes use of the GO-PKI CA signing key via request to the Chrysalis LunaCA3 token using PKCS 11 compliant protocols. The GO-PKI CA issues privileged certificate types to the GO-PKI CA operators and LRAs that need access to the Entrust/Authority (GO-PKI CA) via the remote registration Authority application, Entrust/RA. The LRA certificates are generated and stored on a hardware devices (either Luna2 tokens or Rainbow USB token). The certificates issued for LRA and CA operations are solely used for this purpose/role.

9.6.2 RA Representations and Warranties

The RA represents and warrants that:

The RA shall comply with all the relevant provisions of this certificate policy.

The RA shall bring to the attention of subscribers all relevant information pertaining to the rights and obligations of the subscriber and relying party contained in this certificate policy, the subscriber agreement, or any other relevant document outlining the terms and conditions of use.

RA personnel shall be individually accountable for transactions performed on behalf of the CA. Records of all actions carried out in performance of RA duties shall identify the individual who performed the action.

When an RA submits subscriber information to the CA, it shall confirm to the CA that it has authenticated the identity of that subscriber in accordance with the requirements in this section .

Each person performing RA duties on-line through an administrative interface to the CA application shall ensure that the PKI profile containing their private keys are protected in accordance with this certificate policy.

Private keys used by RA personnel to perform their obligations shall not be used for any other purpose.

The LRAs main responsibility is to register GO-PKI subscribers, in accordance with the CP and the appropriate Program Profile directives. The LRAs responsibility is to verify the accuracy and authenticity of the information provided by the individual to support the application for a certificate (see Chapter 2 Section 4.2 Certificate Application Processing) and forward the certificate requests to the GO-PKI CA staff using secure methods. By adhering to detailed practices described in the CPS, LRAs meet the obligations imposed upon them by the certificate policies supported by the GO-PKI CA. LRAs are responsible for:



Providing LRA services during standard business hours;

Assisting, promoting and educating subscribers on the use of PKI technology;

Identifying and authenticating certificate applicants and submitting valid subscriber registration to the GO-PKI CA staff;

Identifying and authenticating GO-PKI subscribers during the life cycle management functions of certificates and forwarding the following types of requests to the GO-PKI CA staff:

o key recovery requests;

o key compromise notifications;

o name and organization name changes request;

o subscription termination requests; and

o suspension requests.

Distributing subscriber activation data and GO-PKI client application software; and

Recording and signing all actions carried out in the performance of LRA duties. LRAs are accountable for actions performed on behalf of the GO-PKI CA. All certificate requests and certificate life cycle management requests are either digitally signed or manually signed by an authorized LRA.

9.6.2.1 Notification of Certificate Issuance and Revocation

GO-PKI LRAs receive subscriber revocation requests and forward them to the GO-PKI CA staff for processing. Upon revocation of the certificate(s), the GO-PKI CA staff will notify the requesting LRA of the completed revocation. Please refer to the appropriate Program Profile for the description of the specific revocation process.

9.6.2.2 Accuracy of Representations

By submitting a subscriber application to the GO-PKI CA staff, LRAs certify to all who reasonably rely on the information contained in the subsequently-issued certificates, that it has authenticated the named subscriber in accordance with the practices described in the CPS and appropriate Program Profile.

9.6.2.3 Protection of Local Registration Authority Private Key

There are two types of LRAs:

LRAs with direct access to the CA application (Entrust/Authority) via Entrust/RA or equivalent interface. For these types of LRAs, their private keys are generated and stored in a hardware device – Chrysalis Luna2 token or the Rainbow USB token; and

LRAs with no access to the CA application have their private key generated and stored in a digitally encrypted file with restricted access.

The LRAs private keys are protected in accordance with the practices described in the CPS and the RA/LRA Operating Procedures. and the appropriate Program Profile.

9.6.2.4 Restrictions on Local Registration Authority Private Key Use

LRAs who have direct access to the Entrust/Authority are issued subscriber keys and certificates to perform specific tasks associated with their GO-PKI CA functions, and are not authorized to use their



LRA keys for any other function than the authorized LRA functions – no personal use of the key is authorized.

9.6.3 Subscriber Representations and Warranties

Ministries, agencies and the BPS shall ensure that subscribers within the GO-PKI (e.g., employees) acknowledge an acceptable use policy that outlines the terms and conditions of use, including permitted applications and purposes.

Ministries, agencies and the BPS shall ensure that subscribers outside of the GO-PKI (e.g., citizens) acknowledge a subscriber agreement that outlines the terms and conditions of use, including permitted applications and purposes.

The subscriber shall enter into a subscriber agreement with the CA, which sets out the terms and conditions of use, including permitted applications and purposes.

Subscribers represent and warrant that:

Subscribers should not leave their workstations unattended when the cryptography is in an unlocked state (i.e., when the PIN or password has been entered). A workstation that contains private keys on a hard drive should be physically secured or protected with an appropriate access control product.

The subscriber shall request PKI operations following the process specified by the RA.

The subscriber shall use their PKI profile in accordance with the instructions provided to them by their RA and their sponsor.

The subscriber shall advise the RA or the sponsor of any changes that affect their subscriber status.

The subscriber may back up their PKI profiles following instructions provided to them by their RA or their sponsor.

Any information submitted by the subscriber to an RA in connection with a certificate shall be complete and accurate. The subscriber shall be responsible for the completeness and accuracy of such information.

The subscriber shall protect their PKI profile in accordance with their subscriber agreements and any instructions provided to them by their RA or their sponsor.

The subscriber shall use their PKI profile only for the purposes specified by their RA and their sponsor.

The subscriber shall immediately notify their RA of any suspected or known compromise of their PKI profile following the instructions provided to them by their RA or their sponsor.

Subscribers shall accept the terms and conditions of use as specified in the GO-PKI subscriber agreement before their keys and certificates are issued. The Subscriber Agreement is distributed to subscribers by different means, please refer to the appropriate Program Profile for the details for a specific program. In summary, the subscriber’s obligations are:



Generating their private key (initialize) within the time frame specified in Chapter 2 Section 4.2.3 Time to Process Certificate Applications;

Using their private keys for approved applications and appropriate purposes;

Controlling access to their computer, or to the computer containing a private key for which they are responsible.

Protecting any password used to access their private keys;

Informing the GO-PKI CA, through their LRA, within forty-eight (48) hours of a change to any information contained in their certificates or subscriber registration; and

Notifying immediately the GO-PKI CA, through their LRA, of detection or suspicion of private key compromise.

PKI client applications shall, as a minimum, meet the following requirements:

Correctly establish, transfer, and use public and private keys and certificates

Perform certificate validation and verification checking

Correctly interact with subscribers and relying parties, including sending information messages and warnings

9.6.3.1 Representations

By accepting a certificate issued by the GO-PKI CA, the subscriber warrants to the GO-PKI CA and to all who reasonably rely on the information contained in the certificate, that at the time of acceptance and throughout the operational period of the certificate, and until notified otherwise by the subscriber that:

Each digital signature is created using the private key corresponding to the public key listed in the certificate is the digital signature of the subscriber and the certificate has been accepted and is operational (not expired, or revoked) at the time the digital signature is created;

No Unauthorized personnel have ever had access to the subscriber’s private keys or password;

All information contained in the certificate is true to the extent that the subscriber had knowledge or notice of such information and the subscriber has promptly notified the CA of any material inaccuracies in, or changes or additions to, such information; and

The certificate is being used exclusively for authorized and legal purposes, consistent with this CP and the appropriate program profile.

9.6.3.2 Protection of Subscriber Private Key and Key Token

Subscribers are required to protect their private keys and key tokens in accordance with the CPS and the CP Chapter 2 Section 1.3 PKI Participants, and to take all reasonable measures to prevent their loss, disclosure, modification, or unauthorized use.

9.6.3.3 Restrictions on End-Entity Private Key Use

Subscribers are authorized by the GO-PKI CA to use their private keys with the applications listed on the GO-PKI Authorized and Supported Application lists at Appendix F of the CPS



9.6.3.4 Notification Upon Private Key Compromise

Subscribers shall immediately notify the GO-PKI CA, through their LRA, when they detect or suspect a private key compromise.

9.6.4 Relying Party Representations and Warranties

Relying Parties represent and warrant that:

When using a certificate issued under this certificate policy, a relying party shall ensure that it is used for its intended purpose. Relying parties shall do a manual or automated check of certificates used for identity authentication to confirm that they were issued at the level of assurance required by the program or greater.

To use a certificate issued under this certificate policy, a relying party shall use a PKI client application that performs the certification path validation procedure specified in X.509 and RFC 3280 [3].

To use a certificate issued under this certificate policy, the relying party shall use a PKI client application that checks the status of the certificate against the issuing CA’s current CRL. As part of this process, the relying party’s PKI client application shall validate the issuing CA’s digital signature.

If the CA provides on-line certificate status checking, then the relying party may use a PKI client application that obtains certificate status information from that service.

9.6.4.1 Use of Certificates for Appropriate Purpose

Relying parties are authorized to use public keys contained in GO-PKI CA certificates solely for the approved applications and purposes permitted by the certificate policies under which the certificates were issued.

9.6.4.2 Verification Responsibilities

Relying parties shall use certificates issued by the GO-PKI CA with approved applications and only when the certificates are valid . Approved applications shall verify certificates in accordance with the certification path validation procedure specified in X.509 and PKIX Part 1 (RFC 2459).

9.6.4.3 Revocation Check Responsibility

Relying parties shall use certificates issued by the GO-PKI CA with approved applications and only when the certificates are not revoked (see . Prior to using a certificate, approved applications shall check the status of the certificate against the appropriate and current CRL.



As part of this verification process, approved applications shall validate the digital signature of the CRL.

9.6.5 Representations and Warranties of Other Participants

9.6.5.1 Repository Obligations

The GO-PKI CA is responsible for providing the repositories identified in Chapter 2 Section 2 Plublication and Repository Responsibilities. GO PKI has elected to out-source the provisioning of the repository to the Government of Ontario – Electronic Directory Messaging Services (EDMS). GO-PKI CA out-sourcing the repository services does not relief GO-PKI CA of its obligations with respect to the repository.

EDMS responsibilities are documented in the Operational Level Agreement between GO-PKI and EDMS [Reference Q of CPS].

The repository service is available twenty-four (24) hours a day, 7 days a week. Certificates and CRLs are available to subscribers as specified in Chapter 2 Section 4.9.7. section

9.7 Disclaimers of Warranties

Ministries.agencies and the BPS shall include the following disclaimers in all of their agreements with external subscribers:

“The Crown in Right of Ontario disclaims any liability of any kind whatsoever in relation to the use of certificates or associated public/private key pairs issued under this policy for any use other than in accordance with this policy and any agreements. Subscribers shall indemnify the Crown and save the Crown harmless from any such liability.

The Crown in Right of Ontario, its employees, and servants make no representations, warranties, or conditions, express or implied, including the veracity of statements other than as expressly stated in this policy or in any other agreement related to the GO-PKI.

No joint venture, partnership, trust, agency, or fiduciary relationship is established or deemed to be established between the Crown in Right of Ontario and any entity using the GO-PKI.”

Optionally (or alternatively), these disclaimers may be communicated during an on-line session with the subscriber.

The GO-PKI CA assumes no liability whatsoever in relation to the use of certificates or associated public/private key pairs issued under any of the certificate policies supported by the GO-PKI CA for any use other than in accordance with the certificate policies under which the certificates were issued and any other agreements, and subscribers and relying parties will indemnify the Government of Ontario and save the GO-PKI CA harmless from any such liability.

The GO-PKI CA, its employees, servants or agents makes no representations, warranties or conditions, express or implied other than as expressly stated in this CPS or in the GO-PKI certificate policies it supports.

No joint venture, partnership, trust, agency or fiduciary relationship is established or deemed to be established between the Government of Ontario and any entity using the GO-PKI CA.



9.8 Limitations of Liability

Ministries, agencies and the BPS shall include the following limits of liability in all of their agreements with external subscribers:

The Organization and the Government have an existing agreement that governs the work or services and the work or services require the Organization to use GO-PKI certificates. The provisions in that existing agreement relating to the Organization's indemnification and liability supersede those set out in this agreement. Or, if there is no agreement between the Organization and the Government: The Government of Ontario disclaims any liability of any kind whatsoever for any loss or injury, award, damages, or other claim or obligation of any kind arising from tort, contract, or any other reason: (i) in relation to the failure of the Organization or the Subscriber to comply with the obligations set

out in this Agreement or the misuse of certificates or associated public/private key pairs issued pursuant to this Agreement, which includes use for any purpose other than as set out in section 2 of this Agreement. The Organization shall indemnify the Government of Ontario against any losses, damages, costs or liability the Government of Ontario incurs as a result of the Subscriber's or the Organization's failure to comply with the obligations set out in this Agreement or for any misuse, whether willful or negligent, of certificates or the associated public/private key pairs issued pursuant to this Agreement to a limit of $2 million.

(ii) in relation to the issuance, authorized use of, or reliance upon a GO-PKI certificate or its associated public/private key pair in excess of $50,000 per certificate to a limit of $2 million.

9.8.1 Requirements

The CA shall ensure that its services are in accordance with this certificate policy. It shall also take reasonable efforts to ensure that all RAs and subscribers follow the requirements of this certificate policy.

The GO-PKI CA has implemented practices to ensure that its certification authority and repository services, authentication and validation of organizations and individuals, issuance and revocation of certificates, and issuance of CRLs are in accordance with the associated certificate policy requirements when dealing with GO-PKI CA certificates and associated keys. Through its LRA appointment process, the GO-PKI CA ensures that LRAs follow the authentication and validation procedures specified in Chapter 2 Section 4 Certificate Life Cycle Operational Requirements..

9.8.2 Disclaimers

The CA may include disclaimers in the agreements with its subscribers, RAs and relying parties The CA shall communicate any disclaimer to the subscribers. In addition, notice shall be provided through the use of the user notice field within the certificate as defined in RFC 3280 [3]. Due to space limitations within the certificate, such notice shall be limited to the following language: “Disclaimer hyperlink to CP - Responsabilité limitée. Voir CP”.

9.8.3 Limitations of Liability

The CA may include limits of liability in the agreements with its subscribers. The CA shall communicate any limit of liability to the subscribers.



The GO-PKI CA disclaims any liability of any kind whatsoever for any award, damages, or other claim or obligation of any kind arising from tort, contract, or any other reason with respect to any service associated with the issuance, use of, or reliance upon, a certificate issued by the GO-PKI CA or its associated public/private key pair, in excess of the limits described at Appendix C of the CPS. The GO-PKI CA is not liable for any damages, including indirect, special, incidental, or consequential damages, or for any loss of profits, loss of data, or other indirect, consequential, or punitive damages arising from or in connection with its services:

Incurred between the time a certificate is revoked and the next scheduled issuance of a CRL.

Due to unauthorized use of keys and certificates.

Due to use beyond the approved applications and appropriate purposes defined by the certificate policies under which certificates were issued.

Caused by fraudulent or negligent use of certificates and CRLs.

As a result of problems, errors, and bugs in subscriber software, including PKI-ready Commercial of the Shelf (COTS) and in-house applications.

LRAs are not liable for any damages, including indirect, special, incidental, or consequential damages, or for any loss of profits, loss of data, or other indirect, consequential, or punitive damages arising from or in connection with its services caused as a result of misrepresentations during the identification and authentication process.

9.8.4 Other Terms and Conditions

The disclaimers and limitations of liability in section Error! Reference source not found. and section Error! Reference source not found. are subject to any signed contract or cross-certification agreement that may be entered into by the Government of Ontario. Any such disclaimers or limitations of liability shall be consistent with the GO-PKI certificate policies. LRAs operating under the GO-PKI CA warrant and promise to perform identification and authentication consistent with Chapter 2 Section 4 of the CP and in accordance with the practices described in the CPS.section and the appropriate Program Profile. LRAs assume no liability for use of certificates issued by other CAs, or for use of GO-PKI CA certificates outside of its GO-PKI CA domain.

9.9 Indemnities

9.9.1 Indemnification by Relying Parties

By accepting a certificate, the relying party agrees to indemnify the GO-PKI CA for any loss caused by the use, issuance or publication of a certificate that arises from:

Misrepresentation of fact by the subscriber;

Intentional or negligent failure by the subscriber to disclose a material fact; and

Failure on the part of the subscriber to protect his/her private key or password, to use a trustworthy system or otherwise take precautions necessary to prevent the compromise or unauthorized use of the Subscriber’s private key or password.



9.9.2 Fiduciary Relationships

The GO-PKI CA is not the agent, fiduciary, trustee or other representative of any subscriber and shall not be represented by the subscriber to be so. Subscribers have no authority to bind the GO-PKI CA, by contract or otherwise, to any such obligation.

9.9.3 Administrative Processes

Assisting in the issuance of certificates consistent with the GO-PKI CP, and in accordance with the practices described in the CPS, does not make an LRA an agent, fiduciary, trustee, or other representative of subscribers or relying parties.

9.10 Term and Termination

9.10.1 Term

No stipulation

9.10.2 Termination

No stipulation

9.10.3 Effect of Termination and Survival

No stipulation

9.11 Individual Notices and Communications with Participants

No stipulation

9.12 Amendments

The GO-PKI PMA may amend this manual from time to time as specified below.

9.12.1 Procedure for Amendment

Changes to items within this certificate policy that in the judgment of the PMA will have no or minimal impact on subscribers and relying parties may be made with no change to the version number and no notification to the users.

Changes to this certificate policy that in the judgment of the PMA may have significant impact on subscribers and/or relying parties shall undergo a review and comment period of 30 days. The PMA will review all comments and respond individually or with further changes as appropriate. If the PMA decides not to make any further changes after the review period, the initially-proposed modified document will be published in the Repository



9.12.2 Notification Mechanism and Period

All items in this manual are subject to notification requirement.

The GO-PKI PMA will notify, in writing, the Operational Authority and all Program Managers of any proposed changes. The notification will contain a statement of proposed changes, the final date for receipt of comments, and the proposed effective date of change. The Operational Authority and the Program Managers are required to post a notice of change proposals on their web site.

The GO-PKI PMA may request the Operational Authority and the Program Managers to directly notify their subscribers of the proposed changes.

The comment period will be thirty (30) days unless otherwise specified. The comment period will be defined in the change notification.

Comments on proposed changes shall be directed to the GO-PKI PMA. Decisions with respect to the proposed changes are at the sole discretion of this authority.

The GO-PKI PMA will determine the period of final change notice.

9.12.3 Circumstances Under Which OID Must be Changed

Change of the OID of this CP shall be decided upon on a case by case basis by the PMA.

9.13 Dispute Resolution Provisions

Disputes related to GO-PKI services between the Government of Ontario and an organization or individual outside of the Government of Ontario shall be resolved following a dispute settlement procedure. A dispute should be resolved by negotiation. A dispute not settled by negotiation should be resolved using an independent mediator acceptable to both parties to the dispute. A dispute not settled by mediation should be resolved through arbitration in accordance with the Arbitration Act.

A dispute related to GO-PKI services between ministries or agencies should be resolved by negotiation. A dispute not settled by negotiation should be resolved by the GO-PKI PMA or, where appropriate, through a mediator or arbitrator appointed by the GO-PKI PMA.

A dispute related to GO-PKI services within a ministry or agency is to be resolved by the appropriate ministry or agency authority.

Ministries, agencies and the BPS shall ensure that any agreements they enter into provides dispute resolution procedures approved by the GO-PKI PMA.

The CA shall ensure that any agreement it enters into contains dispute resolution procedures.

Disputes between subscribers, or subscribers and the GO-PKI CA or an LRA, will be reported to the Corporate Security Branch , PKI Operations Manager for resolution. Disputes between the GO-PKI CA and any external entity are resolved following the process described at Appendix E of the CPS.

9.13.1 Name Claim Dispute Resolution Procedure

The CA shall reserve the right to make all decisions regarding names in all of its certificates. Where there is a dispute about a name in a directory not under the CA’s control, the CA shall ensure that there is a name claim dispute resolution procedure in its agreement with the entity that has control of that directory.



The naming convention, specified in Chapter 2 Section 3.1 Naming and detailed further in the CPS , is strictly enforced. GO-PKI CA reserves the right to make all decisions regarding subscribers’ names in all assigned certificates. A subscriber requesting a certificate shall demonstrate its right to use a particular name in accordance with Chapter 2 Section 3.1 Naming. section. Any dispute is resolved by the GO-PKI CA in accordance with this naming convention. Where there is a dispute about a name in a repository not under its control (i.e. cross-certification), the GO-PKI CA will ensure that there is a dispute resolution process in its agreement with the cross-certified repository (See Appendix E of the CPS).

9.14 Governing Law

Ministries, agencies and the BPS shall ensure that any agreements that they enter into with respect to the GO-PKI will be governed by the laws of Ontario (including FIPPA) and applicable federal law concerning the enforceability, construction, interpretation, and validity of this policy.

The GO-PKI PMA shall approve all such agreements.

The CA shall specify in all of its agreements the applicable governing laws and court of competent jurisdiction.

The CP is governed by and shall be construed in accordance with the laws of the Province of Ontario and the applicable laws of Canada. In the event that any of the terms, conditions or provisions of the CP shall be determined invalid, unlawful or unenforceable to any extent, such terms, conditions or provisions shall be severed from the remaining terms, conditions and provisions which shall continue to be valid to the fullest extent permitted by law.

9.15 Compliance with Applicable Law

No stipulation

9.16 Miscellaneous Provisions

No stipulation

9.16.1 Entire Agreement

No stipulation

9.16.2 Assignment

No stipulation

9.16.3 Severability

The CA shall ensure that any agreement it enters into contains provisions governing severability, survival, merger, and notice.



All cross-certification agreements between the GO-PKI CA and other entities will contain appropriate provisions governing severability, survival, merger or notice.

9.16.4 Enforcement (Attorneys' Fees and Waiver of Rights)

9.16.5 Force Majeure

9.17 Other Provisions

[1] National Institute of Standards and Technology. Federal Information Processing Standards Publication 140-1: Security Requirements for Cryptographic Modules. January 1994.

10 References

[1] Government of Ontario. Management Board Committee. Information and Information Technology Security Directive.

[2] International Telecommunication Union. Information Technology, Data Networks and Open System Communication: Directory, Recommendation X.509. June 1997.

[3] Internet Engineering Task Force. Public Key Infrastructure Standards Working Group (PKIX). Internet X.509 Public Key Infrastructure: Certificate and CRL Profile, RFC 3280 [3]. January 1999.

[4] Internet Engineering Task Force. Public Key Infrastructure Standards Working Group (PKIX). Internet X.509 Public Key Infrastructure: Online Certificate Status Protocol, RFC2560. June 1999.

[5] Internet Engineering Task Force. Public Key Infrastructure Standards Working Group (PKIX). Internet X.509 Public Key Infrastructure: Certificate Management Protocol, RFC2510 March 1999.

[6] Internet Engineering Task Force. Public Key Infrastructure Standards Working Group (PKIX). Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, RFC2527. March 1999.

[7] Government of Ontario. Management Board Secretariat. Archives Act.

[8] International Telecommunication Union. Information Technology, Open Systems Interconnection, The Directory: Models, Recommendation X.501. August 1997.

[9] Government of Ontario. Public Service Act.

[10] Government of Ontario. Freedom of Information and Protection of Privacy Act (FIPPA).

[11] Government of Ontario. Municipal Freedom of Information and Protection of Privacy Act (MFIPPA).



Appendix A – Glossary

Accreditation — A procedure by which an authoritative body gives formal recognition that a body or person is competent to carry out specific tasks. In the case of PKI, the accrediting body performs its evaluation of CA(s) or other PKI components by applying the standards derived from the Certificate Policies approved by an inter-jurisdictional governing body.

Accredited Certification Authority10 — A certification authority that has been accredited by a recognized body as complying with policies, standards and practices approved by an inter-jurisdictional governing body. An accredited CA may operate for the Government, business partner group, or broader public sector organization.

Activation Data — Private data, other than keys, that are required to operate cryptographic modules and that need to be protected (e.g. a PIN, passphrase, or manually held key share) [IETF PKIX4].

Approved PKI client applications — Software and hardware applications that use GO-PKI keys and certificates as approved by the PMA for use by Ministries, agencies and the BPS.

Assurance — The degree of confidence that a system or product implements a security policy. In PKI, the degree of confidence that can be placed by a relying party on the association between a subscriber and the subscriber’s public key.

Attribute — Data pertaining to an individual’s participation in a specific Government program.

Authentication — Any process designed to verify the identity of an individual or any other entity, or to establish the validity of a transmission, message, or originator.

Authority Revocation List (ARL) — A list of revoked cross-certificates (similar to CRL) used to revoke trust relationships with other CAs.

Authorization Code (AuthCode) — A code (e.g. CMTJ-8VOR-VFNS) obtained from the Administrator that is required along with a reference number to create a new Entrust profile or to recover an existing profile. The authorization code can only be used once then it is no longer valid.

Basic Reliability Check (BRC) — Minimum security screening requirement composed of verification of personal data, education and professional qualification, employment data, and references and a declaration concerning any conviction for a criminal offence.

Border Directory (Border DSA) — A Border DSA refers to a directory accessible from the Internet. The Border DSA would contain a sub-set of the information contained in the GO-PKI directory.

Broader Public Sector (BPS)— Organizations outside of the Government that exist through the provincial legislation to serve individuals and organizations in Ontario on the Government’s behalf. The BPS organizations can be funded directly by the Province or may be authorized through legislation to collect fees and/or taxes for their services. Examples of BPS organizations include municipalities, hospitals, schools, universities, children’s aid societies, and conservation authorities.

CA Agent — see Entrust Administrator.

10 Although a standards-based approach to accreditation is not in place, there is general recognition of its benefits (i.e.,

improved interoperability, streamlining of cross-certification process).



CA Application — A software application that issues and manages keys certificates, CRLs, and ARLs.

CA Certificate — The public verification key of a CA signed with that CA’s own private signing key, and used by PKI client applications to validate subscriber certificates, CRLs, and ARLs.

CA Certification — CA certification is the process by which hierarchical trust relationships are established and managed. CA certification applies only when establishing intra-domain relationships. The process includes steps for submitting CA certification requests, demonstrating compliance to a standard for management and use of keys and certificates, approving requests, modifying hardware and software, and generating and publishing CA certificates.

Certificate — The public key of an entity, together with some other information, rendered unforgeable by digitally signing it with the private key of the CA that issued it. The certificate format is in accordance with X.509 and RFC 3280 [3].

Certificate Management — A set of actions performed by PKI applications and CA, RA, and LRA personnel to manage public key certificates. Certificate management is comprised of generation, issuance, publication, suspension, revocation, expiration, and termination.

Certificate Policy (CP) — A set of rules that indicate the applicability of keys and certificates to a particular community or class of applications with common security requirements.

Certificate Revocation List (CRL) — A list of revoked certificates that is created and signed by the same CA that issued the certificates. A certificate is added to the list if it is revoked (e.g., because of suspected key compromise) and then removed from it when it reaches the end of the certificate’s validity period. In some circumstances, the CA may choose to split a CRL into a series of smaller CRLs.

Certification — The process of attesting that a specified quality or standard has been achieved or exceeded by a service after thorough inspection of the service has been completed.

Certification Authority (CA) — An authority trusted to issue and manage keys, certificates, CRLs and ARLs.

Certification Path — An ordered sequence of certificates, which, together with the public key of the initial object in the path, can be processed to obtain that of the final object in the path.

Certification Practice Statement (CPS) — A statement of the practices that a certification authority employs in issuing keys and certificates. The CPS describes the equipment, policies, and procedures implemented by the CA to satisfy the specifications in the certificate policies it supports.

1.

Compliance Audit — A compliance audit is a review of your activities as they relate to the organizational procedures.

Confidentiality — A PKI security service, which consists of encrypting data before it is stored or transmitted. The encrypted data is not comprehensible to any unauthorized individual.

Confidentiality Key Pair — A pair of asymmetric cryptographic keys composed of a public encryption key and a corresponding private decryption key.

Consistent Use Domain — A domain of related government programs and services (e.g. Health). The use of any personal data collected directly or indirectly must be reasonably consistent with the purpose for which it was collected and not disclosed outside of the domain.



Cross-certificate — A certificate that establishes a network trust relationship between two certification authorities (peer-to-peer). For each trust relationship, CAs may each issue a cross-certificate to the other CA (i.e., a pair of cross-certificates).

Cross-certification — A process by which a trust relationship between two CAs is established and managed for purposes of interoperability. Typically, cross-certification consists of an agreement signed by the CAs to establish a trust relationship by the issuance of cross-certificates, one for each of the CAs public verification keys. The cross-certificate is used by relying parties associated with the CA that generated it to validate certificates of subscribers associated with the other CA.

Decryption — To restore a protected (or encrypted) file to its original, unprotected state.

Device — A workstation, server, or other hardware where the program resides.

Device Certificate — A certificate that resides on a device to enable that device to be authenticated and/or to encrypt and/or sign data as required.

Device Owner — Owner of the workstation or server where the program resides.

Digital Signature — It is an electronic rather than a written signature than can be used to authenticate the identity of the sender of a message, or the signer of a document (non-repudiation). It is also used to ensure that the original content of the message or document is unchanged.

Digital Signature Key Pair — A pair of asymmetric keys composed of a private signing key and a corresponding public verification key.

Directory — A location where CRLs, ARLs, and certificates are stored for access by end-entities (may also be referred to as a Repository).

Directory Service Agent (DSA) — The DSA provides the directory client with controlled access to information stored in the directory database via the standard access protocols of LDAP, DAP (see Acronym Template). It is used in corporate Intranets.

Distinguished Name (DN) — A name appearing in a certificate that uniquely identifies the public key owner. A distinguished name is composed of the following components: common name, organization, country, e-mail (optional), phone (optional), organizational unit (optional), locality (optional), serial number.

Electronic Identity —An electronic identity consists of a subscriber’s digital signature key pair and a corresponding digital signature certificate, the subscriber’s confidentiality key pair, and a corresponding confidentiality certificate, and all of the individual’s or organization’s previous private confidentiality [decryption] keys.

Enhanced Reliability Check (ERC) — Includes normal business reference checking in addition to a complete security check conducted by the OPP covering criminal record investigation, optional credit check, and could include the requirement for fingerprinting.

End-entity — An entity that uses the keys and certificates created within a PKI for purposes other than the management of those keys and certificates. An end-entity may be an individual, a role, a group, a device, or an application.

Entity — Any autonomous element within a PKI, including a CA and a RA.



Entrust Administrator (CA Agent) — A trusted person who used Entrust/Admin to administer the Entrust system. They use it to enable and disable users individually or in bulk, revoke user’s keys, initiate key recovery for users, create new encryption key pairs for users, disable and re-enable a user’s ability to sign files, and increase the maximum number of users in a CA domain. They can also review audit logs. Depending on the organizations security policy, the Administrator may also be able to change default user certificate lifetimes (and perhaps disable certificate updates) and default Encryption and Verification policies. They can also issue new CRLs.

Existing Open Community — A group where membership is available to all.

External Domains — Domains that are not subject to the policies of the GO-PKI Policy Management Authority.

Federated Coordinating PMA (FCPMA) — A PMA whose members would represent the PMA’s of the ten provinces, the territories, and the federal government as equals. This group would help ensure inter-operability between PKI domains by establishing national agreements on PKI policies and standards, cross-recognition, and where appropriate Canadian positions on international PKI issues.

GO BPS & Business Partner Domains — The PKI domains for organizations and individuals who provide services that are regulated and/or funded by the Government. These groups include business partners (i.e., doctors, lawyers) or broader public sector organizations (i.e. municipalities, universities, schools, hospitals).

GO OPS Domain — The PKI domain for the Ontario Public Service (i.e.: employees of the organizations within the Government including government agencies, boards, and commissions).

Initialization — A PKI process by which a subscriber obtains his or her public-private key pairs and associated public key certificates. It is through this process that subscribers obtain their first keys and certificates. Initialization also supports the recovery of subscriber profiles and to re-activate a subscriber following certain types of certificate revocation. When use for profile recovery and following revocation, the subscriber's private decryption key history is recovered. To initialize, the subscriber must have initialization data, which are generated by the CA application.

Initialization Data — Activation data (i.e. reference number and authorization code) issued by the CA and used once during the subscriber initialization process to authenticate the subscriber and secure the initialization session between the PKI client application and the CA application.

Internal Domain — The domain of the GO-PKI CA and its subordinate CAs that are subject to the policies of the GO PMA.

Integrity — A PKI security service that prevents unauthorized modifications of data or transactions to occur. Integrity is established and verified using the digital signature mechanism.

Inter-domain – Between CA hierarchies.

Interoperability – The ability for users who had their public keys certified by one CA to trust and use the public keys of users certified by another CA.

Intra-domain – Within a CA hierarchy.

Key Management — A set of actions performed by PKI applications and CA and RA personnel to manage keys. Key management is comprised of generation, renewal, back up, recovery, and expiration.



Key Recovery — To recover a subscriber’s private decryption keys to the subscriber’s newly created electronic identity.

Local Registration Authority (LRA) — A registration authority authorized by the central RA to service a local community of subscribers.

Master Users — Master users first help the Entrust Site Planner to install the Entrust infrastructure software, and then maintain the Entrust/Authority services which consist of Administration Service, Key Management Service, and Directory Service, plus the Entrust/Authority database. These maintenance tasks are accomplished through the Entrust/Master Control user interface. Master users are highly trusted people in an organization who have a sound working knowledge of the operating system.

Non-repudiation — A condition whereby a subscriber cannot deny having digitally signed a transaction or a file.

Object Identifier — A unique alphanumeric identifier registered under the International Organization for Standardization (ISO) registration standard to reference a specific object or object class.

Operational Authority — An agent of the CA domain or enterprise. For a closed community CA providing a service to an enterprise, this role would likely be performed by a position such as the Director of Information Technology Security. The Operational Authority is responsible to the Policy Authority for:

a) Interpreting the Certificate Policies which were selected or defined by the Policy Authority;

b) Developing a Certification Practice Statement (CPS) , in accordance with the IETF PKIX Part 4 Framework, to document the CAs compliance to the Certificate Policies and other requirements;

c) Maintaining the CPS to ensure that it is updated as required; and

d) Operating the CA in accordance with the CPS.

Operations Zone — An area where access is limited to personnel who work there and to properly escorted visitors. An operations zone is normally accessible from a reception zone.

PKI Client — A software application that processes subscriber certificates, CA certificates, and cross-certificates during certificate path validation, and that uses the public key they contain to obtain PKI security services.

PKI Readiness Assessment — An overview of a methodology for implementing Trusted Services based upon a Public Key Infrastructure (PKI). It is to be the basis for questions that need to be answered in preparation for a presentation to a CIO about business and technical security issues that need to be addressed to securely transform an organization from paper to electronic media across evolving e-business models.

PKIX (Public Key Infrastructure X.509) — A set of working documents of the Internet Engineering Task Force (IETF) that specify technical and operational requirements for public key infrastructures. PKIX documents cover a wide range of subjects, including certificate management protocols, operational protocols, certificate policies and certification practices framework, and certificate and CRL profiles.

Policy Authority — An agent of the CA domain or enterprise. For a closed community CA providing a service to an enterprise, this role would likely reside with the corporate Chief Information Officer (CIO). The Policy Authority is responsible for:



a) Selecting and/or defining Certificate Policies, in accordance with the IETF PKIX Part 4 Framework , for use in the CA domain or organization enterprise;

b) Approving of any cross-certification or inter-operability agreements with external CA domains

c) Approving practices which the CA must follow by reviewing the Certification Practice Statement to ensure consistency with the Certificate Policies; and

d) Providing policy direction to the Operational Authority.

Privacy Impact Assessment (PIA) — A privacy impact assessment (PIA) is a process that helps to determine whether new technologies, information systems, and proposed programs or policies meet basic privacy requirements. It measures both technical compliance with privacy legislation - such as the Freedom of Information and Protection of Privacy Act (FIPPA) or the Municipal Freedom of Information and Protection of Privacy Act (MFIPPA) B and the broader privacy implications of a given proposal.

Private Decryption Key — See confidentiality key pair.

Private Signing Key — See digital signature key pair.

Profile — The subscriber’s electronic identity.

Provisional Policy Management Authority (P/PMA) — Is the temporary governance body of the GO-PKI. This group establishes policy and provides direction for the GO-PKI. A permanent Policy Management Authority will replace it when approved by Management Board.

Public Encryption Key — See confidentiality key pair.

Public Key Infrastructure (PKI) — A structure of hardware, software, people, processes, and policies that employs digital signature and encryption using public and private key pairs to enable parties who were previously unknown to each other to establish trust relationships, and to conduct secure and confidential communication, transactions, and information exchange.

Public Verification Keys — See digital signature key pair.

Reception Zone — The entry to a facility where the initial contact between the public and a ministry or agency occurs, where services are provided, information is exchanged and access to operations zones is controlled. To varying degrees, activity in a reception zone is monitored by the personnel who work there, by other personnel or by security staff. Access by the public may be limited to specific times of the day or for specific reasons. Entry beyond the reception zone is indicated by a recognizable perimeter such as a doorway or an arrangement of furniture and dividers in an open office environment.

Reference Number (REFNum) — A number (e.g. 914801), obtained from the Entrust Administrator (CA Agent), which is used along with an authorization code to create a new profile or to recover an existing profile. The reference number can only be used once and then it is no longer valid.

Registration — Process by which PKI users obtain keys and certificates.

Registration Authority (RA) — An entity that is responsible for identification and authentication of certificate subjects, but does not sign or issue certificates (i.e. an RA is delegated certain tasks on behalf of a CA). An RA is responsible for the registration process within their domain.

Relative Distinguished Name — A set of one or more attributes of the distinguished name.

Relying Party — May or may not be Subscriber of the GO-PKI CA domain. The Relying Party is a recipient of another person’s certificate, who may act in reliance on that person’s certificate and/or digital



signature. Repository — A location where CRLs, ARLs, and certificates are stored for access by end-entities (may also be referred to as a Directory).

Role-Based Attributes — Data elements that are associated with the role of an individual as identified by a Role Identifier within a consistent use domain. The attributes describe his/her role and/or access rights with respect to the specific Government program(s) or service(s) within the consistent use domain (e.g., restricted access to specific applications and/or program data).

Role Identifier — An identifier uniquely assigned to an individual by a Program Manager when the individual is first enrolled in specific Government program(s) or service(s) (e.g., program account number). The role identifier is used exclusively within the domain to identify the individual within the domain, to access his/her role-based attributes, and to access program data pertaining to the individual.

Security Officer — The main role of a Security Officer is to set up and administer an organization’s security polity as it applies to Administrators and subscribers. Security Officers can also add, enable, disable, and delete other Security Officers, Administrators, Directory Administrators, and Entrust users (although adding subscribers is mainly an Administrator’s job). They can do this of users individually or in bulk. They can also increase the maximum number of users in a CA domain.

Set-up Information — Entrust term for Reference Number and Authorization Code (also referred to as initialization data).

Subscriber — A member of the CA domain. A party who is the subject of a certificate and who is capable of using, and is authorized to use, the private key, that corresponds to the public key in the certificate. Responsibilities and obligations of the Subscriber would be as required by the Certificate Policy and as described in the Subscriber Agreement.

Subscriber Agreement— An agreement between the CA and a subscriber defining the subscriber’s rights and obligations with regard to their keys and certificates.

Token — Can be either a hardware or software piece that typically will hold identifying information about an individual (e.g. Smart Card). It will be portable or remotely accessible to enable its bearer to authenticate their identity at dispersed access points.

User — An individual who owns a government-issued electronic identity and who uses it in conjunction with a government program or service. Users are subscribers of the GO-PKI.

Appendix B – List of Acronyms

ARL – Authority Revocation List

BPS – Broader Public Sector

CA – Certification Authority

CONOP – Concept of Operations

CP – Certificate Policy

CPS – Certification Practice Statement

CRL – Certificate Revocation List

DIT – Directory Information Tree



DN – Distinguished Name

EDMS – Electronic Directory and Messaging Service

FIPPA – Freedom of Information and Protection of Privacy Act

GO – Government of Ontario

GO-PKI – Government of Ontario Public Key Infrastructure

IETF – Internet Engineering Task Force

IM/IT – Information Management/Information Technology

LRA – Local Registration Authority

MFIPPA – Municipal Freedom of Information and Protection of Privacy Act

OPS – Ontario Public Service

PKI – Public Key Infrastructure

PKIX – Public Key Infrastructure X.509

PMA – Policy Management Authority

RA – Registration Authority

RFC – Request for Comments

Appendix C - Roles and Responsibilities


The Policy Management Authority (PMA) is an individual or an organization that is responsible for specifying local policy requirements above those specified in this standard. The PMA may be part of the same organization as the subscribers, and may be part of the same organization as the other PKI entities. No matter what the arrangement, however, the relationship between the PMA and the other entities remains the same. The PMA specifies additional requirements that the CA, RAs, subscribers, or relying parties must comply with to support local requirements.

The policy management authority (PMA) is an individual or an organization that is responsible for:

Identifying opportunities for inter-domain cross-certification and submitting requests

The PMA reviews the request and approves or rejects it. During its review, the PMA may request additional documentation from the CA organization (e.g., PKI or network design documents, certification practice statement, operational procedures).

Negotiating and ratifying inter-domain cross-certification agreements

Approving CA certification and intra-domain cross-certification requests



Resolving disputes concerning CA certification and cross-certification

10.1.2 Operational Authority

The Operational Authority (OA) is an individual or an organization appointed by the PMA that is responsible for the management and operations of one or more Certification Authorities (CA). The Operational Authority’s responsibilities cover all aspects of CA operations, including administration, human resources, physical sites, hardware and software, change and problem management, maintenance, and support.


A certification authority (CA) is a PKI entity that is responsible for:

Creation and signing of certificates binding subscribers with their public keys

Creation of subscriber confidentiality key pairs (if required)

Promulgation of certificate status through certificate revocation lists or through an on-line service

A CA is a PKI entity that is responsible for:

Identifying opportunities for CA certification and intra-domain cross-certification and submit requests

Conducting compliance audits when CA certification and intra-domain cross-certification requests require it

Specifying and implementing changes to their CA when CA certification and intra-domain cross-certification requests require it

Implementing CA certification and intra-domain cross-certification agreements

The CA shall ensure that all personnel performing duties with respect to the operation of the CA receive comprehensive training in:

PKI security principles and mechanisms

All software versions in use on the CA and RA system

All CA duties they are expected to perform

Roles and responsibilities of an RA

Disaster recovery and business continuity procedures


A registration authority (RA) is a PKI entity that is responsible for:

Authentication of applicants requesting certificate issuance

Authentication of subscribers requesting other subscriber management services

Subscriber management



An RA may perform duties on behalf of more than one CA, providing that in doing so it satisfies all the requirements of this standard.

More than one RA may support the same subscriber community. If the community is large or geographically dispersed, the RAs delegate a subset of their responsibilities to local registration authorities or a Head LRA. The RA requirements specified in the Certificate Policy apply equally to LRAs.

This standard assumes that all interoperability operations are performed by CAs.

10.1.5 Head LRA

A Head LRA may be established by the RA. The RA may delegate some or all of their duties to the Head LRA. The Head LRA is responsible for: Authentication of LRAs Managing the LRA Network as directed by the RA Ensuring LRAs adhere to this policy when performing their duties Subscriber management

10.1.6 LRA Administrators

A local registration authority (LRA) administrator is an individual appointed by an RA or Head LRA to perform the day-to-day registration operations within an RA’s subscriber domain. Typically, an LRA administrator operates in a different geographical location than the RA to service a local community of subscribers.

The LRAs main responsibility is to register GO-PKI subscribers, in accordance with the CP and the appropriate Program Profile directives. The LRAs responsibility is to verify the accuracy and authenticity of the information provided by the individual to support the application for a certificate (see Chapter 2 Section 4.2 Certificate Application Processing) and forward the certificate requests to the GO-PKI CA staff using secure methods. By adhering to detailed practices described in the CPS, LRAs meet the obligations imposed upon them by the certificate policies supported by the GO-PKI CA. LRAs are responsible for:

Providing LRA services during standard business hours;

Assisting, promoting and educating subscribers on the use of PKI technology;

Identifying and authenticating certificate applicants and submitting valid subscriber registration to the GO-PKI CA staff;

Identifying and authenticating GO-PKI subscribers during the life cycle management functions of certificates and forwarding the following types of requests to the GO-PKI CA staff:

o key recovery requests;

o key compromise notifications;

o name and organization name changes request;



o subscription termination requests; and

o suspension requests.

Distributing subscriber activation data and GO-PKI client application software; and

Recording and signing all actions carried out in the performance of LRA duties. LRAs are accountable for actions performed on behalf of the GO-PKI CA. All certificate requests and certificate life cycle management requests are either digitally signed or manually signed by an authorized LRA.

10.1.7 Subscribers

A subscriber is a PKI entity to which the CA issues certificates for the purpose of using PKI security services (e.g., origin authentication, receiving encrypted communications).

The subscriber has no responsibilities with respect to interoperability.


The responsibilities of a relying party who is a subscriber of the GO-PKI are the same as those specified for subscribers (Section 4.6.7 above). The responsibilities of a relying party who is a subscriber of an external CA must be specified in the cross-certification agreement between the Government of Ontario and the external CA in accordance with the Interoperability Standard.

A relying party is a PKI entity that relies on, or that causes a PKI client application to rely on, a CA certificate or a cross-certificate when using PKI security services (e.g., verifying message origin, encrypting a communication).

10.1.9 Sponsor

A sponsor is an individual or an organization that authorizes the issuance of certificates to subscribers within the sponsor’s area of responsibility. The sponsor is often part of the same organization as the subscribers and relying parties. A sponsor is an individual or an organization with PKI service requirements that may request interoperability to support a particular business requirement. The sponsor is often part of the same organization as a subscriber or relying party community.

10.1.10 Program managers manage the use of certificates, keys, role identifiers, and attributes within their area of responsibility. Custodians of Information and Information Technology

Custodians of information and information technology specify functional requirements for the integration of PKI security services into applications.

Annex A Government of Ontario Public Key Infrastructure Mapping of GO-PKI Certificate Policy Certificate Policy to PKIX Framework

Version 3.2 November 17, 2008 Page A-2–1

10.1.11 Root Certification Authority

The root CA is a PKI entity that operates a CA at the top of a CA hierarchy. The root CA is responsible for:

Assisting their PMA and the CAs operating within their domain with technical aspects of CA certification and cross-certification

Conducting compliance audits when CA certification and cross-certification requests require it

Specifying changes to the root CA when the implementation of CA certification and cross-certification requests require it

Implementing CA certification and cross-certification agreements

In the absence of a root CA, a certification authority operating within the domain assumes these responsibilities.