Ethiopian PKI X.509 Certificate Policy Overview

Ethiopian PKI X.
509 Certificate Policy
Ethiopian PKI X.509 Certificate Policy
Draft Version 1.0
INFORMATION NETWORK SECURITY AGENCY
2012 E.C.
Document Control
Document Name Ethiopian PKI X.509 Certificate Policy
Status Release
Version 1.0
Last Update
Document Owner Information Network Security Agency, INSA
Table of Contents
1. INTRODUCTION ..................................................................................................................................... 1
1.1. Overview ............................................................................................................................................ 1
1.2. Document Name and Identification .................................................................................................. 1
1.3. PKI Participants .................................................................................................................................. 2
1.3.1. Certification Authority (CA)................................................................................................ 2
1.3.1.1. Two-Level CA Hierarchy ..................................................................................................... 2
1.3.1.2. Root Certificate Authority of Ethiopia (INSA) .................................................................... 3
1.3.1.3. Sub-CAs .............................................................................................................................. 4
1.3.2. Registration Authority (RA) ................................................................................................ 4
1.3.3. Local Registration Authority (LRA) ..................................................................................... 4
1.3.4. Subscribers ......................................................................................................................... 5
1.3.5. Relying Parties .................................................................................................................... 5
1.3.6. Other Participants .............................................................................................................. 5
1.3.6.1. Repository Service Providers ............................................................................................. 5
1.3.6.2. Timestamp Service Providers ............................................................................................. 6
1.4. Certificate Usage ............................................................................................................................... 6
1.4.1. Appropriate Certificate Uses .............................................................................................. 6
1.4.1.1. Certificates Issued to Individuals ....................................................................................... 6
1.4.1.2. Certificates Issued to Organizations .................................................................................. 7
1.4.1.3. Assurance Levels ................................................................................................................ 8
1.4.2. Prohibited Certificate Uses ................................................................................................ 9
1.5. Policy Administration......................................................................................................................... 9
1.5.1. Organization Administering the Document ....................................................................... 9
1.5.2. Contact Person ................................................................................................................... 9
1.5.3. Person Determining Certification Practice Statement Suitability for the Policy ............... 9
1.5.4. CP/CPS Approval Procedures ............................................................................................. 9
1.6. Definitions and Acronyms ............................................................................................................... 10
1.6.1. Definitions ........................................................................................................................ 10
1.6.2. Acronyms/Abbreviations ................................................................................................. 14
2. PUBLICATION AND REPOSITORY RESPONSIBILITIES ............................................................................ 16
2.1. Repositories ..................................................................................................................................... 16
i
2.2. Time or Frequency of Publication Repositories............................................................................... 16

2.2.1. Repository Obligations ..................................................................................................... 16
2.3. Time or Frequency of publication ................................................................................................... 17
2.4. Access Controls on Repositories...................................................................................................... 17
3. IDENTIFICATION & AUTHENTICATION ................................................................................................. 18
3.1. Naming ............................................................................................................................................ 18
3.1.1. Types of Names ................................................................................................................ 18
3.1.2. Need for Names to be Meaningful .................................................................................. 18
3.1.3. Anonymity or Pseudonymity of Subscribers .................................................................... 18
3.1.4. Rules for Interpreting Various Name Forms .................................................................... 18
3.1.5. Uniqueness of Names ...................................................................................................... 18
3.1.6. Recognition, Authentication & Role of Trademarks ........................................................ 18
3.2. Initial Identity Validation ................................................................................................................. 19
3.2.1. Method to Prove Possession of Private Key .................................................................... 19
3.2.2. Authentication of Organization Identity .......................................................................... 19
3.2.3. Authentication of Individual Identity ............................................................................... 19
3.2.3.1. Authentication of Component Identities ......................................................................... 20
3.2.4. Non-verified Subscriber Information ............................................................................... 20
3.2.5. Validation of Authority..................................................................................................... 20
3.2.6. Criteria for Interoperation ............................................................................................... 20
3.3. Identification and Authentication for Re-Key Requests .................................................................. 21
3.3.1. Identification and Authentication for Routine Re-key ..................................................... 21
3.3.2. Identification and Authentication for Re-key after Revocation....................................... 21
3.4. Identification and Authentication for Revocation Request ............................................................. 21
4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ................................................................... 22
4.1. Certificate Application ..................................................................................................................... 22
4.1.1. Who can submit Certificate Application .......................................................................... 22
4.1.2. Enrollment Process and Responsibilities ......................................................................... 22
4.2. Certificate Application Processing ................................................................................................... 22
4.2.1. Performing Identification and Authentication Functions ................................................ 22
4.2.2. Approval or Rejection of Certificate Applications............................................................ 23
4.2.3. Time to Process Certificate Application ........................................................................... 23
ii
4.3. Certificate Issuance ......................................................................................................................... 23

4.3.1. CA Actions during Certificate Issuance ............................................................................ 23
4.3.2. Notification to Subscriber by CA of Certificate Issuance ................................................. 23
4.4. Certificate Acceptance..................................................................................................................... 23
4.4.1. Conduct Constituting Certificate Acceptance .................................................................. 23
4.4.2. Publication of the Certificate by the CA ........................................................................... 23
4.4.3. Notification of Certificate Issuance by the CA to Other Entities...................................... 23
4.5. Key Pair and Certificate Usage......................................................................................................... 24
4.5.1. Subscriber Private Key and Certificate Usage .................................................................. 24
4.5.2. Relying Party Public Key and Certificate Usage ............................................................... 24
4.6. Certificate Renewal ......................................................................................................................... 24
4.6.1. Circumstance for Certificate Renewal ............................................................................. 24
4.6.2. Who may Request Renewal ............................................................................................. 25
4.6.3. Processing Certificate Renewal Requests ........................................................................ 25
4.6.4. Notification of New Certificate Issuance to Subscriber ................................................... 25
4.6.5. Conduct Constituting Acceptance of a Renewal Certificate ............................................ 25
4.6.6. Publication of the Renewal Certificate by the CA ............................................................ 25
4.7. Certificate Re-Key ............................................................................................................................ 26
4.7.1. Circumstance for Certificate Re-key ................................................................................ 26
4.7.2. Who may Request Certification of a New Public Key ...................................................... 26
4.7.3. Processing Certificate Re-keying Requests ...................................................................... 26
4.7.5. Conduct Constituting Acceptance of a Re-keyed Certificate ........................................... 26
4.7.6. Publication of the Re-keyed Certificate by the CA ........................................................... 26
4.8. Certificate Modification................................................................................................................... 27
4.8.1. Circumstances for Certificate Modification ..................................................................... 27
4.8.2. Who May Request Certificate Modification .................................................................... 27
4.8.3. Processing Certificate Modification Requests ................................................................. 27
4.8.5. Conduct Constituting Acceptance of Modified Certificate .............................................. 27
iii
4.8.6. Publication of the Modified Certificate by the CA ........................................................... 27

4.9. Certificate Revocation and Suspension ........................................................................................... 27
4.9.1. Circumstance for Revocation of a Certificate .................................................................. 27
4.9.2. Who Can Request Revocation of a Certificate ................................................................. 28
4.9.3. Procedure for Revocation Request .................................................................................. 28
4.9.4. Revocation Request Grace Period.................................................................................... 29
4.9.5. Time within which CA must Process the Revocation Request ......................................... 29
4.9.6. Revocation Checking Requirements for Relying Parties .................................................. 29
4.9.7. CRL Issuance Frequency ................................................................................................... 29
4.9.8. Maximum Latency for CRLs .............................................................................................. 30
4.9.9. Online Revocation/ Status Checking availability .............................................................. 30
4.9.10. Online Revocation Checking Requirements ..................................................................... 30
4.9.11. Other Forms of Revocation Advertisements Available .................................................... 30
4.9.12. Special Requirements Re-key Compromise ..................................................................... 30
4.9.13. Circumstances for Suspension ......................................................................................... 30
4.9.14. Who can Request Suspension .......................................................................................... 31
4.9.15. Procedure for Suspension Request .................................................................................. 31
4.9.16. Limits on Suspension Period ............................................................................................ 31
4.10. Certificate Status Services ............................................................................................................... 31
4.10.1. Operational Characteristics.............................................................................................. 31
4.10.2. Service Availability ........................................................................................................... 32
4.10.3. Optional Features............................................................................................................. 32
4.11. End of Subscription .......................................................................................................................... 32
4.12. Key Escrow and Recovery ................................................................................................................ 32
4.12.1. Key Escrow and Recovery Policy and Practices ................................................................ 32
4.12.2. Session key encapsulation and recovery policy and practices ........................................ 32
5. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS ................................................................. 33
5.1. Physical Controls.............................................................................................................................. 33
5.1.1. Site Location & Construction ........................................................................................... 33
5.1.2. Physical Access ................................................................................................................. 33
5.1.3. Power and Air Conditioning ............................................................................................. 35
iv
5.1.4. Water Exposures .............................................................................................................. 35

5.1.5. Fire Prevention & Protection ........................................................................................... 35
5.1.6. Media Storage .................................................................................................................. 35
5.1.7. Waste Disposal ................................................................................................................. 35
5.1.8. Off-Site backup................................................................................................................. 35
5.2. Procedural Controls ......................................................................................................................... 36
5.2.1. Trusted Roles.................................................................................................................... 36
5.2.1.1. Administrator ................................................................................................................... 36
5.2.1.2. Security Officer................................................................................................................. 36
5.2.1.3. Auditor ............................................................................................................................. 37
5.2.1.4. Operator ........................................................................................................................... 37
5.2.1.5. Registration Authority...................................................................................................... 37
5.2.1.6. Repository Officer ............................................................................................................ 37
5.2.1.7. Timestamp Officer ........................................................................................................... 37
5.2.2. Number of Persons Required per Task ............................................................................ 37
5.2.3. Identification and Authentication for Each Role.............................................................. 38
5.2.4. Roles Requiring Separation of Duties .............................................................................. 38
5.3. Personnel Controls .......................................................................................................................... 39
5.3.1. Qualifications, Experience, and Clearance Requirements ............................................... 39
5.3.2. Background Check Procedures ........................................................................................ 39
5.3.3. Training Requirements ..................................................................................................... 40
5.3.4. Retraining Frequency and Requirements ........................................................................ 41
5.3.5. Job Rotation Frequency and Sequence ............................................................................ 41
5.3.6. Sanctions for Unauthorized Actions ................................................................................ 41
5.3.7. Independent Contractor Requirements........................................................................... 41
5.3.8. 5.3.8. Documentation Supplied to Personnel .................................................................. 41
5.4. Audit Logging Procedures ................................................................................................................ 41
5.4.1. Types of Events Recorded ................................................................................................ 42
5.4.2. Frequency of Processing Audit Log .................................................................................. 46
5.4.3. Retention Period for Audit Log ........................................................................................ 46
5.4.4. Protection of Audit Logs................................................................................................... 46
5.4.5. Audit Log Backup Procedures .......................................................................................... 47
v
5.4.6. Audit Collection System (internal vs. external)................................................................ 47

5.4.7. Notification to Event-Causing Subject ............................................................................. 47
5.4.8. Vulnerability Assessments ............................................................................................... 47
5.5. Records Archival .............................................................................................................................. 47
5.5.1. Types of Records Archived ............................................................................................... 47
5.5.2. Retention Period for Archive ........................................................................................... 48
5.5.3. Protection of Archive ....................................................................................................... 48
5.5.4. Archive Backup Procedures ............................................................................................. 49
5.5.5. Requirements for Time-Stamping of Records.................................................................. 49
5.5.6. Archive Collection System (internal or external) ............................................................. 49
5.5.7. Procedures to Obtain & Verify Archive Information........................................................ 49
5.6. Key Changeover ............................................................................................................................... 49
5.7. Compromise and Disaster Recovery................................................................................................ 50
5.7.1. Incident and Compromise Handling Procedures ............................................................. 50
5.7.2. Computing Resources, Software, and/or Data are corrupted ......................................... 51
5.7.3. Entity Private Key Compromise Procedures .................................................................... 51
5.7.4. Business Continuity Capabilities after a Disaster ............................................................. 51
5.8. Sub-CA and RA Termination ............................................................................................................ 52
6. TECHNICAL SECURITY CONTROLS ........................................................................................................ 53
6.1. Key Pair Generation and Installation ............................................................................................... 53
6.1.1. Key Pair Generation ......................................................................................................... 53
6.1.2. Private Key Delivery to Subscriber ................................................................................... 53
6.1.3. Public Key Delivery to Certificate Issuer .......................................................................... 53
6.1.4. Sub-CA Public Key Delivery to Relying Parties ................................................................. 53
6.1.5. Key Sizes ........................................................................................................................... 54
6.1.6. Public Key Parameters Generation and Quality Checking ............................................... 54
6.1.7. Key Usage Purposes (as per X.509 v3 key usage field) .................................................... 54
6.2. Private Key Protection and Cryptographic Module Engineering Controls ...................................... 55
6.2.1. Cryptographic Module Standards and Controls............................................................... 55
6.2.2. Private Key (m out of n) Multi-Person Control ................................................................ 55
6.2.3. Private Key Escrow ........................................................................................................... 55
6.2.4. Private Key Backup ........................................................................................................... 56
vi
6.2.5. Private Key Archival ......................................................................................................... 56

6.2.6. Private Key Transfer into or from a Cryptographic Module ............................................ 56
6.2.7. Private Key Storage on Cryptographic Module ................................................................ 56
6.2.8. Method of Activating Private Key .................................................................................... 56
6.2.9. Methods of Deactivating Private Key............................................................................... 57
6.2.10. Method of Destroying Private Key ................................................................................... 57
6.2.10.1. Cryptographic Module Rating .......................................................................................... 57
6.3. Other Aspects of Key Management................................................................................................. 57
6.3.1. Public Key Archival ........................................................................................................... 57
6.3.2. Certificate Operational Periods and Key Pair Usage Periods ........................................... 57
6.4. Activation Data ................................................................................................................................ 57
6.4.1. Activation Data Generation and Installation ................................................................... 57
6.4.2. Activation Data Protection ............................................................................................... 58
6.4.3. Other Aspects of Activation Data..................................................................................... 58
6.5. Computer Security Controls ............................................................................................................ 58
6.5.1. Specific Computer Security Technical Requirements ...................................................... 58
6.5.2. Computer Security Rating ................................................................................................ 59
6.6. Life-Cycle Technical Controls ........................................................................................................... 59
6.6.1. System Development Controls ........................................................................................ 59
6.6.2. Security Management Controls ....................................................................................... 60
6.6.3. Life Cycle Security Controls .............................................................................................. 60
6.7. Network Security Controls............................................................................................................... 60
6.8. Time-Stamping................................................................................................................................. 60
7. CERTIFICATE, CRL AND OCSP PROFILES ............................................................................................... 62
7.1. Certificate Profile ............................................................................................................................. 62
7.1.1. Version Number(s) ........................................................................................................... 62
7.1.2. Certificate Extensions....................................................................................................... 62
7.1.3. Algorithm Object Identifiers ............................................................................................ 62
7.1.4. Name Forms ..................................................................................................................... 62
7.1.5. Name Constraints............................................................................................................. 62
7.1.6. Certificate Policy Object Identifier ................................................................................... 62
7.1.7. Usage of Policy Constraints Extension ............................................................................. 62
vii
7.1.8. Policy Qualifiers Syntax and Semantics............................................................................ 63

7.1.9. Processing Semantics for the Critical Certificate Policies Extension ............................... 63
7.2. CRL Profile........................................................................................................................................ 63
7.2.1. Version numbers .............................................................................................................. 63
7.2.2. CRL and CRL entry extensions .......................................................................................... 63
7.3. OCSP Profile ..................................................................................................................................... 63
7.3.1. Version Number ............................................................................................................... 63
7.3.2. OCSP Extension ................................................................................................................ 64
8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS................................................................................ 65
8.1. Frequency or Circumstances of Assessments ................................................................................. 65
8.2. Identity/ Qualifications of Assessor................................................................................................. 65
8.3. Assessor’s Relationship to Assessed Entity ..................................................................................... 66
8.4. Topics Covered by Assessment........................................................................................................ 66
8.5. Actions Taken as a Result of Deficiency .......................................................................................... 67
8.6. Communications of Results ............................................................................................................. 67
9. OTHER BUSINESS AND LEGAL MATTERS.............................................................................................. 69
9.1. Fees .................................................................................................................................................. 69
9.1.1. Certificate Issuance and Renewal Fees ............................................................................ 69
9.1.2. Certificate Access Fees ..................................................................................................... 69
9.1.3. Revocation Status Information Access Fees .................................................................... 69
9.1.4. Fees for Other Services .................................................................................................... 69
9.1.5. Refund Policy ................................................................................................................... 69
9.2. Financial Responsibility ................................................................................................................... 69
9.2.1. Insurance Coverage.......................................................................................................... 69
9.2.2. Other Assets ..................................................................................................................... 69
9.2.3. Insurance or Warranty Coverage for End-Entities ........................................................... 70
9.3. Confidentiality of Business Information .......................................................................................... 70
9.3.1. Scope of Confidential Information ................................................................................... 70
9.3.2. Information not within the Scope of Confidential Information ....................................... 70
9.3.3. Responsibility to Protect Confidential Information ......................................................... 70
9.4. Privacy of Personal Information ...................................................................................................... 71
9.4.1. Privacy Plan ...................................................................................................................... 71
viii
9.4.2. Information Treated as Private ........................................................................................ 71

9.4.3. Information Not Deemed Private .................................................................................... 71
9.4.4. Responsibility to Protect Private Information ................................................................. 71
9.4.5. Notice and Consent to Use Private Information .............................................................. 71
9.4.6. Disclosure Pursuant to Judicial or Administrative Process .............................................. 71
9.4.7. Other Information Disclosure Circumstances .................................................................. 71
9.5. Intellectual Property Rights ............................................................................................................. 71
9.5.1. Property Rights in Certificates and Revocation Information ........................................... 72
9.5.2. Property Rights in the CPS ............................................................................................... 72
9.5.3. Property Rights in Names................................................................................................. 72
9.5.4. Property Rights in Keys .................................................................................................... 72
9.6. Representations and Warranties..................................................................................................... 72
9.6.1. CAs Representations and Warranties .............................................................................. 72
9.6.2. RA Representations and Warranties ................................................................................ 73
9.6.3. Subscriber Representations and Warranties ................................................................... 74
9.6.4. Relying Party Representations and Warranties ............................................................... 74
9.6.5. Representations and Warranties of Other Participants .................................................. 75
9.6.5.1. Time Stamp Service Provider Representations and Warranties ...................................... 75
9.6.5.2. Repository Service Provider Representations and Warranties ........................................ 75
9.7. Disclaimers of Warranties ............................................................................................................... 75
9.8. Limitations of Liabilities ................................................................................................................... 75
9.9. Indemnities ...................................................................................................................................... 76
9.10. Term and Termination ..................................................................................................................... 76
9.10.1. Term ................................................................................................................................. 76
9.10.2. Termination...................................................................................................................... 77
9.10.3. Effect of Termination and Survival................................................................................... 77
9.11. Individual Notices and Communications with Participants ............................................................. 77
9.12. Amendments ................................................................................................................................... 77
9.12.1. Procedure for Amendment .............................................................................................. 77
9.12.2. Notification Mechanism and Period ................................................................................ 77
9.12.3. Circumstances under Which OID Must be changed ........................................................ 77
9.13. Dispute Resolution Provisions ......................................................................................................... 77
ix
9.14. Governing Law ................................................................................................................................. 78

9.15. Compliance with Applicable Law ..................................................................................................... 78
9.16. Miscellaneous Provisions................................................................................................................. 78
9.16.1. Entire Agreement ............................................................................................................. 78
9.16.2. Assignment....................................................................................................................... 78
9.16.3. Severability....................................................................................................................... 78
9.16.4. Enforcement (Attorney’s Fees and Waiver of Rights)...................................................... 79
9.16.5. Force Majeure .................................................................................................................. 79
9.17. Other Provisions .............................................................................................................................. 79
Appendix A: Certificate Profile .................................................................................................................... 80
A.1 Root CA Certificate Profile ..................................................................................................................... 80
A.2 Sub-CA Certificate Profile ...................................................................................................................... 80
A.3 End User Signature Certificate Profile (Personal Use)........................................................................... 81
A.4 End User Encryption Certificate Profile (Personal Use)......................................................................... 81
A.5 End User Signature Certificate Profile (Organizational Use) ................................................................. 82
A.6 End User Encryption Certificate Profile (Organizational Use) ............................................................... 82
A.7 SSL Certificate Profile ............................................................................................................................ 83
A.8 System Certificate Profile ...................................................................................................................... 84
A.9 Time Stamping Authority (TSA) Certificate Profile ................................................................................ 84
A.10 Code Signing Certificate Profile ........................................................................................................... 85
A.11 OCSP Responder Certificate Profile ..................................................................................................... 85
A.12 Document Signer Certificate Profile (Organizational Use) .................................................................. 86
Appendix B: CRL Profile ............................................................................................................................... 86
B.1 Root CA CRL Profile ................................................................................................................................ 86
B.2 Sub-CA CRL Profile ................................................................................................................................. 87
Appendix C: OCSP Request & Respond Format ........................................................................................... 87
C.1 OCSP Request ........................................................................................................................................ 87
C.2 OCSP Respond ....................................................................................................................................... 87
x
1. INTRODUCTION
1.1. Overview
This Certificate Policy (CP) defines certificate policies to facilitate interoperability among
subscribers and relying parties for e-government, e-commerce and other services. This CP, the
related CPS and Certificate Authorities (CAs) are governed by Information Network Security
Agency (INSA). Secure e-government and e-commerce in Ethiopia is governed by the Electronic
Signature Proclamation No. 1072/2018.
The Ethiopia PKI is a hierarchical PKI with the trust chain starting from the Root Certificate
Authority (Root CA) of Ethiopia. Below the Root CA, there are Subordinate Certificate
Authorities (Sub-CAs) licensed by the Root CA to issue digital certificates under the Electronic
Signature Proclamation No. 1072/2018. Sub-CAs can be private sector companies, government
organizations, public sector companies and Non-Government Organizations (NGOs). Below the
Sub-CAs, there are end users.
If applicable, the certificate policies apply to all components of the Ethiopian PKI. Ethiopian PKI
components include but are not limited to Root CA, Sub-CAs, Registration Authorities (RAs),
Local Registration Authorities (LRs), subscribers, Relying Parties, and Repositories.
Any use or reference of this CP outside the scope of influence of the Ethiopia PKI is completely
at the using party‟s risk.
This CP is consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure
X.509 (IETF PKIX) RFC 3647, Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework.
1.2. Document Name and Identification
This document is the CA Certificate Policy followed by the Root CA and its Sub-CAs and will be
approved for publication by the House of Peoples Representatives/Council of Ministers. This CP
document will be disclosed to the public at the website https://www.insa.gv.et.
This document is entitled” Ethiopian PKI X.509 Certificate Policy”. It is identified by Object
Identifier (OID) 2.16.231.100.1. The meanings of the components of the OID are given in the
table below.
1
2 joint-iso-itu-t
16 Country
231 et
100 This is a place holder for OID of Root CA
1 Ethiopian PKI X.509 Certificate Policy
1.3. PKI Participants
CA is a certificate authority that issues digital certificates in accordance with this CP. As a CA,
CA performs functions associated with Public Key operations, including receiving certificate
requests, issuing, revoking and renewing a digital certificate, and maintaining, issuing, and
publishing CRLs or OCSP responses.
1.3.1. Certification Authority (CA)
1.3.1.1. Two-Level CA Hierarchy
The Ethiopian PKI consists of a two-level CA hierarchy; the top level is the Root CA, the highest
level of authority that manages the Ethiopian PKI. The Ethiopian PKI is formed using additional
Sub-CAs as depicted in the figure below.
The Ethiopian PKI comprises:
• One Root CA root-signing all Sub-CAs and kept offline.

• One or more Sub-CAs: The Sub-CAs are signed by the Root CA and are responsible for
the issuance of certificates to end users.
• Below Sub-CAs are end users that can be individuals or organizations which are
expected to get certificate from Sub-CAs;
2
1.3.1.2. Root Certificate Authority of Ethiopia (INSA)

The Root CA of Ethiopian PKI is INSA.INSA is a trust anchor for subscribers of the PKI domain
when the subscribers act as relying party.
Root Certificate Authority shall have the following powers and duties:
• issue license to certificate providers and monitor their activities and operations;
• ensure the trustworthiness and the overall security of the crypto system;
• issue working procedures and standards that certificate providers shall follow;
• drafting and approving of the Ethiopian CP;
• follow and update this CP;
• accept applications from entities to be Sub-CAs;
3
• doing compliance audit to make sure that Sub-CAs are working in conformance to this
CP;
• drafting and approving of CPS for this CP;
1.3.1.3. Sub-CAs
Sub-CAs are legal persons duly authorized or recognized to issue certificates and related services.
A Sub-CA is one that is licensed by the Root CA as per Electronic Signature Proclamation No.
1072/2018. Sub-CAs shall:
• operate and manage the Sub-CA system and its functions in accordance with this CP;
• issue and manage certificates;
• send notification of issuance, revocation or renewal of certificates;
• publish issued certificates and revocation information; and
• handle revocation request regarding certificate it issued;
1.3.2. Registration Authority (RA)

A Registration Authority (RA) is an entity that is responsible for the identification and
authentication of subscribers, but does not sign or issue certificates. RA is the entity that collects
Application Form, Subscriber‟s identity and information that are to be entered into his or her
public key certificate.
Any Sub-CA may delegate its functions in relation to registration of subscribers; identification of
prospect subscriber‟s identity and ensuring the authenticity and appropriateness of information to
document registration and authentication bodies. In some cases, the Sub-CA performs the
subscriber registration function internally.
1.3.3. Local Registration Authority (LRA)
The Sub-CA might delegate the RA function to external registration authorities (sometimes
referred to as Local Registration Authorities or LRAs) that may or may not be part of the same
legal entity as the Sub-CA. LRAs have to abide by all the requirements of this CP. LRAs may,
however implement more restrictive practices based on their internal requirements. The LRAs are
responsible for the collection of certificate requests and their secure transmission to the RA.
Any LRA operating under this CP must have a contractual agreement with Sub-CA which
indicates the authorization for their role as LRA and clearly details the minimum requirements,
processes and liabilities according to this CP.
4
1.3.4. Subscribers
A Subscriber is the entity (the user to whom, or device to which, a certificate is issued) whose
Distinguished Name (DN) appears as the subject in a certificate, and who asserts that it uses the
key and certificate in accordance with this policy. A subscriber means a person who is the subject
named in a certificate, accepts the authenticity of the content the certificate and owns a private
key which corresponds to a public key listed in that certificate.
1.3.5. Relying Parties
A Relying Party means a person who acts relying on the information contained in a certificate or
in the authenticity of digital signature. A Relying Party uses a Subscriber‟s certificate to:
• identify the identity and status of an individual;
• be sure of the integrity of a digitally signed message;
• know the identity of the creator of a message;
• make confidential communications with the Subscriber;
• rely only on a recommended reliance limit and transaction type expressly stated in the
certificate;
The Relying Party relies on the validity of the binding between the Subscriber‟s name and public
key. A Relying Party may use information in the certificate (such as Certificate Policy Identifiers)
to determine the suitability of the certificate for a particular use. The Relying Party is responsible
for deciding whether or how to check the validity of the certificate by checking the appropriate
certificate status information.
For this Certificate Policy, the relying party may be any Entity that wishes to validate the binding
of a public key to the name of a federal employee, contractor, other affiliated personnel, private
organization representative, a legal person or device.
1.3.6. Other Participants
1.3.6.1. Repository Service Providers
Repository means a system for disclosing, storing and retrieving certificates or other information
relating to certificates. If anyone wants to render a repository service for certificates issued by
Sub-CAs, one has to apply to the Root CA first. To know all the necessary procedures and
requirements of application, the obligations and accountabilities of Repository Service Providers
refer to the Electronic Signature Regulation.
5
1.3.6.2. Timestamp Service Providers

Timestamp service means a digitally signed notation appended to electronic message, digital
signature or certificate indicating the correct date and time of an action. If it is not stated
otherwise in the procedures and/or standards the Root Certificate Authority releases all the
regulations stipulated in the Electronic Signature Regulation on for Repository Service Providers
shall apply to Timestamp Service Providers as well.
1.4. Certificate Usage
1.4.1. Appropriate Certificate Uses

Certificate usage is deemed to be appropriate if it is conducted according to rules stipulated in
Electronic Signature Proclamation No. 1072/2018 and Electronic Signature Regulation. Relying
Parties should evaluate the environment and the associated threats and vulnerabilities and
determine the level of risk they are willing to accept based on the sensitivity or significance of the
information. Each Relying Party makes this evaluation for its application outside the control of
this CP.
1.4.1.1. Certificates Issued to Individuals

Individual Certificates are normally used by individuals to sign and encrypt e-mail and to
authenticate to applications (client authentication). While the most common usages for individual
certificates are included in the table below, an individual certificate may be used for other
purposes, provided that a Relying Party is able to reasonably rely on that certificate and the usage
is not otherwise prohibited by law, this CP, the CPS under which the certificate has been issued
and any agreements with Subscribers.
Certificate
Assurance Level Usage
Class
Low Medium High Signing Encryption Client
Assurance Assurance Assurance Authentication
Level Level Level
Class 1 √ √ √ √
Certificates
6
Class 2 √ √ √ √
Certificates
Class 3 √ √ √ √
Certificates
1.4.1.2. Certificates Issued to Organizations
Organizational Certificates are issued to organizations after authentication that the Organization
legally exists and that other Organization attributes included in the certificate (excluding no
verified subscriber information) are authenticated e.g. ownership of an Internet or e-mail domain.
It is not the intent of this CP to limit the types of usages for Organizational Certificates. While the
most common usages are included in the table below, an Organizational Certificate may be used
for other purposes, provided that a Relying Party is able to reasonably rely on that certificate and
the usage is not otherwise prohibited by law, by this CP, by any CPS under which the certificate
has been issued and any agreements with Subscribers.
Certificate
Assurance Level Usage
Class
Medium High Code/Content Secure Authentication
Signing TLS/SSL Signing and
Sessions Encryption
Class 3 √ √ √ √ √
Certificate
Class 3 SSL √ √ √ √ √
Certificates
Class 3 Code √ √ √ √ √
Signing
Certificates
7
1.4.1.3. Assurance Levels

The assurance levels are prescribed taking into consideration the Critical Mass Cyber Security
Requirement Version 1.0 and Text for ITU-T Recommendation X.1254|ISO/IEC DIS 29115
--Information technology –Security techniques – Entity authentication assurance
framework. Accordingly, the following three assurance levels are to be used for authenticating
entities in the Ethiopian PKI.
Assurance Level Description

Low At Low Assurance Level, there is minimal confidence in the asserted
identity of the entity, but some confidence that the entity is the same
over consecutive authentication events. This assurance level is used
when minimum risk is associated with erroneous authentication. There is
no specific requirement for the authentication mechanism used; only that
it provides some minimal assurance. A wide range of available
technologies, including the credentials associated with higher levels of
assurance, can satisfy the authentication requirements for this Low
Assurance Level. This level does not require use of cryptographic
methods.
Medium At Medium Assurance Level, there is some confidence in the asserted
identity of the entity. This assurance level is used when moderate risk is
associated with erroneous authentication. Single-factor authentication is
acceptable. Successful authentication shall be dependent upon the entity
proving, through a secure authentication protocol, that the entity has
control of the credential. Controls shall be in place to reduce the
effectiveness of
Eavesdropper and online guessing attacks. Controls shall be in place to
protect against attacks on stored credentials.
8
High At High Assurance level, there is high confidence in an asserted

identity of the entity. This assurance level is used where substantial risk
is associated with erroneous authentication. This assurance level shall
employ multi-factor authentication. Identity proofing procedures shall be
dependent upon verification of identity information. Any secret
information exchanged in authentication protocols shall be
cryptographically protected. There are no requirements concerning the
generation or storage of credentials; they may be stored or generated in
general purpose computers or special purpose hardware. This assurance
level requires in-person identity proofing for human entities and the use
of tamper-resistant hardware devices for the storage of all secret or
private cryptographic keys.
1.4.2. Prohibited Certificate Uses

Subscribers „use of certificates is generally governed by Electronic Signature Proclamation No.
1072/2018 and CP Regulation. Thus, any use of the certificate by the subscribers for anything
other than the ones mentioned in the two proclamations is totally prohibited.
1.5. Policy Administration
1.5.1. Organization Administering the Document

INSA is responsible for all aspects of this CP.
1.5.2. Contact Person

Questions regarding this CP shall be directed to INSA at contact@insa.gov.et
1.5.3. Person Determining Certification Practice Statement Suitability for the Policy
Certification Practices Statements, derived from this CP, must conform to the corresponding
requirements of this Certificate Policy. The Root CA shall determine the suitability of any CPS to
this policy. In each case, the Root CA shall base the determination of suitability on a compliance
audit results and recommendations. See Section 8 for further details.
1.5.4. CP/CPS Approval Procedures
Approval of the CP/CPS and subsequent amendments shall be made by INSA. Amendments shall
either be in the form of a document containing an amended form of the CP/CPS or an update
9
notice. Updates shall supersede any designated or conflicting provisions of the referenced version
of the CP/CPS.
1.6. Definitions and Acronyms
1.6.1. Definitions
Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate.
Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued
to devices, the Applicant is the entity that controls or operates the device named in the Certificate,
even if the device is sending the actual certificate request.
Audit Period: it is the period between the first day (start) and the last day of operations (end)
covered by the auditors in their engagement. The coverage rules and maximum length of audit
periods are defined in Section 8.1.
Audit Report: means a report from a Qualified Auditor stating the Qualified Auditor‟s opinion
on whether an entity‟s processes and controls comply with the mandatory provisions of the
Requirements.
Certificate: means an electronic data which links public key to the person named in the
certificate and confirms the real identity of that person.
Certificate Data: Certificate requests and data related thereto (whether obtained from the
Applicant or otherwise) in the Sub-CA‟s possession or control or to which the Sub-CA has
access.
Certificate Management Process: Processes, practices, and procedures associated with the use
of keys, software, and hardware, by which the Sub-CA verifies Certificate Data, issues
Certificates, maintains a Repository, and revokes Certificates.
Certificate Policy: A set of rules that indicates the applicability of a named Certificate to a
particular community and/or PKI implementation with common security requirements.
Certificate Problem Report: Complaint of suspected Key Compromise, Certificate misuse, or

other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.
10
Certificate Provider: a legal person duly authorized or recognized to issue certificate and
related service.
Certificate Revocation List: A regularly updated time-stamped list of revoked Certificates that is
created and digitally signed by the Sub-CA that issued the Certificates.
Certification Authority: An organization that is responsible for the creation, issuance,

revocation, and management of Certificates. The term applies equally to both Root CA and
SubCAs.
Certification Practice Statement: One of several documents forming the governance framework
in which Certificates are created, issued, managed, and used.
Domain Name: The label assigned to a node in the Domain Name System. Domain Namespace:
The set of all possible Domain Names those are subordinate to a single node in the Domain Name
System.
Expiry Date: The “Not After” date in a Certificate that defines the end of a Certificate‟s validity
period.
Fully-Qualified Domain Name: A Domain Name that includes the labels of all superior nodes in
the Internet Domain Name System.
Key Compromise: A Private Key is said to be compromised if its value has been disclosed to an
unauthorized person, an unauthorized person has had access to it, or there exists a practical
technique by which an unauthorized person may discover its value.
Key Generation Script: A documented plan of procedures for the generation of a Sub-CA Key
Pair.
Key Pair: means a private key and its corresponding public key in an asymmetric cryptosystem.
Sub-CA: A Certification Authority whose Certificate is signed by the Root CA.
Legal Entity: An association, corporation, partnership, proprietorship, trust, government entity or

other entity with legal standing in a country‟s legal system.
11
Object Identifier: A unique alphanumeric or numeric identifier registered under the

International Organization for Standardization‟s applicable standard for a specific object or object
class.
OCSP Responder: An online server operated under the authority of the Sub-CA and connected
to its Repository for processing Certificate status requests. See also, Online Certificate Status
Protocol.
Online Certificate Status Protocol: An online Certificate-checking protocol that enables

relying-party application software to determine the status of an identified Certificate. See also
OCSP Responder.
Person: means a physical or legal person.
Private Key: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is
used to create Digital Signatures and/or to decrypt electronic records or files that were encrypted
with the corresponding Public Key.
Public Key: The key of a Key Pair that may be publicly disclosed by the holder of the
corresponding Private Key and that is used by a Relying Party to verify Digital Signatures created
with the holder's corresponding Private Key and/or to encrypt messages so that they can be
decrypted only with the holder's corresponding Private Key.
Public Key Infrastructure: A set of hardware, software, people, procedures, rules, policies, and
obligations used to facilitate the trustworthy creation, issuance, management, and use of
Certificates and keys based on Public Key Cryptography.
Qualified Auditor: means a natural person or Legal Entity that meets the requirements of Section
8.3.
Registration Authority (RA): Any Legal Entity that is responsible for identification and
authentication of subjects of Certificates, but is not a CA, and hence does not sign or issue
Certificates. An RA may assist in the certificate application process or revocation process or both.
When “RA” is used as an adjective to describe a role or function, it does not necessarily imply a
separate body, but can be part of the Sub-CA.
12
Reliable Method of Communication: A method of communication, such as a postal/courier

delivery addresses, telephone number, or email address that was verified using a source other
than the Applicant Representative.
Relying Party: means a person who acts relying on the information contained in a certificate or
in the authenticity of digital signature.
Repository: An online database containing publicly-disclosed PKI governance documents (such

as Certificate Policies and Certification Practice Statements) and Certificate status information,
either in the form of a CRL or an OCSP response.
Root CA: The top-level Certification Authority whose Root Certificate is distributed by
Application Software Suppliers and that issues Sub-CA Certificates.
Root Certificate: The self-signed Certificate issued by the Root CA to identify itself and to
facilitate verification of Certificates issued to its Sub-CA s.
Subject: The natural person, device, system, unit, or Legal Entity identified in a Certificate as the
Subject. The Subject is either the Subscriber or a device under the control and operation of the
Subscriber.
Subject Identity Information: Information that identifies the Certificate Subject. Subject
Identity Information does not include a domain name listed in the subjectAltName extension or
the Subject commonName field.
Subscriber: means a person who is the subject named in a certificate, accepts the authenticity of
the content the certificate and owns a private key which corresponds to a public key listed in that
certificate.
Subscriber Agreement: An agreement between the Sub-CA and the Applicant/Subscriber that
specifies the rights and responsibilities of the parties.
Terms of Use: Provisions regarding the safekeeping and acceptable uses of a Certificate issued in
accordance with these Requirements when the Applicant/Subscriber is an Affiliate of the SubCA
or is the Sub-CA.
13
Time Stamp Service: means a digitally signed notation appended to electronic message, digital
signature or certificate indicating the correct date and time of an action;
Valid Certificate: means a certificate which has been issued by a licensed or recognized
certificate provider, accepted by the subscriber, not revoked, not suspended or not expired.
Validity Period: The period of time measured from the date when the Certificate is issued until
the Expiry Date.
1.6.2. Acronyms/Abbreviations
AES Advanced Encryption Standard
CA Certificate Authority
COTS Commercial-Off-The-Shelf
CP Certificate Policy
CPS Certification Practice Statement
CRL Certificate Revocation List
CSP Certificate Status Provider
DN Distinguished Name
DNS Domain Name Service
FIPS (US) Federal Information Processing Standard (United States)

FIPS PUB (US) Federal Information Processing Standard Publication
(United States)
HR Human Resources
HSM Hardware Security Module
HTTP Hypertext Transfer Protocol
ID Identifier
IETF Internet Engineering Task Force
INSA Information Network Security Agency
IT Information Technology
KRP Key Recovery Policy
14
KRPS Key Recovery Practices Statement

Sub-CAs Subordinate Certificate Authorities
LRAs Local Registration Authorities
OID Object Identifier
PIN Personal Identification Number
PKI Public Key Infrastructure
PKCS Public Key Cryptography Standard
PKIX Public Key Infrastructure X.509
RA Registration Authority
RFC Request For Comments
RSA Rivest-Shamir-Adleman (encryption algorithm)
SCVP Simple Certificate Validation Protocol
SHA-1 Secure Hash Algorithm, Version 1
SSL Secure Sockets Layer
TDES Triple Data Encryption Standard
TLS Transport Layer Security
UPS Uninterrupted Power Supply
15
2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
2.1. Repositories
INSA may recognize other bodies that satisfy requirements set forth under a regulation and
directives issued in accordance with the Electronic Signature 1072/2018 to provide repository
service. Any Accredited CA shall establish easily accessible repository system for disclosing
information stated below. The location of any publication will be one that is appropriate to the
certificate-using community, and in accordance with the total security requirements of the Root
CA. Sub-CAs shall operate Hypertext Transfer Protocol (HTTP) or Lightweight Directory Access
Protocol (LDAP) based repositories.
2.2. Time or Frequency of Publication Repositories
Directory services update data on certificates several times per hour and CRLs every four hours.
The Root CA updates its CRLs at least once in three months and immediately after revoking a
Sub-CA‟s certificate. Sub-CAs update their CRLs every 24 hours. New versions of documents
are published as soon as they have been approved.
2.2.1. Repository Obligations
The Sub-CAs shall publish all Certificates and Cross Certificates issued, revocation data for
issued Certificates, CP, CPS, and Relying Party agreements and Subscriber Agreements in
Repositories. The Sub-CAs shall ensure that revocation data for issued Certificates and its Root
Certificate are available through a Repository 24 hours a day, 7 days a week with a minimum of
99% availability overall per year with a scheduled downtime that does not exceed 0.5% annually.
Sub-CAs may refrain from making publicly available certain sensitive and/or confidential
documentation including security controls, operating procedures, and internal security policies.
These documents are, however, made available to Qualified Auditors.
16
2.3. Time or Frequency of publication
Sub-CAs shall make publicly available this CP and their CPSs, Subscriber Agreements, Relying
Party agreements, and CRLs in Repositories, terms and conditions and any other information
related to the service it provides or any modifications made thereof. CRLs should contain entries
for all revoked unexpired Certificates with a validity period that depends on Certificate type
and/or position of the Certificate within the Certificate chain. Sub-CAs may choose to maintain
the serial numbers of expired Certificates on a CRL to further promote additional security.
Certificates and certificate status information shall be published as specified in Section 4.
2.4. Access Controls on Repositories
The Sub-CAs shall provide unrestricted read access to its Repositories and shall implement
logical and physical controls to prevent unauthorized write access to such Repositories. But any
PKI Repository information not intended for public dissemination or modification shall be
protected. The integrity and authenticity of its public documentation is maintained through the
use of Digital Signatures applied to documents.
17
3. IDENTIFICATION & AUTHENTICATION
3.1. Naming
3.1.1. Types of Names
To identify a Subscriber, Sub-CAs shall follow naming and identification rules that include types
of names assigned to the Subject, such as X.500 distinguished names, RFC-822 names, X.400
names or any other applicable framework.
3.1.2. Need for Names to be Meaningful
When applicable, Sub-CAs shall use distinguished names to identify both the Subject and issuer
name of the Certificate. All end-entity certificates issued by Sub-CAs shall be meaningful and
shall contain the subject‟s legal name as well as the subject‟s unique Kebele Identification
Number or Passport Number for certificates issued for citizens and residents.
3.1.3. Anonymity or Pseudonymity of Subscribers
This CP does not give permission to anonymous or pseudonymous Subscribers.
3.1.4. Rules for Interpreting Various Name Forms
Rules for interpreting name forms shall be in accordance with applicable Standards.
3.1.5. Uniqueness of Names
The Root CA shall enforce controls for guaranteeing the uniqueness of subject Distinguishing
Names (DNs). Within the context of the Ethiopian PKI, Subscriber and Sub-CA names shall be
unique. The DN of the Root CA must also be guaranteed to be unique, so that it will not make
conflict with other internationally accepted Root CAs.
3.1.6. Recognition, Authentication & Role of Trademarks
Subscribers shall not use names in their Certificate Application or Certificate
Request that infringe upon the intellectual property rights of entities outside of their authority.
18
3.2. Initial Identity Validation
Certificate applicants must communicate application requests for certificates to an authorized RA

or LRA via a trustworthy process. An authorized RA, equipped with Registration Authority
hardware and software, may communicate authorizations to issue Certificates directly to the
SubCA electronically, provided all communication is secure. An LRA, who is not equipped with
Registration Authority hardware and software, must transmit authorization requests to issue
Certificates to the appropriate RA by secure means (i.e., digitally signed electronic means, via
registered mail, or in person).
3.2.1. Method to Prove Possession of Private Key
The RAs (or LRAs) shall enforce that a Proof-of-Possession of private key is submitted as part of
certificate requests. A possible implementation would be to rely on certificate requests to be
processed by Sub-CAs and containing a Proof-of-Possession (e.g. PKCS#10).
3.2.2. Authentication of Organization Identity
Any individual who requests certificates on behalf of an organizational user shall include the
name of the user who made the request, the name of the organization of which a certificate is
requested, the address of the organization, and proof that the claimed organization exits. The role
of the Sub-CA shall be verifying the information it received concerning the organization.
3.2.3. Authentication of Individual Identity
A Sub-CA shall ensure that the applicant‟s identity information is verified; the applicant‟s
identity information and public key are properly bound and record the process that was followed
for issuance of each certificate. Process information shall depend upon the certificate level of
assurance and shall be addressed in the applicable CPS.
The process documentation and authentication requirements shall include the following:
1. The identity of the person performing the identity verification;
2. A signed declaration by that person that he or she verified the identity of the applicant;
19
3. The applicant shall present Passport or Kebele ID. The applicant shall also present a
document as a proof of residential address.
4. Unique identifying numbers from the Identifier (ID) of the verifier and from an ID of the
applicant;
5. The date and time of the verification; and
6. A declaration of identity signed by the applicant using a handwritten signature or equivalent

per Ethiopian Laws.
3.2.3.1. Authentication of Component Identities
Some computing and communications devices (routers, firewalls, servers, etc.) and software
applications will be named as certificate subjects. In such cases, the device must have a human
sponsor. The sponsor is responsible for providing the following registration information:
 Equipment identification (e.g., serial number) or service name (e.g., DNS name) or
unique software application name
 Equipment or software application public keys
 Equipment or software application authorizations and attributes (if any are to be included
in the certificate)
 Contact information to enable the Sub-CA or RA to communicate with the sponsor when
required
3.2.4. Non-verified Subscriber Information
Information that is not verified shall not be included in certificates.
3.2.5. Validation of Authority
For Certificates having implicit or explicit organizational affiliation, a determination shall be

made whether the applicant has specific rights, entitlements, or permissions, including the
permission to act on behalf of an organization to obtain that certificate.
3.2.6. Criteria for Interoperation
Certificates shall be issued in accordance with the Electronic Signature Proclamation No.
1072/2018 and applicable laws in order to ensure interoperability.
20
3.3. Identification and Authentication for Re-Key Requests
Re-keying a certificate means that the Sub-CAs create a new certificate that has the same
characteristics and level as the old one, except that the new certificate has a new, different public
key (corresponding to a new, different private key) and a different serial number and possibly
different validity period.
3.3.1. Identification and Authentication for Routine Re-key
The Sub-CAs and subscribers shall identify themselves through use of their current Signing Key
or by using the initial identity-proofing process as described in Section 3.2.
3.3.2. Identification and Authentication for Re-key after Revocation
Except for renewal, if a certificate has been revoked, the subject (i.e., a Sub-CA or an end user) is
required to go through the initial registration process described in Section 3.2 to obtain a new
certificate.
3.4. Identification and Authentication for Revocation Request
Revocation requests shall be authenticated before authorized parties act upon them. Requests to
revoke a certificate may be authenticated using that certificate's associated public key, regardless
of whether or not the private key has been compromised. In the case of loss of key, Sub-CA can
suspend/revoke the certificate after verifying the subscriber‟s identity. In the case where
subscriber is not in a position to communicate (death, unconscious state, mental disorder or any
other convincing reason), on receiving such information, the Sub-CA can suspend the certificate
and after verification the certificate can be revoked.
21
4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
Communication among the CA, RA, and subscriber shall have requisite security services (i.e.,
source authentication, integrity, non-repudiation, or confidentiality) applied to them
commensurate with the assurance level of the certificate being managed.
4.1. Certificate Application
4.1.1. Who can submit Certificate Application
For Sub-CA certificate, an authorized representative of the Sub-CA shall submit the request to the
Root CA. The application shall be submitted based on the procedure issued by the Root CA. The
Root CA shall make the procedure available to all entities. The application shall be accompanied
by a CPS written to the format of the Internet X.509 Public Key Infrastructure Certificate Policy
and Certification Practices Framework [RFC3647].
For end entity certificates, the application process shall be in accordance with the CPS issued by
the Sub-CAs.
4.1.2. Enrollment Process and Responsibilities
Sub-CA shall maintain systems and processes that sufficiently authenticate the Applicant‟s
identify for all Certificate types that present the identity to Relying Parties. Applicants should
submit sufficient information to allow Sub-CAs and RAs to successfully perform the required
verification. Sub-CAs and RAs shall protect communications and securely store information
presented by the Applicant during the application process.
4.2. Certificate Application Processing
4.2.1. Performing Identification and Authentication Functions
It is the responsibility of the target CA to verify that the information in certificate applications is
accurate. Applicable CPS shall specify procedures to verify information in certificate
applications.
For further information, see section 3.2.2, section 3.2.3 and section 3.2.4 thereof.
22
4.2.2. Approval or Rejection of Certificate Applications
CAs shall approve or reject applications for Certificates in accordance with applicable CPSs.
4.2.3. Time to Process Certificate Application
Certificate applications are processed instantaneously once the requests have been formally
approved. Consequently, certificates are issued within reasonable time after registration by a RA
or a LRA.
4.3. Certificate Issuance
4.3.1. CA Actions during Certificate Issuance
After the CA verified the source of the request, Certificates shall be checked to ensure that all
fields and extensions are properly populated. After generation, verification, and acceptance, a
CA shall post the certificate as set forth in applicable CPSs.
4.3.2. Notification to Subscriber by CA of Certificate Issuance
The CA shall notify the Subscriber of the issuance of a Certificate in a convenient and
appropriate way based on information submitted during the enrollment process.
4.4. Certificate Acceptance
4.4.1. Conduct Constituting Certificate Acceptance
CAs shall inform the subscriber that he may not use the certificate until the subscriber has
reviewed and verified the accuracy of the data incorporated into the certificate. To avoid this
being an open-ended stipulation, CAs may set a time limit by when the certificate is deemed to be
accepted.
4.4.2. Publication of the Certificate by the CA
Each CA shall publish all CA and subscriber certificates in the appropriate certificate repositories.
4.4.3. Notification of Certificate Issuance by the CA to Other Entities
No Stipulation.
23
4.5. Key Pair and Certificate Usage
4.5.1. Subscriber Private Key and Certificate Usage
All Subscribers must protect their Private Key taking care to avoid disclosure to third parties.
CAs must maintain a suitable Subscriber Agreement which highlights the obligations of the
Subscriber with respect to Private Key protection. Private Keys must only be used as specified in
the appropriate key usage and extended key usage fields as indicated in the corresponding
Certificate. Where it is possible to make a backup of a Private Key, Subscribers must use the
same level of care and protection attributed to the live Private Key. At the end of the useful life of
a Private Key, Subscribers must securely delete the Private Key and any fragments that it has
been split into for the purposes of backup.
4.5.2. Relying Party Public Key and Certificate Usage
CAs must describe the conditions under which certificates may be relied upon by Relying Parties
within their CPS including the appropriate mechanisms available to verify certificate validity
(e.g. CRL or OCSP). CAs must also offer a Relying Party agreement to Subscribers the content
of which should be presented to the Relying Party prior to reliance upon a Certificate. Relying
Parties should use the information to make a risk assessment and as such are solely responsible
for performing the risk assessment prior to relying on the Certificate or any assurances made.
Software used by Relying Parties should be fully compliant fully compatible with applicable
standards including best practice for chaining decisions around policies and key usage.
4.6. Certificate Renewal
Renewing a certificate means creating a new certificate with the same name, key, and other
information as the old one, but a new, extended validity period and a new serial number.
4.6.1. Circumstance for Certificate Renewal
CAs that support renewal must identify the products and services under which renewals can be
accepted. A CA may renew a Certificate so long as:
 The original Certificate to be renewed has not been revoked;
24
 The Public Key from the original Certificate has not been blacklisted for any reason; and
 All details within the Certificate remain accurate and no new or additional validation is
required.
4.6.2. Who may Request Renewal
The following entities may request for certificate renewal:
 A Subscriber may request the renewal of its certificate;

 A PKI Sponsor may request renewal of component certificate;
 A CA may request renewal of its subscriber certificates;
4.6.3. Processing Certificate Renewal Requests
A certificate renewal processes shall be achieved using either of the following:
1. Initial registration process as described in Section 3.2; or
2. Identification & Authentication for Re-key as described in Section 3.3, except the old
key can also be used as the new key.
4.6.4. Notification of New Certificate Issuance to Subscriber
See Section 4.3.2.
4.6.5. Conduct Constituting Acceptance of a Renewal Certificate
See Section 4.4.1.
4.6.6. Publication of the Renewal Certificate by the CA
See Section 4.4.2.
No stipulation.
25
4.7. Certificate Re-Key
Re-keying a certificate means that a new certificate is created that has the same characteristics
and level as the old one, except that the new certificate has a new, different public key
(corresponding to a new, different private key) and a different serial number, and it may be
assigned a different validity period.
4.7.1. Circumstance for Certificate Re-key
A Sub-CA may re-key a Certificate as long as: -
 The original Certificate to be re-keyed has not been revoked;
 The new public key has not been blacklisted for any reason; and
 All details within the Certificate remain accurate and no new or additional validation is
required.
4.7.2. Who may Request Certification of a New Public Key
Subscribers with a current, valid certificate may request re-key via a digitally signed message.
Sub-CAs and RAs may request certification of a new public key on behalf of a subscriber.
For component certificates, the PKI sponsor may request certification of a new public key for
the component.
4.7.3. Processing Certificate Re-keying Requests
Re-key requests shall be validated using the procedures for subscriber identity and
authentication for initial certificate issuance as described in Section 3.2 and 3.3 respectively.
See Section 4.3.2.
4.7.5. Conduct Constituting Acceptance of a Re-keyed Certificate
See Section 4.4.1.
4.7.6. Publication of the Re-keyed Certificate by the CA
See Section 4.4.2.
26
No stipulation.
4.8. Certificate Modification
4.8.1. Circumstances for Certificate Modification
No stipulation.
4.8.2. Who May Request Certificate Modification
No stipulation.
4.8.3. Processing Certificate Modification Requests
No stipulation.
No stipulation.
4.8.5. Conduct Constituting Acceptance of Modified Certificate
No stipulation.
4.8.6. Publication of the Modified Certificate by the CA
No stipulation.
No stipulation.
4.9. Certificate Revocation and Suspension
4.9.1. Circumstance for Revocation of a Certificate
A certificate shall be revoked when the binding between the subject and the subject‟s public key
defined within a certificate is no longer considered valid. Examples of circumstances that
invalidate the binding are:
27
1. Identifying information or affiliation components of any names in the certificate become

invalid;
2. The Subject can be shown to have violated the stipulations of its agreement with the CA;
3. The private key is suspected of compromise;
4. The Subject or other authorized party (as defined in the applicable CPS) asks for the
subscriber‟s certificate to be revoked;
5. Private key lost;
6. Subscriber is not in a position to use certificate (Death – copy of Death certificate made
available to the CA).
Whenever any of the above circumstances occur, the associated certificate shall be revoked and
placed on the CRL. Revoked certificates shall be included on all new publications of the
certificate status information until the certificates expire. A revoked certificate shall appear on at
least one CRL.
4.9.2. Who Can Request Revocation of a Certificate
The following entities may request for certificate

revocation:
 A Subscriber;
 A human supervisor of a human subject (for organizational user);
 A PKI Sponsor for component, or Sub-CA;
For Sub-CAs‟ certificates, authorized individuals representing the Sub-CA may request
revocation of certificates.
4.9.3. Procedure for Revocation Request
A procedure to request for certificate revocation shall be:
 identifying the certificate to be revoked;
 explaining the reason for revocation;
28
 allowing the request to be authenticated (e.g., digitally or manually signed by the

subject);
Upon receipt of a revocation request, a Sub-CA shall authenticate the request and then
revoke the certificate.
4.9.4. Revocation Request Grace Period
The revocation request grace period is the time available for a Subscriber to take any necessary
actions themselves in order to request revocation of a suspected Key Compromise, use of a weak
key or discovery of inaccurate information within an issued Certificate.
There is no revocation grace period. Responsible parties must request revocation as soon as they
identify the need for revocation.
4.9.5. Time within which CA must Process the Revocation Request
The CA shall revoke certificates as quickly as practical after a valid revocation request is
received. Revocation requests shall be processed before the next CRL is published.
4.9.6. Revocation Checking Requirements for Relying Parties
Use of revoked certificates could have damaging or catastrophic consequences in certain

applications. This PKI offers revocation information to relying parties through CRLs published
on a publicly available LDAP or through its OCSP responder. The matter of how often new
revocation data should be obtained is a determination to be made by the Relying Party.
4.9.7. CRL Issuance Frequency
CRLs shall be issued periodically, even if there are no changes to be made, to ensure timeliness
of information. Certificate status information may be issued more frequently than the issuance
frequency described below. A Sub-CA shall ensure that superseded certificate status information
is removed from the PKI Repository upon posting of the latest certificate status information.
CRLs shall be published not later than the next scheduled update.
CRLs shall be issued in accordance with the following frequency requirements:
 At least once every three months for Root CA with minimum validity period of 6 months;
29
 At Least Once every 24 hours for Sub-CA with minimum validity of 7 days.
4.9.8. Maximum Latency for CRLs
CRL‟s shall be published within reasonable time of generation. Each CRL is published with the
nextUpdate time specified in the previous CRL for the same scope.
4.9.9. Online Revocation/ Status Checking availability
The Sub-CA shall support, in addition to CRLs, on-line status checking via OCSP. Client
software using on-line status checking need not obtain or process CRLs.
4.9.10. Online Revocation Checking Requirements
No stipulation.
4.9.11. Other Forms of Revocation Advertisements Available
No stipulation.
4.9.12. Special Requirements Re-key Compromise
None beyond those stipulated in Sections 4.7and 4.9.3.
4.9.13. Circumstances for Suspension
CA may suspend the certificate work fully or partially for a time not exceeding 3 months in the
following conditions:
 To examine the occurrence of the following grounds:
o the certificate provider breaches the provisions of this Proclamation or regulations

and directives issued under this proclamation;
o it is proved that the license has been given based on falsified information; o the
certificate provider performs its duty contrary to the objective or condition of the
license;
o the certificate provider is engaged in business activity and the business license
revoked;
30
o the license is expired and is not renewed; o the certificate provider is wind up or
bankrupt;
o the certificate provider is convicted by court of law for involving in criminal
activity linked to certification that erodes the trust;
o the certificate provider has failed to begin operation within three months from the
date it receives a license;
 When the Root CA considers that the grounds are not suffice to revoke the certificate
provider license but defects are required to be corrected within a specified time;
 The Root CA shall notify in writing the grounds for suspension of certificate work and
measures that the Root CA has to take to correct the defects within the time specified;
4.9.14. Who can Request Suspension
Any subscriber or his duly authorized agent may request the certificate provider for the
suspension of a certificate at any times.
4.9.15. Procedure for Suspension Request
A request to suspend a certificate shall:
• identify the certificate to be suspended;
• explain the reason for suspension;
• allow the request to be authenticated (e.g., digitally or manually signed);
4.9.16. Limits on Suspension Period
The Root CA may suspend the certificate work fully or partially for a time not exceeding 3
months.
4.10. Certificate Status Services
4.10.1. Operational Characteristics
CAs shall provide a Certificate status service either in the form of a CRL distribution point or an
OCSP responder or both.
31
4.10.2. Service Availability
Relying Parties are bound to their obligations and the stipulations of this CP irrespective of the
availability of the online certificate status service.
4.10.3. Optional Features
No stipulation.
4.11. End of Subscription
Subscribers may end their subscription to Certificate services due to the termination of the
service, revocation or expiration of the certificate.
4.12. Key Escrow and Recovery
4.12.1. Key Escrow and Recovery Policy and Practices
Under no circumstances shall a CA or end entity signature key be escrowed by a third party.
4.12.2. Session key encapsulation and recovery policy and practices
No stipulation.
32
5. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS
5.1. Physical Controls
The CA shall impose physical security requirements that provide similar levels of protection as
those specified below. All the physical control requirements apply equally to the CA. Equipment
shall be protected from unauthorized access while the cryptographic module is installed and
activated. The RA shall implement physical access controls to reduce the risk of equipment
tampering even when the cryptographic module is not installed and activated. These security
mechanisms shall be commensurate with the level of threat in the RA equipment environment.
The CA equipment shall be in a controlled facility that is monitored 24/7. The CA cryptographic
modules, both those active and operational, and those stored in security containers for on-site and
off-site backup, shall be protected against theft, loss, and unauthorized use by the controls
specified in section 5.1.2 below. Physical security controls should also be in accordance with the
Critical Mass Cyber Security Requirement Standard V1.0.
5.1.1. Site Location & Construction
The location and construction of the facility housing CA, Timestamp Service Provider and
Repository Service Provider equipment should be consistent with facilities used to house high
value, sensitive information. The site location and construction, when combined with other
physical security protection mechanisms such as guards and intrusion sensors, should provide
robust protection against unauthorized access to the CA, Timestamp Service Provider and
Repository Service Provider equipment and records.
5.1.2. Physical Access
CA, Registration Authority, Timestamp Service Provider and Repository Service Provider
equipment should always be protected from unauthorized access. The physical security
requirements pertaining to CA, Timestamp Service Provider and Repository Service Provider
equipment are:
1. Ensure unauthorized access to the hardware is not permitted;
2. Ensure all removable media and paper containing sensitive plaintext information is
stored in secure containers;
33
3. Be manually or electronically monitored for unauthorized intrusion at all times;
4. Ensure an access log is maintained and inspected periodically;

5. Provide at least three layers of increasing security such as perimeter, building, and CA
room;
6. Require two-person physical access control to both the cryptographic module and
computer system for CAs issuing all class certificates;
Removable cryptographic modules should be deactivated prior to storage. When not in use,
removable cryptographic modules, activation information used to access or enable cryptographic
modules shall be placed in secure containers. Activation data should either be memorized, or
recorded and stored in a manner commensurate with the security afforded to the cryptographic
module, and should not be stored with the cryptographic module.
A security check of the facility housing the CA, RA, Timestamp Service Provider and Repository
Service Provider equipment should occur if the facility is to be left unattended. At a minimum,
the check shall verify the following:
1. The equipment is in a state appropriate to the current mode of operation (e.g., that
cryptographic modules are in place when “open”, and secured when “closed”);
2. For off-line CAs, all equipment other than the PKI Repository is shut down);
3. Any security containers are properly secured;
4. Physical security systems (e.g., door locks, vent covers) are functioning properly; and
5. The area is secured against unauthorized access.
A person or group of persons shall be made explicitly responsible for making such checks. When
a group of persons is responsible, a log identifying the person performing a check at each
instance shall be maintained. If the facility is not continuously attended, the last person to depart
shall initial a sign-out sheet that indicates the date and time, and asserts that all necessary
physical protection mechanisms are in place and activated.
34
5.1.3. Power and Air Conditioning
CAs shall have backup power sufficient to automatically lockout input, finish any pending
actions, and record the state of the equipment before lack of power or air conditioning causes a
shutdown. PKI Repositories should be provided with Uninterrupted Power sufficient for a
minimum of 24 hours operation in the absence of commercial power, to support continuity of
operations.
5.1.4. Water Exposures
The CA, Registration Authority, Timestamp Service Provider and Repository Service Provider
equipment shall be installed such that it is not in danger of exposure to water.
5.1.5. Fire Prevention & Protection
The CA, Registration Authority, Timestamp Service Provider and Repository Service Provider
secure facility is fully wired for fire detection, alarm and suppression. Routine, frequent
inspections of all systems shall be made to assure adequate operation.
5.1.6. Media Storage
Electronic optical and other media shall be stored so that they are protected from accidental
damage (water, fire, electromagnetic radiation). Media that contains security audit archive and
backup information shall be stored in a secure, fire-proof, and safe location separate from the CA.
5.1.7. Waste Disposal
All obsolete paper, magnetic media, optical media, etc. created within the enclave shall be
shredded before discarding. Reusable magnetic and optical media may be reused indefinably
within the enclave.
5.1.8. Off-Site backup
Full system backups of the CAs, sufficient to recover from system failure, should be made on a
periodic schedule, described in the respective CPS. Backups should be performed and stored
offsite as described in applicable CPS. At least one full backup copy should be stored at an offsite
location (at a location separate from the CAs equipment). Only the latest full backup needs to be
retained. The backup should be stored at a site with physical and procedural controls
commensurate to that of the operational CAs.
35
5.2. Procedural Controls
5.2.1. Trusted Roles
A trusted role is one whose incumbent performs functions that can introduce security problems if
not carried out properly, whether accidentally or maliciously. The people selected to fill these
roles must be extraordinarily responsible or the integrity of the CA is weakened. The functions
performed in these roles form the basis of trust for all uses of the CA. Two approaches are taken
to increase the likelihood that these roles can be successfully carried out. The first ensures that
the person filling the role is trustworthy and properly trained. The second distributes the functions
among more than one person, so that any malicious activity would require collusion.
The following sections define these and other trusted roles.
5.2.1.1. Administrator
The administrator should be responsible for:
1. Installation, configuration, and maintenance of the CA;
2. Establishing and maintaining CA system accounts;
3. Configuring certificate profiles or templates and audit parameters, and;
4. Generating and backing up CA keys.
Note: - Administrators shall not issue certificates to subscribers.
5.2.1.2. Security Officer
The CA Security Officer should be responsible for issuing certificates, that is:
1. Registering new subscribers and requesting the issuance of certificates;
2. Verifying the identity of subscribers and accuracy of information included in certificates;
3. Approving and executing the issuance of certificates; and
4. Requesting, approving and executing the revocation of certificates;
36
5.2.1.3. Auditor
The Auditor should be responsible for:
1. Reviewing, maintaining, and archiving audit logs;
2. Performing or overseeing internal compliance audits to ensure that the CA is operating in

accordance with this CP and the CPS;
5.2.1.4. Operator
The Operator should be responsible for the routine operation of the CA equipment and operations
such as system backups and recovery or changing recording media.
5.2.1.5. Registration Authority
The roles of RAs engaged by CAs are limited only to the collection of Digital Signature
Certificate (DSC) application form, supporting documents and facilitation of issuance of DSC to
applicants.
Whereas for organizational RA, the responsibilities are:
1. Verifying organizational identity of the applicant.
2. Entering applicant‟s information and verifying correctness;
3. Securely communicating requests and responses from to the CA;
5.2.1.6. Repository Officer
The Repository Officer shall make public a copy of a certificate the CA issued, suspended or
revoked in the repository specified in the certificate; provided that the subscriber accepted it.
5.2.1.7. Timestamp Officer
The Timestamp Officer shall confirm the correct date and time of an act to a specific electronic
message, digital signature or authenticity of a certificate.
5.2.2. Number of Persons Required per Task
Two or more persons are required for CAs for the following tasks:
a. Generation of CAs Signing Keys;
37
b. Activating CAs Signing Keys;
c. Using CAs Signing Keys;
d. Deactivating CAs Signing Keys;
e. Backing up or Duplicating CAs Private Signing Keys;
f. Physical Control of Backups of CAs Signing Keys;
g. Physical Access or Control of the Cryptographic Module;
h. Physical Access or Control of the CAs;
i. Physical Access or Control of the Safes and/or Secure Containers;
j. Physical Access to the CAs;
k. Audit Log Review and Oversight;
l. Recovery of a subscriber‟s encryption private key for a third party as directed by the
CAs Policy Authority or legal judgment;

Note: - All roles are recommended to have multiple persons in order to support continuity of
operations.
5.2.3. Identification and Authentication for Each Role
An individual should identify and authenticate him/herself before being permitted to perform any
actions set forth above for that role or identity. All user authentications are based on two-factor
authentication.
5.2.4. Roles Requiring Separation of Duties
Role separation, when required as set forth below, may be enforced either by the CA equipment,
or procedurally, or by both means.
Individual CA personnel should be specifically designated to the four roles defined in Section
5.2.1 Above. Individuals may assume more than one role, except:
1. Individuals who assume a Security Officer role may not assume an Administrator or
Auditor role;
2. Individuals who assume an Auditor role shall not assume any other role on the CA; and
38
3. Under no circumstances shall any of the seven roles perform its own compliance auditor
function.
Note: - No individual shall be assigned more than one identity.
5.3. Personnel Controls
5.3.1. Qualifications, Experience, and Clearance Requirements
All persons filling trusted roles should be selected on the basis of loyalty, trustworthiness, and
integrity, and should be subject to background investigation.
The trusted roles of these individuals per Section 5.2.1 should be identified.
All trusted roles are required to be held by Ethiopian citizens and in accordance with the
following requirements:
1. Have successfully completed an appropriate training program;
2. Have demonstrated the ability to perform their duties;
3. Be trustworthy;
4. Have no other duties that would interfere or conflict with their duties for the trusted
role;
5. Have not been previously relieved of duties for reasons of negligence or
nonperformance of duties;
6. Have not been denied a security clearance, or had a security clearance revoked for
cause;
7. Have not been convicted of a felony offense; and
8. Be appointed in writing by an approving authority.
5.3.2. Background Check Procedures
All persons filling trusted roles should have completed a favorable background investigation.
The scope of the background check should include the following areas:
1. Employment;
39
2. Education (Regardless of the date of award, the highest educational degree shall be
verified);
3. Place of residence;
4. Law Enforcement; and
5. References
The period of investigation must cover at least the last five (5)
years for each area, excepting the residence check which must cover at least the last three (3)
years. Regardless of the date of award, the highest educational degree shall be verified.
The background investigation shall be performed by an authorized body based on applicable
laws.
5.3.3. Training Requirements
All personnel performing duties with respect to the operation of a CA, Repository Service
Provider, Timestamp Service Provider or a Registration Authority should receive comprehensive
training. Training should be conducted in the following areas:
1. CA/Repository Service Provider/Timestamp Service
Provider/Registration Authority security principles and mechanisms;
2. All PKI software versions in use on the CA system;
3. All PKI duties they are expected to perform;
4. Disaster recovery and business continuity procedures;

5. Electronic Signature Proclamation;
6. Certificate Practices Statement; and
7. Computer Crime Proclamation;
Documentation shall be maintained identifying all personnel who received training and the level
of training completed. Where competence was demonstrated in lieu of training, supporting
documentation shall be maintained.
40
5.3.4. Retraining Frequency and Requirements
Individuals responsible for trusted roles should be aware of changes in the CA, Repository Service
Provider, Timestamp Service Provider or RA operations, as applicable. Any significant change to
the operations should have a training (awareness) plan, and the execution of such plan shall be
documented. Examples of such changes are CA software or hardware upgrade, Registration
Authority software upgrades, changes in automated security systems, and relocation of
equipment.
5.3.5. Job Rotation Frequency and Sequence
Any job rotation frequency and sequencing procedures shall provide for continuity and integrity
of the Ethiopian PKI CA services.
5.3.6. Sanctions for Unauthorized Actions
Any person that operates in violation of this CP or the CPSs related to this CP or the practices and
procedures stated herein, whether through negligence or with malicious intent, shall have
privileges revoked and may be subject to administrative, disciplinary or legal action.
5.3.7. Independent Contractor Requirements
Contractor personnel employed to perform functions pertaining to the CA shall meet applicable
requirements set forth in Section 5.3.1 above. Vendors who provide services to the Ethiopian PKI
shall establish procedures to ensure that any subcontractors who directly provide services to the
Ethiopian PKI perform in accordance with the requirements of Section 5.3.1 above.
5.3.8. 5.3.8. Documentation Supplied to Personnel
For the Ethiopian PKI CA and RA, documentation sufficient to define duties and procedures for
each trusted role shall be provided to the personnel filling that role.
5.4. Audit Logging Procedures
Audit log files should be generated for all events relating to the security of the CAs, Repository
Service Providers, Timestamp Service Providers and RAs. Where possible, the security audit logs
should be automatically collected. Where this is not possible, a logbook, paper form, or other
physical mechanism shall be used. All security audit logs, both electronic and non-electronic,
41
should be retained and made available during compliance audits. The security audit logs for each
auditable event defined in this section should be maintained in accordance with Section 5.5.2.
5.4.1. Types of Events Recorded
All security auditing capabilities of the CAs, Repository Service Providers, Timestamp Service
Providers and Registration RAs operating system and the applications required by this CP should
be enabled. As a result, most of the events identified in the table should be automatically
recorded. At a minimum, each audit record should include the following (either recorded
automatically or manually for each auditable event):
1. The type of event,
2. The date and time the event occurred,
3. Success or failure where appropriate, and
4. The identity of the entity and/or operator that caused the event.
The following events should be recorded.
Auditable Event CA Repository Timestamp RA

Service Service
Provider Provider
SECURITY AUDIT
Any changes to the Audit parameters, X X X
e.g., audit frequency, type of event
audited
Any changes to the Audit parameters, X X X
e.g., audit frequency, type of event
audited
IDENTITY-PROOFING
Successful and unsuccessful attempts
X X X
to assume a role
42
The value of maximum number of
X X X
authentication attempts is changed
The number of unsuccessful
authentication attempts exceeds the
X X X
maximum authentication attempts
during user login
An Administrator unlocks an account
that has been locked as result of X X X
unsuccessful authentication attempts
An Administrator changes the type of
authenticator, e.g., from a password X X X
to a biometric
LOCAL DATA ENTRY
All security-relevant data that is
X X X
entered in the system
REMOTE DATA ENTRY
All security-relevant messages that
X X X
are received by the system
DATA EXPORT AND OUTPUT
All successful and unsuccessful
requests for confidential and X X X
security-relevant information
KEY GENERATION
Whenever the Component generates
a key (not mandatory for single
X X X
session or one-time use symmetric
keys)
PRIVATE KEY LOAD AND STORAGE
The loading of Component private
X X X
keys
All access to certificate subject
Private Keys retained within the CA X N/A N/A
for key recovery purposes
TRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGE
All changes to the trusted Component
Public Keys, including X X X
additions and deletions
PRIVATE AND SECRET KEY EXPORT
The export of private and secret keys
(keys used for a single session or X X X
message are excluded)
CERTIFICATE REGISTRATION
ETHIOPIAN X.509 CERTIFICATE POLICY 41
All certificate requests X N/A X

CERTIFICATE REVOCATION
All certificate revocation requests X N/A X
CERTIFICATE STATUS CHANGE APPROVAL
The approval or rejection of a
X N/A N/A
certificate status change request
CONFIGURATION
Any security-relevant changes to the
X X X
configuration of the Component
ACCOUNT ADMINISTRATION
Roles and users are added or deleted X - -
The access control privileges of a user
X - -
account or a role are modified
CERTIFICATE PROFILE MANAGEMENT
All changes to the certificate profile X N/A N/A
CERTIFICATE STATUS PROVIDERMANAGEMENT
All changes to the CSP profile (e.g.
N/A X N/A
OCSP profile)
REVOCATION PROFILE MANAGEMENT
All changes to the revocation profile X N/A N/A
CERTIFICATE REVOCATION LIST PROFILE MANAGEMENT
All changes to the certificate
X N/A N/A
revocation list profile
MISCELLANEOUS
Appointment of an individual to a
X X N/A
Trusted Role
Designation of personnel for
X - N/A
multiparty control

Installation of the Operating System X X X
Installation of the PKI Application X X X
Installation of hardware
X X X
cryptographic modules
Removal of hardware cryptographic
X X X
modules
Destruction of cryptographic
X X X
modules
System Startup X X X
Logon attempts to PKI Application X X X
Receipt of hardware / software X X X
Attempts to set passwords X X X
Attempts to modify passwords X X X
Back up of the internal CA database X - -

Restoration from back up of the
X - -
internal CA database
File manipulation (e.g., creation,
X - -
renaming, moving)
Posting of any material to a PKI
X - -
Repository
Access to the internal CA database X X -
All certificate compromise
X N/A X
notification requests
Loading tokens with certificates X N/A X
Shipment of Tokens X N/A X
Zeroizing Tokens X N/A X
Re-key of the Component X X X
CONFIGURATION CHANGES
Hardware X X -
Software X X X
Operating System X X X
Patches X X -
Security Profiles X X X
PHYSICAL ACCESS / SITE SECURITY
Personnel Access to room housing
X - -
Component
Access to the Component X X -

Known or suspected violations of
X X X
physical security
ANOMALIES
Software error conditions X X X
Software check integrity failures X X X
Receipt of improper messages X X X
Misrouted messages X X X
Network attacks
X X X
(suspected or confirmed)
Equipment failure X - -
Electrical power outages X - -
Uninterruptible Power Supply (UPS)
X - -
failure
Obvious and significant network
X - -
service or access failures
Violations of Certificate Policy X X X
Violations of Certification Practice
X X X
Statement
Resetting Operating System clock X X X
5.4.2. Frequency of Processing Audit Log
Audit logs shall be reviewed monthly. Such reviews involve verifying that the log has not been
tampered with, and then briefly inspecting all log entries with a more thorough investigation of
any alerts or irregularities in the log. Examples of irregularities include discontinuities in the logs
and loss of audit data. Actions taken as a result of these reviews shall be documented.
5.4.3. Retention Period for Audit Log
Audit logs shall be retained onsite for at least two months as well as being retained in the manner
described Section 5.5.2.
5.4.4. Protection of Audit Logs
The Ethiopian PKI system configuration and procedures should be implemented together to
ensure that:
1. Only authorized people have read access to the logs;
2. Only authorized people may archive audit logs; and,
3. Audit logs are not modified.

The entity performing audit log archive need not have modify access, but procedures must be
implemented to protect archived data from destruction prior to the end of the audit log retention
period (If a system over-writes audit logs after a given time, the audit log is not considered
deleted or destroyed if the audit log has been backed up and archived). Audit logs shall be moved
to a safe, secure storage location separate from the CA equipment.
5.4.5. Audit Log Backup Procedures
Audit logs and audit summaries shall be backed up at least monthly. A copy of the audit shall be
sent off-site on a monthly basis.
5.4.6. Audit Collection System (internal vs. external)
The audit log collection system may or may not be external to the CA, Repository Service
Provider, Timestamp Service Provider or Registration Authority. Audit processes should be
invoked at system startup, and cease only at system shutdown. Should it become apparent that an
automated audit system has failed, and the integrity of the system or confidentiality of the
information protected by the system is at risk, then the CA should determine whether to suspend
its operation until the problem is remedied.
5.4.7. Notification to Event-Causing Subject
This CP imposes no requirement to provide notice that an event was audited to the individual,
organization, device, or application that caused the event.
5.4.8. Vulnerability Assessments
The CA shall assess the vulnerability of its system or its components annually. A routine
assessment of the CA’s system shall be performed regularly for evidence of any malicious
activity.
5.5. Records Archival
5.5.1. Types of Records Archived
CA, Repository Service Provider, Timestamp Service Provider and RA archive records should be
sufficiently detailed to establish the proper operation of the component or the validity of any
certificate (including those revoked or expired) issued by the CA.

Data to be archived CA Repository Timestamp RA
Service Service
Provider Provider
Certification Practice Statement X X X
Contractual obligations X X X
System and equipment configuration X X -
Modifications and updates to system or X X -
configuration
Certificate requests X - -
Revocation requests X - -
Subscriber identity authentication data X N/A X
as per Section 3.2.3
Documentation of receipt and X N/A X
acceptance of certificates
Documentation of receipt of Tokens X N/A X
All certificates issued or published X N/A X
Record of Component CA Re-key X X X
All CRLs and CRLs issued and/or X N/A N/A
published
All Audit Logs X X X
All Audit Log Summaries X X X
Other data or applications to verify X X X
archive contents
Compliance audit reports X X X
5.5.2. Retention Period for Archive
The minimum retention periods for archive data shall be ten (10) years.
If the original media cannot retain the data for the required period, a mechanism to periodically
transfer the archived data to new media should be defined by the archive site. Applications
required processing the archive data should also be maintained for the minimum retention period
specified above.
5.5.3. Protection of Archive
No unauthorized user shall be permitted to write to, modify, or delete the archive. For the
SubCA, archived records may be moved to another medium. The contents of the archive shall not
be released except in accordance with Sections 9.3 and 9.4. Records of individual transactions
may be released upon request of any subscribers involved in the transaction or their legally

recognized agents. Archive media shall be stored in a safe, secure storage facility separate from
the Sub-CA. If the original media cannot retain the data for the required period, a mechanism to
periodically transfer the archived data to new media shall be defined.
5.5.4. Archive Backup Procedures
Archive files shall be backed up along with the security audit logs. Paper archives shall be
backed up to long-term storage media. The Sub-CA’s CPS shall specify the details of which
media type issued, the frequency and other procedural details. The CPS shall also specify how
archive backup files are managed.
5.5.5. Requirements for Time-Stamping of Records
Ethiopian PKI Sub-CA archive records shall be automatically time-stamped as they are created.
The CPS shall describe how system clocks used for time-stamping are maintained in compliance
with applicable time standard.
5.5.6. Archive Collection System (internal or external)
Archive data may be collected in any expedient manner.

5.5.7. Procedures to Obtain & Verify Archive Information
Procedures detailing how to create, verify, package, and transmit archive information should be
published in the applicable CPS.
5.6. Key Changeover
To minimize risk from compromise of a Sub-CA’s private signing key, that key may be changed
often; from that time on, only the new key should be used for certificate signing purposes. The
older, but still valid, certificate will be available to verify old signatures until all of the
certificates signed using the associated private key have also expired. If the old private key is
used to sign CRLs, then the old key should be retained and protected.
The following table provides the life times for certificates and associated private keys.
Key Private key Certificate Key length

Root CA 20 years 20 years 4096-bit keys

Sub-CA 20 years 20 years 4096-bit keys
Timestamp Service 3 years 10 years 4096-bit keys
Provider
Code Signer 2 years 2 years 4096-bit keys
OCSP Responder 2 years 2 years 4096-bit keys
Human Subscriber 2 years 2 years 4096-bit keys
Signature
Human Subscriber 2 years 2 years 4096-bit keys
Encryption
SSL 2 years 2 years 4096-bit keys
Device/System 2years 2 years 4096-bit keys
5.7. Compromise and Disaster Recovery
5.7.1. Incident and Compromise Handling Procedures
If a Sub-CA, Repository Service Provider, Timestamp Service Provider, or Registration Authority

detects a potential hacking attempt or other form of compromise, it should perform an
investigation in order to determine the nature and the degree of damage. If the Sub-CA,
Repository Service Provider, Timestamp Service Provider, or Registration Authority key is
suspected of compromise, the procedures outlined in Section 5.7.3 shall be followed. Otherwise,
the scope of potential damage should be assessed in order to determine if the Sub-CA, Repository
Service Provider, Timestamp Service Provider, or Registration Authority needs to be rebuilt,
only some certificates need to be revoked, and/or the Sub-CA, Repository Service Provider,
Timestamp Service Provider, or Registration Authority key needs to be declared compromised.
The Root CA should be notified if any of the following cases occur:

1. Suspected or detected compromise of a Sub-CA system;
2. Physical or electronic attempts to penetrate a Sub-CA system;
3. Denial of service attacks on a Sub-CA system;
4. Any incident preventing the Sub-CA from issuing a CRL within 24 hours of the time
specified in the next update field of its currently valid CRL. A Sub-CA shall reestablish
capability to issue CRL as quickly as possible.

5.7.2. Computing Resources, Software, and/or Data are corrupted
If Sub-CA equipment is damaged or rendered inoperative, but the Sub-CA signature keys are not
destroyed, Sub-CA operation shall be reestablished as quickly as possible, giving priority to the
ability to generate certificate status information. The integrity of the system shall be ensured at
all times as Sub-CA equipment/systems are restored to operation.
5.7.3. Entity Private Key Compromise Procedures
If a Sub-CA signature keys are compromised, lost, or suspected to be compromised:
1. The Root CA should be securely notified at the earliest feasible time so that the Sub-CA
certificate can be revoked;
2. A Sub-CA key pair should be generated by the Sub-CA in accordance with procedures set
forth in the applicable CPS;
3. New Sub-CA certificates should be requested in accordance with the initial registration
process set elsewhere in this CP;
4. If the Sub-CA can obtain accurate information on the certificates it has issued and that are
still valid (i.e., not expired or revoked), the Sub-CA may re-issue (i.e., renew) those
certificates with the not After date in the certificate as in original certificates; and
5. If the Sub-CA is the Root Certificate Authority, it should provide the Subscribers the new
trust anchor using secure means.
The Sub-CA should also investigate what caused the compromise or loss, and what measures
must be taken to preclude recurrence.
If a Repository Service Provider and Timestamp Service Provider keys are compromised, all
certificates issued to the Repository Service Provider and Timestamp Service Provider should be
revoked, if applicable. The Repository Service Provider and Timestamp Service Provider will
generate new key pairs and request new certificate(s), if applicable.
5.7.4. Business Continuity Capabilities after a Disaster
In the case of a disaster whereby the Sub-CA installation is physically damaged and all copies of
the Sub-CA signature key are destroyed as a result, the Root CA shall be securely notified as
soon as practical and take whatever action it deems appropriate. Relying Parties may decide of
their own volition whether to continue to use certificates signed with the destroyed private key

pending reestablishment of Sub-CA operation with new certificates.
5.8. Sub-CA and RA Termination
In the event of termination of a Sub-CA or RA, the entity should request all certificates issued to
it be revoked.
 A Sub-CA or RAshould archive all audit logs and other records prior to termination.
 A Sub-CA or RA should destroy all its private keys upon termination.
 Sub-CA or RA archived records should be transferred to an appropriate authority.

6. TECHNICAL SECURITY CONTROLS
6.1. Key Pair Generation and Installation
6.1.1. Key Pair Generation
Cryptographic keying material for certificates issued by the Sub-CA shall be generated in
FIPS140-1/2 validated cryptographic modules. For the Sub-CA, the modules shall meet or
exceed Security Level 3. The Sub-CAs must document their key generation procedure in their
CPSs, and generate auditable evidence that the documented procedures were followed. The
documentation of the procedure must be detailed enough to show that appropriate role separation
was used. The process shall be validated by an independent third party.
6.1.2. Private Key Delivery to Subscriber
The Sub-CA should generate their own key pair and therefore do not need private key delivery.
Sub-CA shall retain the copy of subscribers‟ encryption key or shall have key recovery system.
Sub-CA shall not retain or hold copy of private key used to sign digital signature.
6.1.3. Public Key Delivery to Certificate Issuer
Where key pairs are generated by the Subscriber, the public key and the Subscriber‟s identity
should be delivered securely to the Sub-CA for certificate issuance. The delivery mechanism
should bind the Subscriber‟s verified identity to the public key. If cryptography is used to
achieve this binding, it should be at least as strong as the Sub-CA keys used to sign the
certificate.
6.1.4. Sub-CA Public Key Delivery to Relying Parties
The public key of a trust anchor should be provided to the subscribers acting as relying parties in
a secure manner so that the trust anchor is not vulnerable to modification or substitution.
Acceptable methods for delivery of trust anchor include but are not limited to:
1. The Sub-CA loading a trust anchor onto tokens delivered to subscribers via secure
mechanisms;
2. Secure distribution of a trust anchor through secure out-of-band mechanisms;

3. Comparison of certificate hash (fingerprint) against trust anchor hash made available
via authenticated out-of-band sources (note that fingerprints or hashes posted in-band
along with the certificate are not acceptable as an authentication mechanism); or
4. Loading trust anchor from websites secured with a currently valid certificate of equal
or greater assurance level than the certificate being downloaded and the trust anchor
is not in the certification chain for the Web site certificate.
6.1.5. Key Sizes
• If the Root CA determines that the security of a particular algorithm may be

compromised, it may require the Sub-CAs to revoke the affected certificates.
• All Sub-CAs, Timestamp Service Providers, Repository Service Providers, Online
Certificate Status Protocol Responder (OCSP Responder), RA, and Code Signing
certificates should be 4096-bit RSA.
• All subscriber (human, SSL, and device) certificates and Transport Layer Security (TLS)
protocols should use the following algorithm suites.
Cryptographic Function Cryptographic Algorithm
Signature 4096-bit RSA
Hashing Secure Hash Algorithm (SHA-256)
6.1.6. Public Key Parameters Generation and Quality Checking
Public key parameters prescribed in the Digital Signature Standard (DSS) shall be generated in
accordance with FIPS 186-4.
Parameter quality checking (including primarily testing for prime numbers) shall be performed in
accordance with FIPS 186-4 or a more stringent test if specified by the Root CA.
6.1.7. Key Usage Purposes (as per X.509 v3 key usage field)
The Sub-CA and subscriber certificates include key usage extension fields to specify the purposes
for which the certificate may be used and also to technically limit the functionality of the
certificate when used with X.509v3compliant software. Reliance on key usage extension fields is
dependent on correct software implementations of the X.509 version 3 standard and is outside of

the control of the Ethiopian PKI.
Key usages are covered in Electronic Signature Proclamation No. 1017/2108.
6.2. Private Key Protection and Cryptographic Module Engineering Controls
All CAs must implement a combination of physical, logical, and procedural controls
to ensure the security protection and prevent the loss, damage, disclosure, modification or
unauthorized use of their private keys.
6.2.1. Cryptographic Module Standards and Controls
For key pair generation and Sub-CA private key storage, the Root CA uses hardware
cryptographic modules that are rated at Federal Information Processing Standard (FIPS) 140-2
Level 3.For the Sub-CAs key pair generation and private key storage use hardware cryptographic
modules that, at a minimum, are rated at FIPS 140-2 Level 3.Hardware tokens for key pair
generation and private key storage of end-user Subscribers shall, at a minimum, be rated at FIPS
140-2 Level 1.
6.2.2. Private Key (m out of n) Multi-Person Control
All the Sub-CAs must implement technical and procedural mechanisms that require the
participation of multiple trusted individuals to perform sensitive Sub-CA cryptographic
operations. A threshold number of Secret Shares (m) out of the total number of Secret Shares
created and distributed for a particular hardware cryptographic module (n) is required to activate
a Sub-CA private key stored on the module.
The threshold number of shares needed for key generation is 3 of 10 (where m=3 and n=10)
signing key activation is 3 of 10 and private key backup and restore is 3 of 10. Re-activation of
the backed-up Sub-CA private keys requires the same multi-person participation as when
performing other sensitive Sub-CA private key operations.
6.2.3. Private Key Escrow
Under no circumstances should the signature keys be escrowed by a third party.
The end entity private keys used solely for decryption should be escrowed prior to the generation
of the corresponding certificates.

6.2.4. Private Key Backup
The private keys of the Sub-CAs are stored in encrypted state and access is only by multi-person
control as specified in Section 6.2.2 (Private Key (m out of n) Multi-person Control) of this CP.
Backup copy of the Sub-CAs private keys are created for routine recovery and disaster recovery
purposes. The Sub-CAs private keys are copied to backup hardware cryptographic modules in
accordance with this CPS.
All the Sub-CAs do not store copies of subscriber private keys. Subscribers are solely responsible
for backup of their private keys. For the backup of subscriber private keys, subscribers may
choose to back up their keys to their hard drive.
6.2.5. Private Key Archival
When all the Sub-CAs key pairs reach the end of their validity period, such Sub-CAs key pairs
will be archived for a period of at least 10 years. Archived Sub-CAs key pairs will be securely
stored using offline media. Procedural controls will prevent archived Sub-CAs key pairs from
being returned to production use. Upon the end of the archive period, the archived Sub-CAs
private keys will be securely destroyed.
The Ethiopian PKI does not archive copies of subscriber signature private keys.
6.2.6. Private Key Transfer into or from a Cryptographic Module
All the Sub-CAs generate key pairs on the hardware cryptographic modules in which the keys
will be used. In addition, copies of such Sub-CAs key pairs for routine recovery and disaster
recovery purposes are made. Where Sub-CAs key pairs are backed up to another hardware
cryptographic module, such key pairs are transported between modules in encrypted form.
6.2.7. Private Key Storage on Cryptographic Module
The cryptographic module may store Private Keys in any form as long as the keys are not
accessible without authentication mechanism that is in compliance with FIPS 140-2 rating of the
cryptographic module.
6.2.8. Method of Activating Private Key
The user must be authenticated to the cryptographic module before the activation of any private
key(s). Acceptable means of authentication include but are not limited to pass-phrases, Personal

Identification Numbers (PINs) or biometrics. Entry of activation data should be protected from
disclosure (i.e., the data should not be displayed while it is entered).
6.2.9. Methods of Deactivating Private Key
The Sub-CAs private keys are deactivated upon stopping of the Sub-CA system software. The
RA private keys (used for authentication to the RA application) are deactivated upon system log
off. RAs are required to log off their workstations when leaving their work area. A and end-user
Subscriber private keys may be deactivated after each operation, upon logging off their system or
upon removal of hardware token or software token depending upon the authentication
mechanism employed by the user. In all cases, end-user subscribers have an obligation to
adequately protect their private keys in accordance with this CP.
6.2.10. Method of Destroying Private Key
The HSM device and associated backup are “zerotized” or re-initialized according to the
specifications of the hardware manufacturer. This overwrites all of the data on the device. In
cases when this zeroization procedure fails, the Ethiopian PKI will physically destroy the device
to remove the ability to extract any private key.
6.2.10.1. Cryptographic Module Rating
See Section 6.2.1.

6.3. Other Aspects of Key Management
6.3.1. Public Key Archival
All CA‟s and subscribers‟ public keys are archived as part of the certificate archival.
6.3.2. Certificate Operational Periods and Key Pair Usage Periods
See Section 5.6.

6.4. Activation Data
6.4.1. Activation Data Generation and Installation
The Ethiopian PKI activates the cryptographic module containing its Sub-CAs‟ private keys
according to the specifications of the hardware manufacturer and the Key Ceremony Script. This

method has been evaluated as meeting the requirements of FIPS 140-2 Level 3. It can only be
activated through the use of HSM smart cards (3 of 10) accomplished by strong passwords. All
smart cards are stored in a safe when not in use. The cryptographic hardware is held under three-
person control as explained in Section 5.2.2 (Number of persons Required per Task) and
elsewhere in this CP.
All Ethiopian PKI personnel are required to use strong passwords and to protect PINs and
passwords. The Ethiopian PKI requires that passwords to workstations be changed on a regular
basis.
6.4.2. Activation Data Protection
Activation data for HSM devices are protected as described in Section 6.2.2 (Private Key (n out
of m) Multi-Person Control). Sub-CA and RA are required to store their administrator private
keys in encrypted form using hardware token with strong password protection. The Ethiopian
PKI recommends that subscribers store their private keys in encrypted form and protect their
private keys through the use of a hardware token and/or strong passphrase.
6.4.3. Other Aspects of Activation Data
Sub-CAs, Repository Service Providers, and Timestamp Service Providers should change the
activation data whenever the token is re-keyed or returned from maintenance.
6.5. Computer Security Controls
All computers able to access the Sub-CA environment shall be protected by a combination of
operating system, software and physical safeguards. All RAs that are accredited should comply
with all the rules and guidelines stated in the accreditation.
6.5.1. Specific Computer Security Technical Requirements
The Ethiopian PKI ensures that the systems maintaining the Sub-CA software and data files are
secure from unauthorized access. All computers that are part of the Sub-CA system shall be
configured and hardened using industry best practices. All operating systems shall require
identification and authentication for authenticated logins. It shall provide discretionary access
control, access control restrictions to services based on authenticated identity, security audit
capability and a protected audit record for shared resources, self-protection, and process

isolation.
The Sub-CAs production network is logically separated from other components. This separation
prevents network access except through defined application processes. The Ethiopian PKI uses
firewalls to protect the production network from external intrusion and limit the nature and
source of network activities that may access production systems.
Direct access to the Sub-CA databases supporting the Sub-CA operation is limited to the
database administrator duly authorized for such access.
6.5.2. Computer Security Rating
No Stipulation.
6.6. Life-Cycle Technical Controls
6.6.1. System Development Controls
The System Development Controls for the Sub-CA, Repository Service Provider, and Timestamp
Service Provider are as follows:
1. The Sub-CA shall use software that has been designed and developed under a
development methodology
2. The Sub-CA shall use COTS Sub-CA software that meets FIPS requirements.
3. Hardware and software procured should be purchased in accordance with Critical

Mass Cyber Security Requirement Standard v1.0 Procurement, Development and
Maintenance process.
4. All hardware must be shipped or delivered via controlled methods that provide a
continuous chain of accountability, from the purchase location to the operations
location
5. The hardware and software should be dedicated to performing the PKI activities.
There should be no other applications; hardware devices, network connections, or
component software installed which are not parts of the PKI operation.
6. Proper care should be taken to prevent malicious software from being loaded onto the
equipment. Only applications required to perform the PKI operations should be
obtained from sources authorized by local policy.

7. Sub-CA, Repository Service Provider, and Timestamp Service Provider hardware and
software should be scanned for malicious code on first use and periodically thereafter.
6.6.2. Security Management Controls
The configuration of the CA, Repository Service Provider, and Timestamp Service Provider
system as well as any modifications and upgrades should be documented and controlled. There
should be a mechanism for detecting unauthorized modification to the CA, Repository Service
Provider, and Timestamp Service Provider software or configuration. A formal configuration
management methodology should be used for installation and ongoing maintenance of the CA
system. The CA, Repository Service Provider, and Timestamp Service Provider software, when
first loaded, should be verified as being that supplied from the vendor, with no modifications,
and be the version intended for use.
6.6.3. Life Cycle Security Controls
No stipulation.
6.7. Network Security Controls
The Ethiopian PKI system is protected by firewalls. The Root CA is offline and not reachable
from the network. Firewalls and boundary control devices are configured to allow access only by
the addresses, port, protocols and commands required for the provision of PKI services by such
systems.
The Sub-CA equipment is configured with minimum number of services and all unused network
ports and services are disabled. All firewall configuration changes are documented, authorized,
tested and implemented in accordance with change management policies and procedures.
Network configuration is available for review by its auditors and consultants under an
appropriate non-disclosure agreement.
6.8. Time-Stamping
All Sub-CA, Repository Service Provider, and Timestamp Service Provider components shall
regularly synchronize with a reliable time service. Time derived from the time service shall be
used for establishing the time of:

• Initial validity time of a Subscriber‟s Certificate
• Issuance of Subscriber Certificates
• Revocation of a Subscriber‟s Certificate
• Posting of CRL updates
• OCSP responses
Asserted times shall be accurate to within three minutes. Electronic or manual procedures may be
used to maintain system time. Clock adjustments are auditable events as listed in Section
5.4.1.

7. CERTIFICATE, CRL AND OCSP PROFILES
7.1. Certificate Profile
The CPS related to this CP defined in detail the actual format of certificates issued by the CA.
Certificates issued by the CA shall conform to the Ethiopian PKI X.509 Certificate and CRL
Extensions Profile as well as the Electronic Signature Proclamation No. 1072/2018.
7.1.1. Version Number(s)
All CAs Certificates are X.509 version 3 certificates.
7.1.2. Certificate Extensions
X.509 v3 extensions are supported and used as indicated in the Certificates profiles as described
in the present document.
7.1.3. Algorithm Object Identifiers
Algorithms OID are conforming to IETF RFC 3279 and RFC 5280.
7.1.4. Name Forms
Name forms are in the X.500 distinguished name form as implemented in RFC 3739.
7.1.5. Name Constraints
CAs are technically unconstrained and are subject for full audit as specified in Section 8 of this
CP.
7.1.6. Certificate Policy Object Identifier
Certificate policy object identifiers are used as per RFC 3739. The OIDs used by CAs are listed
in Section 1.2.
7.1.7. Usage of Policy Constraints Extension
Usage of Policy Constraints extension is supported as per RFC 5280. CAs follow Section 7.1.6

of CA/B Forum Baseline Requirements.
7.1.8. Policy Qualifiers Syntax and Semantics
No stipulation.
7.1.9. Processing Semantics for the Critical Certificate Policies Extension
No stipulation.
7.2. CRL Profile
7.2.1. Version numbers
The CAs and its subordinates issue X.509 Version 2 CRLs in accordance with IETF PKIX RFC
5280.
7.2.2. CRL and CRL entry extensions
The CAs and Subscriber Certificates include the CRLDistributionPoints extension containing the
URL of the location where a Relying Party can obtain a CRL to check the CAs‟ Certificates
statuses.
7.3. OCSP Profile
OCSP (Online Certificate Status Protocol) is a way to obtain timely information about the
revocation status of a particular certificate. The Sub-CA‟s OCSP functionality is built according
to RFC 6960.
The Sub-CA provides uninterrupted on-line certificate status protocol OCSP support which is a
real time certificate status inquiry. By this service, when appropriate certificate status inquiries
are received, the status of certificates and additional information as required by the protocol are
returned to the inquirer as the response.
The Ethiopian PKI operates an OCSP service at http://govsubca.epki.gov.et/ocsp. To get the

minimum requirements of what an OCSP Request Format and OCSP Response Format profile
look like, see Appendix C. The Ethiopian PKI OCSP Request and Response Formats conform to
RFC 2560.
7.3.1. Version Number

The OCSP service provided by Sub-CA supports the v1 protocol version under the “IETF RFC
6960 Internet X.509 Public Key Infrastructure Online Certificate Status Protocol - OCSP”
document.
7.3.2. OCSP Extension
Sub-CA‟s OCSP profile description is available as in the naming and profile (published in
repository http://govsubca.epki.gov.et /repository)

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
At a minimum, yearly audits shall be conducted by an auditing firm, referred to as “auditor”

selected by INSA. The auditor audits the operations of CAs against this CP and related CPSs.
8.1. Frequency or Circumstances of Assessments
An annual audit is performed by an independent external auditor to assess CAs’ compliance with
standards set forth by the CA/Browser Forum.
More than one compliance audit per year is possible if this is requested by the audited party or is
a result of unsatisfactory results of a previous audit. Material exceptions or deficiencies
identified during an audit will result in a determination of actions to be taken. This determination
is made by the independent auditor with input from the CA. The CA is responsible for
developing and implementing a corrective action plan.
8.2. Identity/ Qualifications of Assessor
The audit requirement shall be performed by a qualified independent assessment team organized
by INSA comprising, but not limited to, the following:
a) Certified Public Accountants; and
b) Certified Information Security practitioners.
All shall possess sufficient knowledge on digital signatures, digital certificates, Internet X.509
version 3 PKI Certificate Policy, Certification Practices Framework, the Electronic Signature
Proclamation No. 1072/2018, the Computer Crime Offence Proclamation, the Telecom Fraud
Proclamation, the National Information Security Policy among others.
Compliance audit is performed by a Qualified Auditor. A Qualified Auditor means a natural

person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the
following qualifications and skills:

a) Independence from the subject of the audit;
b) Has proficiency in security auditing, information security tools and techniques,
c) PKI technology and third-party attestation functions;

d) Holds particular skill sets, competency testing, quality assurance measures like peer
review, standards with respect to proper assignment of staff to engagements and
requirements for continuing professional education.
e) accredited in accordance with ISO17065 applying the requirements specified in ETSI EN
319 403; and
f) Bound by law, government regulation, or professional code of ethics;
8.3. Assessor‟s Relationship to Assessed Entity
Any member of the assessment team and the firms or companies the member is affiliated with
shall have no conflict of interest with the Ethiopian PKI CA being assessed and shall not be a
software or hardware vendor that is or has been providing services or supplying equipment to the
Ethiopian PKI CA within the last two (2) years.
8.4. Topics Covered by Assessment
The compliance audit verifies that the operational and technical controls used by the CA
operations personnel, including all RA and any other PKI or entity satisfy all requirements of
this CP including all the following topics:
• Identification & Authentication
• Certificate Life-Cycle Operational Requirements
• Facility, Management, and Operational Controls
• Technical Security Controls
• Certificate, CRL and OCSP Profiles
• CPS Administration

8.5. Actions Taken as a Result of Deficiency
When the compliance auditor finds a discrepancy between how the CA is designed or is operated
or maintained, as compared to the requirements of this CP and/or applicable CPS, the following
actions shall be performed:
• the compliance auditor shall document the discrepancy;
• the compliance auditor shall notify INSA;

• INSA shall promptly determine what further actions are necessary to meet the
requirements of this CP. INSA shall make any such required notifications and take such
actions without delay.
Relevant to bullet item #3 above, there are three possible additional actions to take when a
deficiency has been identified by the compliance auditor:
• Continue to operate as usual
• Continue to operate but at a lower assurance level
• Suspend operation
If a deficiency is identified, INSA will determine which of the following actions to take.
• If continuing operation, as usual or lower assurance level, INSA is responsible for

ensuring that corrective actions are taken within 30 days. At that time, or earlier if agreed
by INSA and Compliance Auditor, the compliance audit team will re-audit the CA in the
areas of deficiencies. If, upon re-audit, corrective actions have not been taken, INSA will
determine if more severe action is required.
• If operation is suspended, INSA is responsible for reporting the status of corrective action
to the Compliance Auditors on a weekly basis. INSA and Compliance Auditor together
will determine when re-audit is to occur. If the deficiencies are deemed to have been
corrected upon re-audit, the CA will resume service.
8.6. Communications of Results
The compliance auditor will communicate results of all compliance audits to INSA through a
Compliance Audit Report letter. This report letter shall document the versions of the CP and

CPS used in the compliance audit. Additionally, where necessary, the results of the compliance
audit shall be communicated by the INSA as described in Section 8.5 above.
A special compliance audit shall be conducted if it is required to confirm the implementation and
effectiveness of the remedy to any deficiencies documented by the compliance auditor. INSA
can determine that such a special compliance audit is required to verify implementation and
effectiveness of the remedy.

9. OTHER BUSINESS AND LEGAL MATTERS
9.1. Fees
Any person who wants to engage as certificate provider may lodge application to the Root CA
for the issuance of license by filling the form prescribed by the Root CA and pay a prescribed
license fee. The Sub-CA shall submit an application for a replacement license accompanied by
all documents as may be required by the Root CA together with the prescribed fee.
9.1.1. Certificate Issuance and Renewal Fees
Any certificate provider that submits an application for issuance or renewal of license in
accordance with the Electronic Signature Proclamation No. 1072/2018 shall provide necessary
documents as may be required and pay prescribed fee upon approval of the application.
9.1.2. Certificate Access Fees
Sub-CAs may not charge for access to

any certificates.
9.1.3. Revocation Status Information Access Fees
Sub-CAs may not charge for access to any revocation status

information.
9.1.4. Fees for Other Services
CAs may set any reasonable fees for any other services such as access to archive records or key
recovery.
9.1.5. Refund Policy
Sub-CAs may, but are not required to, have a documented refund process.
9.2. Financial Responsibility
9.2.1. Insurance Coverage
CAs shall also maintain reasonable levels of insurance coverage to address all foreseeable
liability obligations to PKI Participants described in Section 1.2 of this CP.
9.2.2. Other Assets

CAs shall maintain reasonable and sufficient financial resources to maintain operations, fulfill
duties, and address commercially reasonable liability obligations to PKI Participants described in
Section 1.2 of this CP.
9.2.3. Insurance or Warranty Coverage for End-Entities
Sub-CAs may, but are not required, to offer protection to end entities that extends beyond the
protections provided in this CP. Any such protection shall be offered at commercially reasonable
rates.
9.3. Confidentiality of Business Information
CAs information not requiring protection may be made publicly available, subject to the
stipulations of this CP and other applicable laws.
9.3.1. Scope of Confidential Information
Each Subscriber‟s private signing key is confidential to that Subscriber. The Sub-CA and RA are
not provided any access to those keys. Information held in audit logs and the archives is
considered confidential to the Sub-CAs and is not released to external parties, unless required by
law. Personal information held by the RA, other than that which is explicitly published as part of
a certificate, CRL, this CP or the CPS is considered confidential to the Ethiopian PKI and is not
released unless required by law. Information stored on the RA workstation or Sub-CAs server is
protected by password. The RA keeps paper information (e.g., registration forms) in a locked
container when the RA is not present.
9.3.2. Information not within the Scope of Confidential Information
Subscriber application data being published in a digital certificate is

considered public and not within the scope of confidential information. Certificate revocation
and other status information are not considered confidential/private information. This section is
subject to applicable privacy laws.
9.3.3. Responsibility to Protect Confidential Information
The Root CA shall have responsibility to ensure that controls exist to protect the confidential
information in section 9.3.1.

9.4. Privacy of Personal Information
CAs information not requiring protection may be made publicly available, subject to the
stipulations of this CP and other applicable laws.
9.4.1. Privacy Plan
All Ethiopian CAs and/or RAs have Privacy Plans that will always protect personally identifying
information from unauthorized disclosure.
9.4.2. Information Treated as Private
Any information about subscribers that is not publicly available through the content of the issued
certificate and online CRLs is treated as private.
9.4.3. Information Not Deemed Private
Information appearing in the certificate and CRL is

not considered private.
9.4.4. Responsibility to Protect Private Information
All Ethiopian CAs and RAs shall secure all private information they receive from compromise
and disclosure to unauthorized parties and shall comply with applicable laws in line with data
privacy.
9.4.5. Notice and Consent to Use Private Information
There are no requirements for the CA to provide notice or obtain consent to use the information
provided by Subscribers and applicants for certificates.
9.4.6. Disclosure Pursuant to Judicial or Administrative Process
An Ethiopian CA or RA shall not disclose any private information to

any third party unless authorized by this CP, required by law or a court order. Any request for
release of information shall be processed according to an established procedure.
9.4.7. Other Information Disclosure Circumstances
No stipulation.
9.5. Intellectual Property Rights

The intellectual property rights held by individuals, organizations, or entities shall always be
upheld by all Ethiopian CAs or RAs operating under this CP.
9.5.1. Property Rights in Certificates and Revocation Information
CAs may claim all Intellectual Property Rights in and to the

Certificates and revocation information that they issue. However, they must grant permission to
reproduce and distribute Certificates and revocation information on a nonexclusive royalty-free
basis, provided that the recipient agrees to distribute them at no cost.
9.5.2. Property Rights in the CPS
All Intellectual Property Rights in this CP are owned by INSA. All Intellectual Property Rights
in any CPS of a Sub-CA may be claimed by that Sub-CA.
9.5.3. Property Rights in Names
The Certificate Applicant may claim all rights, if any, in any trademark, service mark, or trade
name of the Certificate Applicant contained in any Application.
9.5.4. Property Rights in Keys
Sub-CAs may claim property rights to the keys they use (e.g., Sub-CA key pair, OCSP
Responder key pair, time-stamp service provider key pair, repository service provider key pair,
etc.) Subject to any agreements between a Sub-CA and its customers, ownership of and property
rights in key pairs corresponding to Certificates of Subscribers shall be specified in the
applicable CPS.
9.6. Representations and Warranties
9.6.1. CAs Representations and Warranties
The CA shall make certificates and CRLs available in a repository for subscribers, PKI
administrators and Relying Parties use. The CA does not disclaim any responsibilities required
under this CP. The CA may use a variety of mechanisms for posting information into a
repository as required by this CP. These mechanisms at a minimum shall include:
• All CAs certificates and CRLs shall be placed into a X.500 Directory Server System that
is publicly accessible through the Lightweight Directory Access Protocol (LDAP);
• All CAs‟ certificates and CRLs shall also be available and publicly accessible via the

Hyper Text Transport Protocol (HTTP);
• The CA may optionally publish subscriber certificates into the publicly accessible X.500
Directory Server System that is publicly accessible through LDAP protocol
• Availability of the information as required by the certificate information posting and
retrieval stipulations of this CP;
• Access control mechanisms when needed to protect repository information from
unauthorized modification or deletion;
• There shall be redundant directory systems (a total of 3 directory systems for triple
redundancy) at the primary operational site and in addition, redundant directory systems
at the off-site backup operational site (a total of 3 directory systems for triple redundancy
at the off-site backup location) so that the CA can achieve the Common Policy directory
availability requirements;
• The publicly accessible directory systems and LDAP and HTTP access mechanisms shall
be operated and maintained to comply with this CP requirements for overall availability,
and the scheduled downtime for these systems will be limited to ensure that this CP
requirements are met at all times;
• The schedule downtime requirements in this CP are met by tracking all scheduled
downtime in the PKI Change Control Records and ensuring that one of the redundant
systems is always planned to be online and active, to avoid any downtime while other
redundant systems might undergo scheduled maintenance or problem resolution.
9.6.2. RA Representations and Warranties
The RA will abide by all obligations and all stipulations defined in this CP. The RA shall ensure
that the cryptographic module shall not left unattended once the private key is activated, in order
to ensure that unauthorized access to the private key does not occur. RA‟s shall conform to the
stipulations of this CP including:
• Maintaining RA operations in conformance with this CP;
• Including only valid and appropriate information in certificate requests, and maintaining
evidence that due diligence was exercised in validating the information contained in the
certificate;

• Ensuring that obligations are imposed on Subscribers via the Subscriber Agreement, and
that Subscribers are informed of the consequences of not complying with the obligations
contained in the Subscriber Agreement and this CP (by informing Subscribers that their
certificate can be revoked for non-compliance with the Subscriber Agreement and this
CP).
RA‟s that are found to have acted in a manner inconsistent with these obligations in this CP shall
be subject to revocation of RA responsibilities.
9.6.3. Subscriber Representations and Warranties
A Subscriber shall be required to sign a document (e.g., a subscriber agreement) containing the
requirements the Subscriber shall meet respecting protection of the private key and use of the
certificate before being issued the certificate.
In signing the document described above, each Subscriber shall agree to the following:
1. Subscriber shall accurately represent itself in all communications with the PKI
authorities.
2. The data contained in any certificates issued to Subscriber is accurate.
3. The Subscriber shall protect its private keys at all times, in accordance with this policy,
as stipulated in their certificate acceptance agreements, and local procedures.
4. The Subscriber lawfully holds the private key corresponding to public key identified in
the Subscriber‟s certificate.
5. The Subscriber will abide by all the terms, conditions, and restrictions levied on the use
of their private keys and certificates.
6. Subscriber shall promptly notify the appropriate CA upon suspicion of loss or
compromise of their private keys. Such notification shall be made directly or indirectly
through mechanisms consistent with the CA‟s.
9.6.4. Relying Party Representations and Warranties
Parties who rely upon the certificates issued under a policy defined in this document shall:
1. Use the certificate for the purpose for which it was issued, as indicated in the certificate
information (e.g., the key usage extension);

2. Check each certificate for validity, using procedures described in RFC 5280, prior to
reliance;
3. Preserve original signed data, the applications necessary to read and process that data,
and the cryptographic applications needed to verify the digital signatures on that data for
as long as it may be necessary to verify the signature on that data. Note: data format
changes associated with application upgrades will often invalidate digital signatures and
shall be avoided.
9.6.5. Representations and Warranties of Other Participants
9.6.5.1. Time Stamp Service Provider Representations and Warranties
Parties that want to provide time stamp service shall:

1. Abide by the stipulations of this CP;
2. Comply with the provisions of the Electronic Signature Regulations;
3. Strictly follow all the detailed standards and requirements given by INSA;
9.6.5.2. Repository Service Provider Representations and Warranties
Parties that want to provide repository service shall:

1. Use secured systems and resources to give the service;
2. give prior information concerning modifications to be made hardware or software

resources;
3. make the archived data easily accessible to subscribers and relying parties;
4. Strictly abide by the laws and regulations released in relation to what they do;
9.7. Disclaimers of Warranties
To the extent permitted by applicable law and any other related agreements, CAs may disclaim
all warranties (other than any express warranties contained in such agreements or set forth in the
CA‟s).
9.8. Limitations of Liabilities
A Sub-CA or RA shall not be liable for any damages to subscribers, relying parties or any other

parties arising out of or related to the misuse of, or reliance on certificate issued by a Sub-CA
that has been:
a. Revoked;
b. Expired;
c. Used for unauthorized purposes (for purposes not specified in the Electronic Signature
Proclamation No. 1072/2018);
d. Tampered with;
e. Compromised; or
f. Subject to misrepresentation, misleading acts or omissions.
9.9. Indemnities
Subscribers and relying parties shall agree to indemnify and hold a CA or RA free from any
claims, actions or demands that are caused by the use or publication of a certificate and that
arises from:
a. Any false or misleading statement of fact by the subscriber;
b. Any failure by the subscriber to disclose a material fact, if such omission was made
negligibly or with the intent to deceive;
c. Any failure on the part of the subscriber to protect its private key and/or token if
applicable or to take the precautions necessary to prevent the compromise, disclosure,
loss, modifications or unauthorized use of the subscriber‟s private key; or
d. Any failure on the part of the subscribe to promptly notify the CA or RA of the
compromise, disclosure, loss, modification or unauthorized use of the subscriber‟s
private key once the subscriber has actual or constructive notice of such event.
9.10. Term and Termination
9.10.1. Term
This CP becomes effective upon ratification by INSA. Amendments to this CP become effective
upon ratification by INSA and publication at http://www.insa.gov.et

9.10.2. Termination
This CPS shall remain in force until it is amended or replaced by a new version.
9.10.3. Effect of Termination and Survival
Upon termination of this CP, CAs are bound by its terms for all certificates issued for the
remainder of the validity periods of such certificates.
9.11. Individual Notices and Communications with Participants
The Root CA, Sub-CAs, Subscribers, Relying Parties and other participants will use
commercially reasonable methods to communicate with each other.
9.12. Amendments
9.12.1. Procedure for Amendment
INSA shall review this at least once every year. Additional reviews may be made at any time at
the discretion of INSA. INSA can recommend amendments or corrections to this CP; such
modifications shall be circulated to the CAs. Comments from the CAs shall be collected and
adjudicated by INSA. INSA shall use commercially reasonable efforts to immediately notify
CAs of changes.
9.12.2. Notification Mechanism and Period
Errors and anticipated changes to this CP resulting from reviews are published online at
http://www.insa.gov.et. The most up to date copy of the CP can be found at http://www.gov.et.
This CP and any subsequent changes shall be made publicly available within seven days of
approval.
9.12.3. Circumstances under Which OID Must be changed
If INSA determines that a change is necessary in the OID corresponding to a Certificate policy,
the amendment shall contain new OIDs for the CPs corresponding to each such Certificate.
Otherwise, amendments shall not require a change in CP OID.
9.13. Dispute Resolution Provisions
Parties are required to notify the Root CA and attempt to resolve disputes directly with the Root

CA before resorting to any dispute resolution mechanism, including adjudication or any type of
alternative dispute resolution.
9.14. Governing Law
The terms and provisions of this CP shall be interpreted under and governed by applicable
Federal laws of Ethiopia.
9.15. Compliance with Applicable Law
This CP is subject to any applicable laws of

Ethiopia.
9.16. Miscellaneous Provisions
9.16.1. Entire Agreement
This CP and/or the related CPS and the applicable Subscriber Terms and Conditions represent
the entire agreement between any Subscriber or Relying Party and INSA and shall supersede any
and all prior understandings and representations pertaining to its subject matter. In the event,
however, of a conflict between this CP and/or the related CPS and any other express agreement
between a Subscriber or Relying Party with the Root CA with respect to a Certificate, including
but not limited to a Subscriber Terms and Conditions, such other agreement shall take
precedence.
9.16.2. Assignment
Entities operating under this CP and/or the related CPSs cannot assign their rights or obligations
without the prior written consent of the Root CA.
9.16.3. Severability
If any provision of this CP and/or the related CPS, including limitation of liability clauses, is
found to be invalid or unenforceable, the remainder of this CP and/or the related CPS will be
interpreted in such a way as to realize the original intention of the parties. Each and every
provision of this CP and/or the related CPS that provides for a limitation of liability is intended
to be severable and independent of any other provision and is to be enforced as such.

9.16.4. Enforcement (Attorney‟s Fees and Waiver of Rights)
The waiver or failure to exercise any right provided for in this CP and/or in the related CPS shall
not be deemed a waiver of any further or future right under this CP and/or the related CPS.
9.16.5. Force Majeure
The Ethiopian PKI accepts no liability for any breach of warranty, delay or failure in
performance that results from events beyond its control such as, but not limited to, the following:
a) Acts of God;
a. Acts of War;
b. Acts of Terrorism;
c. Epidemics;
d. Power or telecommunication services failure;
e. Earthquake;
f. Flood;
g. Fire; or
h. Any other natural or man-made disasters.
9.17. Other Provisions
No stipulation.

Appendix A: Certificate Profile
A.1 Root CA Certificate Profile
Mandatory/ Critical/ Note

Field
Optional Non critical
Version Version 3
Serial Number Minimum 8 Bytes , Maximum 20 Bytes
Issuer Signature Algorithm SHA256WithRSA
Issuer Distinguished Name CN= National Root CA ,O=INSA, ST=Name of State , C=ET
Validity Period Generalized Time (20 years)
Subject Distinguished Name CN= National Root CA ,O=INSA , ST=Name of State, C=ET
Subject Public Key Information RSA 4096
X.509 V3 extensions
Authority Key Identifier Mandatory Non critical Issuing CA Subject Key Identifier
Subject Key Identifier Mandatory Non critical Subject Key Identifier
Key usage Mandatory Critical keyCertSign, cRLSign
Basic Constraints Mandatory Critical Subject Type=CA ,Path Length Constraint=None
A.2 Sub-CA Certificate Profile

Field
Version Version 3
Serial Number Minimum 8 Bytes, Maximum 20 Bytes
Issuer Distinguished Name CN= National Root CA, O=INSA, ST=Name of State, C=ET
Validity Period Generalized Time (20 years)

Subject Distinguished Name CN= Certificate Provider Name, O=Organization Name,
OU=Organizational Unit Name, ST=Name of State, C=ET
X.509 V3 extensions
Key usage Mandatory Critical keyCertSign, cRLSign
Certificate Policies Mandatory Non critical Policy OID, Policy Qualifier
Basic Constraints Mandatory Critical Subject Type=true, Path Length Constraint=0
CRL Distributions Points Mandatory Non critical URL pointing to CRL Distribution
Authority Information Access Mandatory Non critical URL pointing to CA Issuer Certificate

A.3 End User Signature Certificate Profile (Personal Use)
Field
Version Version 3
CN= Certificate Provider Name, O=Organization Name,
Issuer Distinguished Name
Validity Period Generalized Time (2 Years)
CN=FirstName MiddleName LastName,
NID= [This attribute should be populated with the
Subject Distinguished Name SHA256 hash of National ID], O=Personal,
ST=Name of State,
C=ET

X.509 V3 extensions
Key usage Mandatory Critical digitalSignature, nonrepudiation
Certificate policies Mandatory Non critical Policy OID, Policy Qualifier
Subject Alternative Name Optional Non critical E=username@domain.com
Basic Constraints Optional Non critical Subject Type=End Entity Path Length Constraint=None
Extended Key Usage Optional Non critical emailProtection
CRL Distribution Points Mandatory Non critical URL pointing to CRL Distribution
Authority Information Access Mandatory Non critical OCSP locator URL, URL pointing to CA Issuer Certificate
A.4 End User Encryption Certificate Profile (Personal Use)

Field
Version Version 3
CN= Certificate Provider Name, O=Organization,
CN=FirstName MiddleName LastName,
NID= [This attribute should be populated with the
Subject Distinguished Name SHA256 hash of National ID], O=Personal, ST=Name of
State,
C=ET

X.509 V3 extensions

Key usage Mandatory Critical Keyencipherment; dataencipherment
A.5 End User Signature Certificate Profile (Organizational Use)
Mandatory/ Critical/
Field Note
Version Version 3
CN=FirstName MiddleName LastName
NID= [This attribute should be populated with the SHA256
hash of National ID]
OID= [This attribute should be populated with the
Subject Distinguished Name SHA256 hash of Organizational ID] O= Organization
Name,
O= Organizational Unit,
ST=Name of State
C=ET
X.509 V3 extensions
Mandatory Non critical Issuing CA Subject Key Identifier
Authority Key Identifier
Key usage Mandatory Critical Keyencipherment; dataencipherment
A.6 End User Encryption Certificate Profile (Organizational Use)

Field Note
Version Version 3


CN=FirstName MiddleName LastName
NID= [This attribute should be populated with the SHA256 hash
of National ID]
OID= [This attribute should be populated with the SHA256
Subject Distinguished Name hash of Organizational ID] O= Organization Name
O= Organizational Unit Name
ST=Name of State
C=ET

X.509 V3 extensions
Key usage Mandatory Critical digitalSignature, nonrepudiation
Subject Alternative Name Optional Non critical E=username@organization_domain.com
OCSP locator URL,
Authority Information Access Mandatory Non critical
URL pointing to CA Issuer Certificate
A.7 SSL Certificate Profile
Field Note
Version Version 3
OU=Organizational Unit, ST=Name of State, C=ET
CN=Fully Qualified Domain Name (FQDN)
OU=Organization Unit Name
Subject Distinguished Name O=Organization Name
ST=Name of State
C=ET
X.509 V3 extensions
Key usage Mandatory Critical digitalSignature, keyEncipherment
Subject Alternative Name Optional Non critical dnsName(s) for server, IP address of the server
Extended Key Usage Mandatory Critical serverAuth, clientAuth

A.8 System Certificate Profile
Field Note
Version Version 3
Subject Distinguished Name CN=unique identifier
X.509 V3 extensions
Key usage Mandatory Critical digitalSignature, keyEncipherment,dataEncipherment
Basic Constraints Optional Non critical Subject Type=End Entity, Path Length Constraint=None
Extended Key Usage Optional Non critical serverAuth, clientAuth
A.9 Time Stamping Authority (TSA) Certificate Profile

Field Note
Version Version 3
Validity Period Generalized Time (Maximum 10 Years)
CN= Time Stamping Authority Name
ST=Name of State
C=ET
X.509 V3 extensions
Key usage Mandatory Critical digitalSignature
Extended Key Usage Mandatory Critical timestamping

A.10 Code Signing Certificate Profile
Field Note
Version Version 3

CN= “Organization Name” or “FirstName MiddleName
LastName”
Subject Distinguished Name
ST=Name of State
C=ET
X.509 V3 extensions
Basic Constraints Optional Non critical Subject Type=End Entity, Path Length Constraint=None
Extended Key Usage Mandatory Non critical codeSigning
A.11 OCSP Responder Certificate Profile

Field Note
Version Version 3
CN= OCSP Responder Name
ST=Name of State
C=ET
X.509 V3 extensions
Basic Constraints Optional Non critical Subject Type=End Entity,Path Length Constraint=None

Extended Key Usage Mandatory Critical OCSPSigning
Mandatory Non critical This extension tells a client that it is not necessary to check
OCSP No Check
the certificate status of this certificate.
A.12 Document Signer Certificate Profile (Organizational Use)

Field Note
Version Version 3
Critical/
Field Non Note
critical
CN= Document Signer Name
ST=Name of State
C=ET
X.509 V3 extensions
Key usage Mandatory Critical digitalSignature,nonRepudiation
Basic Constraints Optional Non critical Subject Type=End Entity,Path Length Constraint=None
Extended Key Usage Optional Non critical MSFT Document Signer, Adobe Document Signer
Appendix B: CRL Profile

B.1 Root CA CRL Profile
Critical/
Field Non Note
critical
Version Version 2
Issuer Distinguished Name CN= National Root CA, O=INSA, ST=Name of State, C=ET
thisUpdate Generalized Time
nextUpdate Generalized Time
Revoked certificates list

CRL extensions
CRL Number Non critical
Authority Key Identifier Non critical
Reason Code Non critical
B.2 Sub-CA CRL Profile

Version Version 2
Issuer Distinguished Name CN= Certificate Provider Name, O=Organization, OU=Organizational
Unit, ST=Name of State, C=ET
thisUpdate Generalized Time
nextUpdate Generalized Time
Revoked certificates list
CRL extensions
CRL Number Non critical
Authority Key Identifier Non critical
Reason Code Non critical
Appendix C: OCSP Request & Respond Format

C.1 OCSP Request
Field Note
Version V1 (0)
Requester Name DN of the requestor (required)
Request List List of certificates as specified in RFC 2560
Request Extension Value
None None
Request Entry Extension Value
None None
C.2 OCSP Respond

Field Value
Response Status As specified in RFC 2560
Response Type id-pkix-ocsp-basic {1 3 6 1 5 5 7 48 1 1}
Version V1 (0)
Responder ID Octet String (same as subject key identifier in Responder certificate)
Produced At Generalized Time

List of Responses Each response will contain certificate id; certificate status1, thisUpdate,
nextUpdate2,
Responder Signature sha256 With RSA Encryption {1 2 840 113549 1 1 11}

Certificates Applicable certificates issued to the OCSP Responder
Response Extension Value
Nonce c=no; Value in the nonce field of request (required, if present in request)
Response Entry Extension Value
None None

Ethiopian PKI X.509 Certificate Policy Overview

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ethiopian PKI X.509 Certificate Policy Overview

Uploaded by

Copyright:

Available Formats

Ethiopian PKI X.

509 Certificate Policy

Ethiopian PKI X.509 Certificate Policy

Draft Version 1.0

INFORMATION NETWORK SECURITY AGENCY

2.2. Time or Frequency of Publication Repositories............................................................................... 16

4.3. Certificate Issuance ......................................................................................................................... 23

4.8.6. Publication of the Modified Certificate by the CA ........................................................... 27

5.1.4. Water Exposures .............................................................................................................. 35

5.4.6. Audit Collection System (internal vs. external)................................................................ 47

6.2.5. Private Key Archival ......................................................................................................... 56

7.1.8. Policy Qualifiers Syntax and Semantics............................................................................ 63

9.4.2. Information Treated as Private ........................................................................................ 71

9.14. Governing Law ................................................................................................................................. 78

The Ethiopian PKI comprises:

• One Root CA root-signing all Sub-CAs and kept offline.

1.3.1.2. Root Certificate Authority of Ethiopia (INSA)

1.3.2. Registration Authority (RA)

1.3.6.2. Timestamp Service Providers

1.4. Certificate Usage

1.4.1. Appropriate Certificate Uses

1.4.1.1. Certificates Issued to Individuals

Level Level Level

1.4.1.3. Assurance Levels

Assurance Level Description

High At High Assurance level, there is high confidence in an asserted

1.4.2. Prohibited Certificate Uses

1.5.1. Organization Administering the Document

1.5.2. Contact Person

1.6. Definitions and Acronyms

Certificate Problem Report: Complaint of suspected Key Compromise, Certificate misuse, or

Certification Authority: An organization that is responsible for the creation, issuance,

Sub-CA: A Certification Authority whose Certificate is signed by the Root CA.

Legal Entity: An association, corporation, partnership, proprietorship, trust, government entity or

Object Identifier: A unique alphanumeric or numeric identifier registered under the

Online Certificate Status Protocol: An online Certificate-checking protocol that enables

Person: means a physical or legal person.

Reliable Method of Communication: A method of communication, such as a postal/courier

Repository: An online database containing publicly-disclosed PKI governance documents (such

FIPS (US) Federal Information Processing Standard (United States)

KRPS Key Recovery Practices Statement

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.2. Time or Frequency of Publication Repositories

2.2.1. Repository Obligations

These documents are, however, made available to Qualified Auditors.

2.3. Time or Frequency of publication

Certificates and certificate status information shall be published as specified in Section 4.

2.4. Access Controls on Repositories

3. IDENTIFICATION & AUTHENTICATION

3.1.1. Types of Names

3.1.2. Need for Names to be Meaningful

3.1.3. Anonymity or Pseudonymity of Subscribers

This CP does not give permission to anonymous or pseudonymous Subscribers.

3.1.4. Rules for Interpreting Various Name Forms

3.1.5. Uniqueness of Names

3.1.6. Recognition, Authentication & Role of Trademarks

Subscribers shall not use names in their Certificate Application or Certificate

3.2. Initial Identity Validation

Certificate applicants must communicate application requests for certificates to an authorized RA

3.2.1. Method to Prove Possession of Private Key

3.2.2. Authentication of Organization Identity

3.2.3. Authentication of Individual Identity

1. The identity of the person performing the identity verification;