Certificate Policy

National Certification Authority

of
Sri Lanka
Certificate Policy
Version 1.0
Document Information

Document ID D1- CP

Document Name Certificate Policy

Status Release Publication

Version 1.0

Last update To be decided

Document Owner National Certification Authority of Sri Lanka

Document History

Version Description Release Date Effective Date

1 Certificate Policy – Initial Version 30th January 14th February

2020 2020

Approved by: Policy Authority (National Certificate Authority Task Force)

Date: 30th January 2020

Page 2 of 61
Table of Contents

1. INTRODUCTION ....................................................................................................................... 11
1.1. Overview ......................................................................................................................... 11
1.2. Document name and identification .................................................................................. 12
1.3. PKI Participants ................................................................................................................ 12
1.3.1. Certification authorities ............................................................................................... 12
1.3.2. Registration authorities ................................................................................................ 13
1.3.3. Subscribers .................................................................................................................. 13
1.3.4. Relying parties ............................................................................................................. 13
1.3.5. Other participants ........................................................................................................ 13
Policy Authority ........................................................................................................................... 13
1.4. Certificate usage .............................................................................................................. 14
1.4.1. Appropriate certificate uses ......................................................................................... 14
1.4.2. Prohibited certificate uses ............................................................................................ 14
1.5. Policy administration ....................................................................................................... 14
1.5.1. Organization administering the document ................................................................... 14
1.5.2. Contact person ............................................................................................................. 14
1.5.3. Person determining CPS suitability for the policy.......................................................... 15
1.5.4. CPS approval procedures.............................................................................................. 15
1.6. Definitions and acronyms................................................................................................. 15
2. PUBLICATION & PKI REPOSITORY RESPONSIBILITIES................................................................. 18
2.1. Repositories ..................................................................................................................... 18
2.2. Publication of certification information ............................................................................ 18
2.3. Time or frequency of publication ..................................................................................... 18
2.4. Access Controls on repositories........................................................................................ 18
3. IDENTIFICATION & AUTHENTICATION ...................................................................................... 20
3.1. Naming ............................................................................................................................ 20
3.1.1. Types of Names............................................................................................................ 20
3.1.2. Need for names to be meaningful ................................................................................ 20
3.1.3. Anonymity or pseudonymity of subscribers .................................................................. 20
3.1.4. Rules for interpreting various name forms ................................................................... 20
3.1.5. Uniqueness of names ................................................................................................... 20
3.1.6. Recognition, authentication and role of trademarks ..................................................... 20
3.2. Initial identity validation .................................................................................................. 21

Page iii of 61
 3.2.1. Method to prove possession of private key .................................................................. 21
3.2.2. Authentication of organization identity ........................................................................ 21
3.2.3. Authentication of individual identity ............................................................................ 21
3.2.4. Non-verified subscriber information............................................................................. 22
3.2.5. Validation of authority ................................................................................................. 22
3.2.6. Criteria for interoperation ............................................................................................ 22
3.3. Identification and authentication for re-key requests ....................................................... 22
3.3.1. Identification and authentication for routine re-key ..................................................... 22
3.3.2. Identification and authentication for re-key after revocation ....................................... 22
3.4. Identification and authentication for revocation request ................................................. 23
4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS.......................................................... 24
4.1. Certificate Application and Enrolment Process ................................................................. 24
4.1.1. Who can submit a certificate application ...................................................................... 24
4.1.2. Enrollment process and responsibilities ....................................................................... 24
4.2. Certificate Application Processing .................................................................................... 24
4.2.1. Performing identification and authentication functions ................................................ 24
4.2.2. Approval or rejection of certificate applications ........................................................... 25
4.2.3. Time to process certificate applications........................................................................ 25
4.3. Certificate issuance .......................................................................................................... 25
4.3.1. CA actions during certificate issuance........................................................................... 25
4.3.2. Notification to subscriber by the CA of issuance of certificate ...................................... 25
4.4. Certificate acceptance...................................................................................................... 25
4.4.1. Conduct constituting certificate acceptance ................................................................. 25
4.4.2. Publication of the certificate by the CA......................................................................... 26
4.4.3. Notification of certificate issuance by the CA to other entities...................................... 26
4.5. Key pair and certificate usage .......................................................................................... 26
4.5.1. Subscriber private key and certificate usage ................................................................. 26
4.5.2. Relying party public key and certificate usage .............................................................. 26
4.6. Certificate renewal........................................................................................................... 26
4.6.1. Circumstance for certificate renewal ............................................................................ 26
4.6.2. Who may request renewal ........................................................................................... 27
4.6.3. Processing certificate renewal requests........................................................................ 27
4.6.4. Notification of new certificate issuance to subscriber ................................................... 27
4.6.5. Conduct constituting acceptance of a renewal certificate ............................................. 27
4.6.6. Publication of the renewal certificate by the CA ........................................................... 27
4.6.7. Notification of certificate issuance by the CA to other entities...................................... 27

Page iv of 61
4.7. Certificate re-key ............................................................................................................. 27
4.7.1. Circumstance for certificate re-key ............................................................................... 27
4.7.2. Who may request certification of a new public key ...................................................... 27
4.7.3. Processing certificate re-keying requests...................................................................... 28
4.7.4. Notification of new certificate issuance to subscriber ................................................... 28
4.7.5. Conduct constituting acceptance of a re-keyed certificate ............................................ 28
4.7.6. Publication of the re-keyed certificate by the CA .......................................................... 28
4.7.7. Notification of certificate issuance by the CA to other entities...................................... 28
4.8. Certificate Modification ................................................................................................... 28
4.8.1. Circumstance for certificate modification ..................................................................... 28
4.8.2. Who may request certificate modification.................................................................... 28
4.8.3. Processing certificate modification requests................................................................. 29
4.8.4. Notification of new certificate issuance to subscriber ................................................... 29
4.8.5. Conduct constituting acceptance of a modified certificate ........................................... 29
4.8.6. Publication of the modified certificate by the CA .......................................................... 29
4.8.7. Notification of certificate issuance by the CA to other entities...................................... 29
4.9. Certificate revocation and suspension .............................................................................. 29
4.9.1. Circumstances for revocation of a certificate ................................................................ 29
4.9.2. Who can request revocation ........................................................................................ 30
4.9.3. Procedure for revocation request ................................................................................. 30
4.9.4. Revocation request grace period .................................................................................. 30
4.9.5. Time within which CA must process the revocation request ......................................... 31
4.9.7. CRL issuance frequency ................................................................................................ 31
4.9.8. Maximum latency for CRLs ........................................................................................... 31
4.9.9. Online revocation/status checking availability .............................................................. 31
4.9.10. Online revocation checking requirements .................................................................... 31
4.9.11. Other forms of revocation advertisements available .................................................... 32
4.9.12. Special requirements related to key compromise ......................................................... 32
4.9.13. Circumstances for suspension ...................................................................................... 32
4.9.14. Who can request suspension........................................................................................ 32
4.9.15. Procedure for suspension request ................................................................................ 32
4.9.16. Limits on suspension period ......................................................................................... 32
4.10. Certificate status services ............................................................................................. 32
4.10.1. Operational characteristics........................................................................................... 32
4.10.2. Service availability........................................................................................................ 32
4.10.3. Optional Features......................................................................................................... 32

Page v of 61
 4.11. End of Subscription ...................................................................................................... 33
4.12. Key Escrow and Recovery ............................................................................................. 33
4.12.1. Key Escrow and Recovery Policy and Practices ............................................................. 33
4.12.2. Session Key Encapsulation and Recovery Policy and Practices ...................................... 33
5. FACILITY MANAGEMENT & OPERATIONAL CONTROLS ............................................................. 34
5.1. Physical controls .............................................................................................................. 34
5.1.1. Site location and construction ...................................................................................... 34
5.1.2. Physical access ............................................................................................................. 34
5.1.3. Power and air conditioning........................................................................................... 34
5.1.4. Water exposures .......................................................................................................... 34
5.1.5. Fire prevention and protection ..................................................................................... 34
5.1.6. Media storage .............................................................................................................. 35
5.1.7. Waste disposal ............................................................................................................. 35
5.1.8. Off-Site backup ............................................................................................................ 35
5.2. Procedural controls .......................................................................................................... 35
5.2.1. Trusted roles ................................................................................................................ 35
5.2.2. Number of persons required per task ........................................................................... 36
5.2.3. Identification and authentication for each role ............................................................. 37
5.2.4. Roles requiring separation of duties ............................................................................. 37
5.3. Personnel controls ........................................................................................................... 37
5.3.1. Qualifications, experience, and clearance requirements ............................................... 37
5.3.2. Background check procedures ...................................................................................... 37
5.3.3. Training requirements .................................................................................................. 38
5.3.4. Retraining frequency and requirements ....................................................................... 38
5.3.5. Job rotation frequency and sequence ........................................................................... 39
5.3.6. Sanctions for unauthorized actions .............................................................................. 39
5.3.7. Independent contractor requirements ......................................................................... 39
5.3.8. Documentation supplied to personnel ......................................................................... 39
5.4. Audit logging procedures ................................................................................................. 39
5.4.1. Types of events recorded ............................................................................................. 39
5.4.2. Frequency of processing log ......................................................................................... 40
5.4.3. Retention period for audit log ...................................................................................... 40
5.4.4. Protection of audit log.................................................................................................. 40
5.4.5. Audit log backup procedures ........................................................................................ 40
5.4.6. Audit collection system (internal vs. external) .............................................................. 41
5.4.7. Notification to event-causing subject ........................................................................... 41

Page vi of 61
5.4.8. Vulnerability assessments ............................................................................................ 41
5.5. Records Archival .............................................................................................................. 41
5.5.1. Types of records archived............................................................................................. 41
5.5.2. Retention period for archive ........................................................................................ 42
5.5.3. Protection of archive .................................................................................................... 42
5.5.4. Archive backup procedures .......................................................................................... 42
5.5.5. Requirements for time-stamping of records ................................................................. 42
5.5.6. Archive collection system (internal or external) ............................................................ 42
5.5.7. Procedures to obtain & verify archive information ....................................................... 42
5.6. Key changeover................................................................................................................ 42
5.7. Compromise and disaster recovery .................................................................................. 43
5.7.1. Incident and compromise handling procedures ............................................................ 43
5.7.2. Computing resources, software, and/or data are corrupted ......................................... 43
5.7.4. Business continuity capabilities after a disaster ............................................................ 44
5.8. CA or RA termination ....................................................................................................... 44
6. TECHNICAL SECURITY CONTROLS ......................................................................................... 45
6.1. Key pair generation and installation ................................................................................. 45
6.1.1. Key pair generation ...................................................................................................... 45
6.1.2. Private key delivery to subscriber ................................................................................. 45
6.1.4. CA public key delivery to relying parties ....................................................................... 45
6.1.5. Key sizes....................................................................................................................... 45
6.1.6. Public key parameters generation and quality checking................................................ 45
6.1.7. Key usage purposes (as per X.509 v3 key usage field) ................................................... 46
6.2. Private key protection and cryptographic module engineering controls ........................... 46
6.2.1. Cryptographic module standards and controls ............................................................. 46
6.2.2. Private key (n out of m) multi-person control ............................................................... 46
6.2.3. Private key escrow ....................................................................................................... 46
6.2.4. Private key backup ....................................................................................................... 46
6.2.5. Private key archival ...................................................................................................... 47
6.2.6. Private key transfer into or from a cryptographic module............................................. 47
6.2.7. Private key storage on cryptographic module ............................................................... 47
6.2.8. Method of activating private key .................................................................................. 47
6.2.9. Methods of deactivating private key ............................................................................ 47
6.2.10. Method of destroying private key ................................................................................ 47
6.2.11. Cryptographic Module Rating ....................................................................................... 47
6.3. Other aspects of key pair management ............................................................................ 47

Page vii of 61
6.3.1. Public key archival ........................................................................................................ 47
6.3.2. Certificate operational periods and key pair usage periods ........................................... 48
6.4. Activation data................................................................................................................. 48
6.4.1. Activation data generation and installation .................................................................. 48
6.4.2. Activation data protection............................................................................................ 48
6.4.3. Other aspects of activation data ................................................................................... 48
6.5. Computer security controls .............................................................................................. 48
6.5.1. Specific computer security technical requirements....................................................... 48
6.5.2. Computer security rating.............................................................................................. 49
6.6. Life-cycle technical controls ............................................................................................. 49
6.6.1. System development controls ...................................................................................... 49
6.6.2. Security management controls ..................................................................................... 49
6.6.3. Life cycle security controls............................................................................................ 49
6.7. Network security controls ................................................................................................ 49
6.8. Time stamping ................................................................................................................. 50
7. CERTIFICATE, CRL AND OCSP PROFILES ................................................................................ 51
7.1. Certificate Profile ............................................................................................................. 51
7.1.1. Version Number ........................................................................................................... 51
7.1.2. Certificate Extensions ................................................................................................... 51
7.1.3. Algorithm Object Identifiers ......................................................................................... 51
7.1.4. Name Forms................................................................................................................. 51
7.1.5. Name Constraints......................................................................................................... 51
7.1.6. Certificate Policy Object Identifier ................................................................................ 51
7.1.7. Usage of Policy Constraints Extension .......................................................................... 52
7.1.8. Policy Qualifiers Syntax and Semantics ......................................................................... 52
7.1.9. Processing Semantics for the Critical Certificate Policies Extension ............................... 52
7.2. CRL Profile ....................................................................................................................... 52
7.2.1. Version Number(s) ....................................................................................................... 52
7.2.2. CRL and CRL Entry Extensions ....................................................................................... 52
7.3. OCSP Profile ..................................................................................................................... 52
7.3.1. Version Number(s) ....................................................................................................... 52
7.3.2. OCSP Extensions........................................................................................................... 52
8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS.................................................................. 53
8.1. Frequency or circumstances of assessments .................................................................... 53
8.2. Identity/ qualifications of assessor ................................................................................... 53
8.3. Assessor’s relationship to assessed entity ........................................................................ 53

Page viii of 61
8.4. Topics covered by assessment.......................................................................................... 53
8.5. Actions taken as a result of deficiency .............................................................................. 53
8.6. Communication of results ................................................................................................ 53
8.7. Self-Audits ....................................................................................................................... 54
9. OTHER BUSINESS AND LEGAL MATTERS ............................................................................... 55
9.1. Fees ................................................................................................................................. 55
9.1.1. Certificate issuance and renewal fees........................................................................... 55
9.1.2. Certificate access fees .................................................................................................. 55
9.1.3. Revocation or status information access fees ............................................................... 55
9.1.4. Fees for other services ................................................................................................. 55
9.1.5. Refund policy ............................................................................................................... 55
9.2. Financial responsibility ..................................................................................................... 55
9.2.1. Insurance coverage ...................................................................................................... 55
9.2.2. Other assets ................................................................................................................. 55
9.2.3. Insurance or warranty coverage for end-entities .......................................................... 55
9.3. Confidentiality of business information ............................................................................ 55
9.3.1. Scope of confidential information ................................................................................ 55
9.3.2. Information not within the scope of confidential information ...................................... 56
9.3.3. Responsibility to protect confidential information ........................................................ 56
9.4. Privacy of personal information ....................................................................................... 56
9.4.1. Privacy plan.................................................................................................................. 56
9.4.2. Information treated as private ..................................................................................... 56
9.4.3. Information not deemed private .................................................................................. 56
9.4.4. Responsibility to protect private information ............................................................... 56
9.4.5. Notice and consent to use private information ............................................................. 56
9.4.6. Disclosure pursuant to judicial or administrative process ............................................. 56
9.4.7. Other Information Disclosure Circumstances................................................................ 57
9.5. Intellectual property rights............................................................................................... 57
9.6. Representations and warranties....................................................................................... 57
9.6.1. CA representations and warranties .............................................................................. 57
9.6.2. RA representations and warranties .............................................................................. 57
9.6.3. Subscriber representations and warranties .................................................................. 57
9.6.4. Relying party representations and warranties .............................................................. 58
9.6.5. Representations and warranties of other participants .................................................. 58
9.7. Disclaimers of warranties ................................................................................................. 58
9.8. Limitations of liability ....................................................................................................... 58

Page ix of 61
9.9. Indemnities ...................................................................................................................... 59
9.10. Term and Termination.................................................................................................. 59
9.10.1. Term ............................................................................................................................ 59
9.10.2. Termination ................................................................................................................. 59
9.10.3. Effect of termination and survival................................................................................. 59
9.11. Individual notices and communications with participants ............................................. 59
9.12. Amendments ............................................................................................................... 59
9.12.1. Procedure for amendment ........................................................................................... 59
9.12.2. Notification mechanism and period.............................................................................. 60
9.12.3. Circumstances under which OID must be changed ....................................................... 60
9.13. Dispute resolution provisions ....................................................................................... 60
9.14. Governing law .............................................................................................................. 60
9.15. Compliance with applicable law ................................................................................... 60
9.16. Miscellaneous Provisions ............................................................................................. 60
9.16.1. Entire agreement ......................................................................................................... 60
9.16.2. Assignment .................................................................................................................. 60
9.16.3. Severability .................................................................................................................. 60
9.16.4. Enforcement ................................................................................................................ 61
9.16.5. Force majeure .............................................................................................................. 61
9.17. Other provisions........................................................................................................... 61

Page x of 61
 1. INTRODUCTION
1.1. Overview

The Public key infrastructure (PKI) is a set of hardware, software, people, policies and procedures
needed to create, manage, distribute, use, store, and revoke digital certificates. It is an arrangement
that binds public keys with respective user identities by means of a certification authority(CA)
/certification service providers(CSPs).

Sri Lanka PKI is a hierarchical PKI with the trust chain starting from the Root Certification Authority of
National Certification Authority of Sri Lanka. Root CA of NCA is operated by Sri Lanka Computer
Emergency Readiness Team (Sri Lanka CERT) Under the Ministry of Information and Communication
Technology. The NCA root CA is responsible for all aspects of the issuance and management of its
issued certificates.

Below the Root CA of NCA there are Certification Authorities (CAs) which are called as Certification
Service Providers (CSPs) that are accredited by Root CA of NCA. The NCA should also make sure that
applicable standards, procedures and guidelines are in compliance with both NCA Certification Policy
(CP) and Certificate Practice Statement (CPS) and are followed in all CSP operations. CSPs can be
private sector companies, Government departments, public sector companies, or Non-Government
Organizations (NGOs).

The Electronic Transaction Act No. 19 of 2006 grants authority to Sri Lanka CERT to be the NCA. NCA
has the authority to define the requirements for accredited certification service providers.

The Certificate Policy(CP) is the principal statement of policy governing the Sri Lankan Root CA of NCA.
The CP applies to Sri Lanka NCA root CA and thus provides assurances of trust. The CP sets out
requirements that CSPs under NCA must meet.

The purpose of this document is to describe the practices that Root Certification Authority (CA) of
National Certification Authority (NCA) of Sri Lanka follows when issuing and managing Certificates to
its accredited Certification Service Providers (CSPs).

As defined by ITU Recommendation X.509, a Certificate Policy is “a named set of rules that indicates
the applicability of a certificate to a particular community and/or class of application with common
security requirements.”

A certificate policy (CP) focuses on certificates and the CSP's responsibilities regarding these
certificates. It defines certificate characteristics such as usage, enrollment and issuance procedures,
as well as liability issues. The content in this document may reference the NCAs Certificate Practice

Page 11 of 61
Statement (CPS) and other applicable documents for detailed information on discussed topics. All the
applicable policies of NCA are located at https://www.nca.gov.lk.

1.2. Document name and identification

This Certificate Policy is published by the National Certification Authority of Sri Lanka and specifies the
baseline set of security controls and practices that NCA Root CA of Sri Lanka and its accredited CSPs in
Sri Lanka in issuing, revoking or suspending and publishing certificates.

International Telecommunication Union (ITU) and ISO/IEC has assigned the country OID 2.16.144 to
Sri Lanka. For identification purpose, this Certificate Policy bears an Object Identifier (OID)
“2.16.144.1.2.”.

1.3. PKI participants

1.3.1. Certification authorities

PKI provides a systematic methodology to support the verification and validation of a public key
ownership such an ownership is represented by a digital certificate. The certificate is an electronic
document that at least contains information about entities public key to guarantee its integrity, the
certificate is digitally signed by a trusted third party called Certification Authority (CA). The CA issues
certificates to guarantee that an entity whose information is stored in the certificate owns the private
key that is related to the public key values stored in the certificate.

Certification Authority is a person or legal entity who issues a digital certificate to a person or legal
entity (who may be another CA) by using a collection of hardware, software, personnel, and operating
procedures that create, sign, and issue public key certificates to subscribers. This includes centralized,
automated systems such as card management systems. The CA is responsible for issuing and managing
certificates including:

• Issuance of digital certificates including those issued to CSPs

• Publication of Certificates
• Revocation of certificates
• Renewal of the certificates
• Validation services
• Generation and destruction of CA signing keys
• Establishing and maintaining the CA system
• Establishing and maintaining the Certification Practice Statement (CPS)

Page 12 of 61
 • Ensuring that all aspects of the CA services, operations, and infrastructure related to
certificates issued under this CP are performed in accordance with the requirements,
representations, and warranties of the CP.
• Control over the application/enrollment process of CSPs
• The identification and authentication process of CSPs

1.3.2. Registration authorities

A Registration Authority (RA) is a person or legal entity that is responsible for the identification and
authentication of subscribers, but does not sign or issues certificates. It collects and verifies each
subscriber’s identity and information that is to be entered into the subscriber’s public key certificate.
RA performs its function in accordance with the CPS of the CA and is responsible for:

• The registration process

• The identification and authentication process.

1.3.3. Subscribers

A Subscriber is a person or legal entity whose name appears as the subject in a certificate. A subscriber
emphasizes that it uses its key and certificate in accordance with the certificate policy asserted in the
certificate. CAs are sometimes technically considered “subscribers” in a PKI. However, the term
“Subscriber” as used in this document refers only to Certificate Service Providers (CSPs) those who
request certificates from Root CA of NCA.

1.3.4. Relying parties

Relying Parties rely on the validity of the binding of the Subscriber's name to a public key and are
responsible for deciding whether or how to check the validity of the certificate by checking the
appropriate certificate status information. A relying party may use information in the certificate to
determine the suitability of the certificate for a particular use and to verify the integrity of a digitally
signed message, or to identify the creator of a message by verifying the digital signature that is
generated using the private key corresponding to the public key listed in a certificate.

1.3.5. Other participants

Policy Authority

Policy Authority (PA) decides that a set of requirements for certificate issuance and use are sufficient
for the NCA. PA has roles and responsibilities as follows:

Page 13 of 61
 • Establish certificate policy (CP) and certification practice statement (CPS) of NCA and
ensure the compliance of the same with other certification authorities under the NCA
trust model;
• Review of certificate policy and certification practice statement of NCA and other
certification authorities under the NCA trust model on a regular basis; and
• Promote trust relationship of NCA with other domestic or overseas certification
authorities.

Task Force of the NCA will act as the PA of the NCA of Sri Lanka.

1.4. Certificate usage

1.4.1. Appropriate certificate uses

The usage of a certificate issued by NCA Root CA is limited to support the following:

• Authentication and Non-repudiation – Ensures the identity of the CSP;

• Certificate signing – To sign certificates of CSPs;
• Cryptography – Encrypt/decrypt electronic data of CSP. The Private Key shall be used for
Digital Signatures;
• Digital signature – Assist any end user in preventing a subscriber from denying that such
subscriber has authorized any particular transaction if that subscriber has digitally signed
that certificate
• Certificate revocation list (CRL) signing – Authority to sign and publish CRLs

1.4.2. Prohibited certificate uses

A certificate issued in accordance with this CP shall be used only for the purpose as specified in Section
1.4.1, Appropriate Certificate Uses and in particular shall be used only to the extent the use is
consistent with applicable laws.

1.5. Policy administration

1.5.1. Organization administering the document

The NCA Task Force under the NCA is responsible for all aspects of this CP.

1.5.2. Contact person

Chief Executive Officer

Sri Lanka CERT

Page 14 of 61
Room 4-112, BMICH, Bauddhaloka Mawatha, Colombo 07, Sri Lanka.
Tel: +94 11 269 1692 / 269 5749 / 267 9888
Fax: +94 11 269 1064
Email: Info @nca.gov.lk

1.5.3. Person determining CPS suitability for the policy

The PA (NCA Task Force) determines the suitability and applicability of this CP and the conformance
of a CPS to this CP. The PA is also responsible for evaluating and acting upon the results of compliance
audits.

1.5.4. CPS approval procedures

The PA (NCA Task Force) approves the CP/ CPS and any amendments. Amendments are made by either
updating the entire CP/CPS or by publishing an addendum.

The updated version is binding upon all Subscribers including the Subscribers and parties relying on
Certificates that have been issued under a previous version of the CP/CPS.

1.6. Definitions and acronyms

Affiliate: A corporation, partnership, joint venture or other entity controlling, controlled by, or under
common control with another entity, or an agency, department, political subdivision, or any entity
operating under the direct control of a Government Entity.

Certificate: An electronic document that uses a digital signature to bind a Public Key and an identity.

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 Revocation List: A regularly updated timestamped list of revoked Certificates that is
created and digitally signed by the CA that issued the Certificates.

Certification Authority: An organization that is responsible for the creation, issuance, revocation, and
management of digital certificates. The term applies equally to both Roots CAs and Subordinate CAs.

Certification Practice Statement: One of several documents forming the governance framework in
which Certificates are created, issued, managed, and used.

Cross Certificate: A Certificate that is used to establish a trust relationship between two Root CAs.

Page 15 of 61
Federal Information Processing Standards (FIPS): The standards that deal with a wide range of
computer system components including: hardware, storage media, data files, codes, interfaces, data
transmission, networking, data management, documentation, programming languages, software
engineering, performance and security.

High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to
internal criteria and databases maintained by the CA, which may include names at higher risk for
phishing or other fraudulent usage, names contained in previously rejected certificate requests or
revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list,
or names that the CA identifies using its own risk-mitigation criteria.

Key Pair: The Private Key and its associated Public Key.

Network Time Protocol (NTP): A networking protocol for clock synchronization between computer
systems over packet-switched, variable-latency data networks.

Object Identifier (OID): 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 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.

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 (PKI): A system for publishing the Public Key values used in public key
cryptography. Also a system used in verifying, enrolling, and certifying users of a security application.

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.

Page 16 of 61
Root CA: The top level Certification Authority whose Root Certificate is distributed by Application
Software Suppliers and that issues Subordinate 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 Subordinate CAs.

Subordinate CA: A Certification Authority whose Certificate is signed by the Root CA, or another
Subordinate CA. Also called a CSP.

WebTrust: The current version of CPA Canada’s WebTrust Program(s) for Certification Authorities.

CA Certification Authority

CP Certificate Policy

CPS Certification Practice Statement

CRL Certificate revocation list

CSP Certificate Service Provider

DN Distinguished Name

FIPS Federal Information Processing Standards

NCA National Certification Authority

NTP Network Time Protocol

OCSP Online Certificate Status Protocol

OID Object Identifier

PA Policy Authority

PKI Public Key Infrastructure

RA Registration Authority

Page 17 of 61
 2. PUBLICATION & PKI REPOSITORY RESPONSIBILITIES
2.1. Repositories

NCA and all CSPs that issue digital certificates under this CP should post all certificates and CRLs issued
to or by CSPs in a repository which is publically accessible through Uniform Resource Identifier (URI)
references indicated in valid certificates issued by NCA or that CSP. To ensure the integrity and the
availability of certificates and CRLs, the repository shall implement access controls and communication
mechanism to prevent unauthorized modification or deletion of information.

2.2. Publication of certification information

As stated in Section 2.1 the NCA and the CSPs that issue certificates under this CP shall make the
certificates, related information and CRLs available in a publically accessible repository.

NCA Root CA publishes its CP, CPS, Subscriber Agreements, and Relying Party agreements at
https://www.nca.lk/repository. The CP and CPS include all the material required by RFC 3647, and are
structured in accordance with RFC 3647.

NCA Root CA conforms to the current version of the Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates published at http://www.cabforum.org, the current
version of CAB Forum Network Security Requirements and to other root stores that NCA intends to
comply with (i.e. Adobe, Microsoft, Mozilla, etc.) where applicable. NCA Root CA shall ensure its
commitment to the latest baseline requirements, other root stores requirements and implementing
it annually.

In the event of any inconsistency between this document and those Requirements, those
Requirements take precedence over this document.

2.3. Time or frequency of publication

The NCA and CSPs that issues certificates under this CP shall publish its certificates and CRLs as soon
as possible after issuance, an updated version of this CP will be made publicly available within one
working day of the approval of changes. NCA and CSPs that issue certificates under this CP shall update
and publish its CPS accordingly within thirty days after update.

2.4. Access Controls on repositories

The NCA shall not impose any access controls for general public when accessing the certificates and
CRLs in the repository. Any PKI Repository information not intended for public dissemination or
modification shall be protected. CSPs shall clearly declare the restrictions of availability of information

Page 18 of 61
in the repository to whom, and under which conditions the restricted information may be made
available. CSPs shall maintain effective procedures and controls over the management of its
repositories.

Page 19 of 61
 3. IDENTIFICATION & AUTHENTICATION
3.1. Naming

3.1.1. Types of names

The subject name appear on the X.509 certificate shall be the CSPs authenticated common name in
the form of an X.500 Distinguished Name (DN).

3.1.2. Need for names to be meaningful

When applicable, NCA and/or CSPs shall use distinguished names to identify both the entity (i.e.
person, organization, device, or object) that is the subject of the Certificate and the entity that is the
issuer of the Certificate.

The subject name listed in all certificates must have a reasonable association with the authenticated
information of the CSP.

3.1.3. Anonymity or pseudonymity of subscribers

NCA and CSPs that issue certificates under this CP shall not issue certificates which are anonymous or
pseudonymous.

3.1.4. Rules for interpreting various name forms

Distinguished names in Certificates are interpreted using X.500 standards and ASN.1 syntax. Refer to
RFC 2253 and RFC 2616 for further information on how X.500 distinguished names in Certificates are
interpreted as Uniform Resource Identifiers and HTTP references.

3.1.5. Uniqueness of names

The subject name or a combination of the subject name and other data fields listed in a certificate
should be unambiguous and unique for all certificates issued by the NCA Root CA. If necessary,
additional characters may be appended to the authenticated common name to ensure the name’s
uniqueness within the domain name of certificates issued by the NCA Root CA.

3.1.6. Recognition, authentication and role of trademarks

Subscribers may not request Certificates with any content that infringes the intellectual property
rights of another entity. This CP does not require that an Applicant’s right to use a trademark be
verified. However, NCA Root CA may reject any applications or require revocation of any Certificate
that is part of a dispute.

Page 20 of 61
 3.2. Initial identity validation

3.2.1. Method to prove possession of private key

Whenever the CSP named in a certificate generates its own key, that CSP shall prove the possession
on its private key, which corresponds to the public key in the certificate application. If the key
generation is performed under the NCA Root CAs presence, proof shall not be required.

3.2.2. Authentication of organization identity

Requests for certificates shall include the CSP name, address, and documentation of the existence of
the CSP. The NCA shall verify the information relating to the authenticity of the requesting CSP.

CSPs shall submit an application for NCA in order to get registered as an accredited CSP under NCA.
The Task Force of the NCA has the full authority to accept or reject CSP applications.

Any application to obtain a license should include the following (as applicable):

• Project proposal (including network configuration, details and cost of network equipment,
proposed investment, projected cash flow statement, business plan and sources of
funding the project, implementation schedule, tariff structure)
• Company Profile
• Certificate of Incorporation certified by Department of the Registrar of Companies
• Memorandum and Articles of Association (A True Copy certified by Department of the
Registrar of Companies)
• Certificate Policy(CP) and Certificate Practice Statement(CPS)
• Web Trust seals for certification authority

CSPs shall be subjected to Web Trust Audit by an accredited auditor under the CPA, Canada prior to
granting the initial CSP license and relevant Web Trust seals should be obtained annually.

3.2.3. Authentication of individual identity

Public key certificates bind public keys to identities. However, the entity to be identified depends on
the application for which the public keys are used. Identifying different types of entity requires
different evidence and procedures. CA that issues certificates under this CP shall state in its CPS the
types of entity that the CA will support and details the required evidence and procedures.

The NCA Root CA shall not issue digital certificates to individual entities. The certification request from
CSPs shall only be considered.

Page 21 of 61
 3.2.4. Non-verified subscriber information

Information that is not verified shall not be included in certificates.

3.2.5. Validation of authority

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

NCA is responsible for verifying and authenticating the authorized representative by checking the
following documents.

• Authorized Representative Appointment Letter from the organization

• A certified true copy of identification card or passport of the authorized representative of
the organization

3.2.6. Criteria for interoperation

NCA promotes interoperation between CAs issuing certificates under this CP with other CAs which
may or may not issue certificates under this CP (for example, overseas CA(s)). NCA will interoperate
with other Certification Authorities after signing an agreement or a Memorandum of Understanding
(MOU) on behalf of all CAs under Sri Lanka NCA trust model.

3.3. Identification and authentication for re-key requests

3.3.1. Identification and authentication for routine re-key

The License to operate as an accredited CSP is given for a period of 1 year subject to annual audit.
During the tenure of License, CSP certificates are issued without further identification and
authentication. The Authorized Signatory of the accredited CSP can send request for re-key requests.

All requests from accredited CSPs must be made in-person by the CSP’s representative. The requests
must be submitted at the location specified in section 1.5.3. and follow the section 3.2.

3.3.2. Identification and authentication for re-key after revocation

If a certificate has been revoked, the Authorized Signatory of the Licensed CSP can request for re-key
requests. For Licensed CSPs, no identification and authentication is carried out for re-key after
revocation.

All requests from licensed CSPs must be made in-person by the CSP’s representative. The requests
must be submitted at the location specified in section 1.5.3 and follow the section 3.2.

Page 22 of 61
 3.4. Identification and authentication for revocation request

NCA Root CA that approved the certificate’s issuance shall authenticate all revocation requests. NCA
Root CA shall authenticate a revocation request using the certificate’s public key, regardless of
whether the associated private key is compromised.

Page 23 of 61
 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
4.1. Certificate Application

4.1.1. Who can submit a certificate application

CSPs who wants to operate as an accredited CA in Sri Lanka shall submit an application to NCA Root
CA. NCA Root CA issues certificates only for the CSPs. End user certificate applications should be
submitted to authorized CSPs. The required documents that are essential to submit is listed in section
3.2. Applicants for the certificates shall be responsible for providing accurate information in their
application for certification.

4.1.2. Enrollment process and responsibilities

The NCA Root CA is responsible for ensuring that the identity of each Certificate Applicant is verified
in accordance with this CP and the applicable CPS prior to the issuance of a Certificate. Applicants are
responsible for submitting sufficient information and documentation for the NCA Root CA to perform
the required verification of identity prior to issuing a Certificate. NCA Root CA 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 NCA Root CA to verify that the information in certificate application is
accurate before the issuance of the certificate. The procedures to verify information in certificate
application is specified in the CPS. The identity validation should be done as mentioned in section 3.2.
The components of the PKI that are responsible for authenticating the subscriber’s identity must be
identified in the CPS.

The NCA Root CA shall develop, maintain, and implement documented procedures that identify and
require additional verification activity for High Risk Certificate Requests prior to the Certificate’s
approval, as reasonably necessary to ensure that such requests are properly verified under these
Requirements.

NCA Root CA shall request and verify additional documents to identify the legal mandate for the
entities that are flagged/identified as High Risk.

NCA Root CA does not issue any certificates with FQDNS/domain validated certificates and hence does
not perform CAA checks.

Page 24 of 61
 4.2.2. Approval or rejection of certificate applications

The certificate applications received by the NCA will be reviewed and validated. The validation process
takes 30 working days, starting from the date that the NCA received the application. It is a sole
decision taken by the NCA to approve or reject a certificate application. The applications that fail
during the validation process will be rejected. The approval or rejection notification will be sent to the
subscriber by the NCA.

4.2.3. Time to process certificate applications

All parties involved in certificate application processing shall use reasonable efforts to ensure that
certificate applications are processed in a timely manner. NCA Root CA shall complete the processing
of the certificate application within 30 business days, counting from the date the NCA Root CA
received the application.

4.3. Certificate issuance

4.3.1. CA actions during certificate issuance

Certificate issuance by NCA Root CA requires NCA Task Force to deliberately issue a direct command
in order for the NCA Root CA to perform a Certificate signing operation. The NCA Root CA shall protect
databases under their control and that are used to confirm CSP identity information from unauthorized
modification or use.

NCA Root CA shall perform validation to ensure that all information sent to NCA is verified and
authenticated in a secure manner.

If all the requirements are met by the CSP, then the digital certificate can be signed by the NCA Root
CA.

4.3.2. Notification to subscriber by the CA of issuance of certificate

Once the NCA Root CA sign the CSP certificate, a notification shall be sent to the CSP regarding the
issuance of the certificate via an email permitting the CSP to download the certificate form the NCA
Root CA website.

4.4. Certificate acceptance

4.4.1. Conduct constituting certificate acceptance

After the receipt of the certification issuance notification, the subscriber must verify the information
on the certificate and either accept or reject the certificate.

Page 25 of 61
In case the subscriber fails to inform the acceptance of the certificate to the NCA within 10 business
days of issuance of notification the certificate should be revoked by the NCA Root CA.

4.4.2. Publication of the certificate by the CA

The issued certificates should be published in the repositories. Publication arrangements of subscriber
certificate are specified in the CPS of the NCA Root CA.

4.4.3. Notification of certificate issuance by the CA to other entities

NCA Root CA will notify NCA Task Force whenever a certificate is issued to a CSP.

4.5. Key pair and certificate usage

4.5.1. Subscriber private key and certificate usage

Subscriber should protect its Private Key corresponding to the Public Key in the certificate, which is
issued by NCA Root CA and use that Private key to generate its digital signature to other relying parties.

CSP can use its Private Key corresponding to the Public Key in the certificate to issue certificates to
end users. R

4.5.2. Relying party public key and certificate usage

Relying parties shall use public key certificates and associated public keys for the purposes as
constrained by the extensions in the certificates.

Relying Parties shall assess the certificate for its accuracy, validity period, status (whether it is revoked
or suspended) etc. before any act of reliance.

4.6. Certificate renewal

Renewing a certificate is creating a new certificate with the same name, same key, and other
information as the previous certificate, yet with extended validity period and a new serial number.
Certificates may be renewed in order to reduce the size of CRLs.

Request for renewal of certificates are not accepted by NCA Root CA at present.

4.6.1. Circumstance for certificate renewal

Not Applicable.

Page 26 of 61
 4.6.2. Who may request renewal

Not Applicable.

4.6.3. Processing certificate renewal requests

Not Applicable.

4.6.4. Notification of new certificate issuance to subscriber

Not Applicable.

4.6.5. Conduct constituting acceptance of a renewal certificate

Not Applicable.

4.6.6. Publication of the renewal certificate by the CA

Not Applicable.

4.6.7. Notification of certificate issuance by the CA to other entities

Not Applicable.

4.7. Certificate re-key

Re-keying a certificate is creating new certificates with a different public key, serial number and
validity period while retaining the remaining contents of the previous certificate that describe the
subscriber.

4.7.1. Circumstance for certificate re-key

The subscriber shall request for a re-key under the following circumstances.

• CSP’s certificate has less 25% life time before expiration or has already expired.
• CSP’s certificate has been revoked.

4.7.2. Who may request certification of a new public key

The NCA Root CA may accept a re-key request provided that it is authorized by the original CSP. A
Certificate signing request is mandatory with any new Public Key.

Page 27 of 61
 4.7.3. Processing certificate re-keying requests

Processing Certificate Re-Keying Requests shall follow the same process described in Section 4.1.2.
The previous validation data older than 825 days shall not be re-used and the NCA shall require
updated data for re-keying.

4.7.4. Notification of new certificate issuance to subscriber

NCA Root CA that issues certificates under this CP shall notify the result of new certificate issuance to
subscriber according to the procedures specified in Section 4.3.2.

4.7.5. Conduct constituting acceptance of a re-keyed certificate

After subscribers receive re-keyed certificate, subscribers must follow the procedure in Section 4.4.1
to accept the re-keyed certificate.

4.7.6. Publication of the re-keyed certificate by the CA

NCA Root CA that issues certificates under this CP shall publish the re-keyed according to the
procedure in Section 4.4.2.

4.7.7. Notification of certificate issuance by the CA to other entities

NCA Root CA that issues certificates under this CP shall notify the result of certificate issuance to other
entities according to the procedure in Section 4.4.3.

4.8. Certificate modification

Modifying a Certificate means creating a new Certificate for the same subject with authenticated
information that differs slightly from the old Certificate (e.g., changes to email address or non-
essential parts of names or attributes) provided that the modification otherwise complies with this
CP. The new Certificate may have the same or a different subject Public Key.

Request for modification of certificates are not accepted by NCA Root CA at present.

4.8.1. Circumstance for certificate modification

Not Applicable.

4.8.2. Who may request certificate modification

Not Applicable.

Page 28 of 61
 4.8.3. Processing certificate modification requests

Not Applicable.

4.8.4. Notification of new certificate issuance to subscriber

Not Applicable.

4.8.5. Conduct constituting acceptance of a modified certificate

Not Applicable.

4.8.6. Publication of the modified certificate by the CA

Not Applicable.

4.8.7. Notification of certificate issuance by the CA to other entities

Not Applicable.

4.9. Certificate revocation and suspension

4.9.1. Circumstances for revocation of a certificate

The NCA shall revoke a CSP Certificate within seven (7) days if one or more of the following occurs:

• The CSP requests revocation in writing;

• The CSP notifies the NCA that the original certificate request was not authorized and does not
retroactively grant authorization;
• The NCA obtains evidence that the CSP's Private Key corresponding to the Public Key in the
Certificate suffered a Key Compromise or no longer complies with the requirements of
Sections 6.1.5 and 6.1.6;
• The NCA obtains evidence that the Certificate was misused;
• The NCA is made aware that the Certificate was not issued in accordance with or that CSP has
not complied with this document or the applicable Certificate Policy or Certification Practice
Statement;
• The NCA is made aware that the the CSP has not complied with the CA/B Forum Baseline
requirements.
• The NCA determines that any of the information appearing in the Certificate is inaccurate or
misleading;
• The NCA or CSP ceases operations for any reason and has not made arrangements for another
CA to provide revocation support for the Certificate;

Page 29 of 61
 • The NCA's or CSP's right to issue Certificates under these Requirements expires or is revoked
or terminated, unless the NCA has made arrangements to continue maintaining the CRL/OCSP
Repository; or
• Revocation is required by the NCA's Certificate Policy and/or Certification Practice Statement.

In case any of the above circumstances occur, the associated certificate shall be revoked, placed on
the CRL and shall be included on all new publications of the certificate status information until the
certificates expire.

4.9.2. Who can request revocation

• Subscriber (CSP) may make a request to revoke the certificate for which the subscriber is
responsible.
• NCA Root CA that issues certificates under this CP may make a request to revoke its own
certificate.
• NCA Root CA that issues certificates under this CP may also revoke any issued certificate
whenever it knows or reasonably suspects that the circumstances as specified in section 4.9.1
occurred.
• The Court may make a request to revoke the certificate via a court order

4.9.3. Procedure for revocation request

Procedure for revocation request for certificates issued under this CP is stated in the CPS.

Subscriber submits the revocation request and related documents to the NCA Root CA providing that
the information is genuine, correct and complete.

NCA root CA verifies and endorses the revocation requests and the related documents and shall inform
the revocation result to the subscriber.

In case NCA Root CA determines a certificate problem relevant to the revocation request, forward
such complaints to law enforcement, where appropriate.

4.9.4. Revocation request grace period

Responsible parties must request revocation immediately as they identify the need for revocation and
therefore there is no revocation grace period.

Page 30 of 61
 4.9.5. Time within which CA must process the revocation request

The NCA Root CA shall process a revocation request immediately so that the revocation can be posted
on the next CRL publication. Revocation requests shall be processed within seven business days or
before the next CRL is published.

4.9.6. Revocation checking requirement for relying parties

It is the sole responsibility of Relying Parties for checking the validity of each certificate in the
certificate path, including checks for certificate validity, issuer-to-subject name chaining, certificate
policy and key usage constraints, and the status of the certificate through the CRL.

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. The NCA Root CA shall ensure that superseded certificate status information is removed
from the PKI Repository upon posting of the latest certificate status information.

CA that issues certificates under this CP shall issue a CRL in the following circumstances:

• Issue a CRL whenever a certificate or a CSP certificate is revoked. CRL issuance timing shall be
within 24 hours after revoke of a subscriber certificate.
• Issue a CRL for certificates once every twelve months whether or not the CRL has any changes.

4.9.8. Maximum latency for CRLs

CRLs shall be published within 24 hours after generation. Furthermore, each CRL shall be published no
later than the time specified in the nextUpdate field of the previously issued CRL. CA that issues
certificates under this CP shall publish CRL within commercially acceptable period of time.

4.9.9. Online revocation/status checking availability

On-line status checking is optional for NCA Root CA. Where on-line status checking is supported, status
information shall be regularly updated and available to relying parties.

4.9.10. Online revocation checking requirements

Relying Parties may optionally check the status of certificates through the NCA Root CA’s Online
Certificate Status Protocol (OCSP) service.

Page 31 of 61
 4.9.11. Other forms of revocation advertisements available

Any alternate forms used to disseminate revocation information shall be implemented in a manner
consistent with the security and latency requirements for the implementation of CRLs and on-line
revocation and status checking.

4.9.12. Special requirements related to key compromise

The NCA Root CA and/or CSPs shall use commercially reasonable efforts to notify potential Relying
Parties if it discovers or suspects that its Private Key has been compromised. The NCA Root CA and/or
CSPs must have the ability to transition any revocation reason to code to “key compromise”. If a
Certificate is revoked because of compromise or suspected compromise, the NCA Root CA and/or CSPs
shall issue a CRL within 24 hours after it receives notice of the compromise or suspected compromise.

4.9.13. Circumstances for suspension

For certificate, suspension is not permitted.

4.9.14. Who can request suspension

Not applicable.

4.9.15. Procedure for suspension request

Not applicable.

4.9.16. Limits on suspension period

Not applicable.

4.10. Certificate status services

4.10.1. Operational characteristics

The status of certificates is available through the NCA Root CA’s website and LDAP using the
appropriate software.

4.10.2. Service availability

CA that issues certificates under this CP shall implement backup systems for providing certificate
status services and put the best efforts to make such services available 24x7.

4.10.3. Optional Features

Not applicable.

Page 32 of 61
 4.11. End of Subscription

CSPs may end their subscription to Certificate services by having their Certificate revoked or naturally
letting it expire.

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 private key be escrowed by a third party.

4.12.2. Session Key Encapsulation and Recovery Policy and Practices

Not Applicable.

Page 33 of 61
 5. FACILITY MANAGEMENT & OPERATIONAL CONTROLS
5.1. Physical controls

5.1.1. Site location and construction

All NCA operations shall be conducted within a physically protected environment that deters,
prevents, and detects unauthorized use, access or disclosure of sensitive information and systems.
The site location and construction shall provide robust protection against unauthorized access to the
NCA equipment and records when combined with other physical security protection mechanisms such
as guards, high security locks, and intrusion sensors.

5.1.2. Physical access

Access to NCA Root CA Certificate Issuance system is only allowed for the responsible officers of the
NCA. Access the service area where the NCA Root CA systems are located will be given to any other
individuals after obtaining the proper authorization. All visitors must be accompanied by the
responsible officer during the whole visit and must be recorded in the access log.

Dual-control or two-factor authentication will be used for physically accessing the Certificate issuing
servers and Cryptographic Module which must be stored in a secure area.

5.1.3. Power and air conditioning

NCA 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.
Repositories shall be provided with Uninterrupted Power sufficient for a minimum of six-hours
operation in the absence of commercial power, to support continuity of operations.

5.1.4. Water exposures

The secure facilities of NCA shall be constructed and equipped, and procedures shall be implemented,
to prevent floods or other damaging exposure to water, e.g.: on raised floor equipped with water
sensor. Sensors shall be used for water seepage detection.

5.1.5. Fire prevention and protection

The secure facilities of NCA shall be constructed and equipped, and procedures shall be implemented,
to prevent and extinguish fires or other damaging exposure to flame or smoke. These measures shall
meet all local applicable safety regulations.

Page 34 of 61
 5.1.6. Media storage

NCA Root CA shall protect all media holding back ups of critical system data or any other sensitive
information from water, fire, or other environmental hazards and any accidental damage, and shall
use protective measures to deter, detect, and prevent the unauthorized use, access, or disclosure of
such media. Media that contains audit, archive, or backup information shall be duplicated and stored
in a location separate from the NCA location.

5.1.7. Waste disposal

NCA shall implement procedures for the disposal of waste (paper, media, or any other waste) to
prevent the unauthorized use, access, or disclosure of waste containing sensitive Information.

5.1.8. Off-Site backup

At least one full backup copy shall be stored at an offsite location.

5.2. Procedural controls

5.2.1. Trusted roles

A trusted role is identified as incumbent who performs functions that has a possibility of introducing
security problems accidentally or maliciously if not carried out properly. The individuals selected for
these roles must be extraordinarily responsible or else the integrity of the CA will be weakened. The
functions performed in these roles create 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 approach is
to minimize the number of trusted roles and ensure that the people performing those roles are
trustworthy and properly trained. The second is to enforce the concept of least privilege and distribute
the functions of the roles among several people, so that any malicious activity requires collusion.

CA administrator

The administrator shall be responsible for:

• Installation, configuration, and maintenance of the NCA Root CA;

• Establishing and maintaining NCA Root CA system accounts;
• Configuring certificate profiles or templates and audit parameters, and;
• Generating and backing up NCA Root CA keys.

CA Officer

The CA officer shall be responsible for issuing certificates, that is:

Page 35 of 61
 • Registering new subscribers and requesting the issuance of certificates;
• Verifying the identity of subscribers and accuracy of information included in certificates;
• Approving and executing the issuance of certificates, and;
• Requesting, approving and executing the revocation of certificates.

Audit Administrator

The Audit Administrator shall be responsible for:

• Reviewing, maintaining, and archiving audit logs;

• Performing or overseeing internal compliance audits to ensure that the NCA Root CA is
operating in accordance with its CPS;

System Administrator

The System Administrator shall be responsible for the routine operation of the NCA Root CA
equipment and operations such as system backups and recovery or changing recording media.

Registration Authority

NCA Root CA’s RA, responsibilities are:

• Verifying organizational identity of the CSP.

• Entering CSP’s information, and verifying correctness;
• Securely communicating requests and responses from to the NCA;

5.2.2. Number of persons required per task

Where multi-party control is required, all participants shall hold a trusted role. The following tasks
shall require two or more persons:

• Generation, activation, and backup of CA keys

• Performance of CA administration or maintenance tasks
• Archiving or deleting CA audit logs. At least one of the participants shall serve in a Security
Auditor role
• Physical access to CA equipment
• Access to any copy of the CA cryptographic module
• Processing of third party key recovery requests

Page 36 of 61
 5.2.3. Identification and authentication for each role

An individual shall identify and authenticate him/herself before being permitted to perform any
actions set forth above for that role or identity.

Individuals holding trusted roles shall be appointed to the trusted role by NCA Task Force. The approval
shall be recorded in a secure and auditable fashion. Individuals holding trusted roles shall accept the
responsibilities of the trusted role, and this acceptance shall be recorded in a secure and auditable
fashion.

5.2.4. Roles requiring separation of duties

Individuals serving as Security Auditors shall not perform or hold any other trusted role. An individual
that holds any NCA Root CA Operations Staff role shall not be an RA except that NCA Root CA
Operations Staff may perform RA functions when issuing certificates or issuing certificates to RA.

Only an individual serving in a Security Auditor role may perform internal auditing functions, with the
exception of those security audit functions (e.g., configuring, archiving, deleting) that require multi-
person control.

An individual that performs any trusted role shall only have one identity when accessing CA
equipment.

The following roles must be performed by trusted officers:

• Verification and validation of forms such as the certificate application forms and the certificate
revocation form.
• Certificate issuance and certificate revocation.
• Access to CA’s private key.

5.3. Personnel controls

5.3.1. Qualifications, experience, and clearance requirements

All personnel of NCA Root CA that issues certificates under this CP must be examined with their
qualifications in terms of the requisite background, experience in order to ensure their prospective
job responsibilities, competency and satisfaction.

5.3.2. Background check procedures

Prior to commencement of employment, NCA must conduct the following background checks:

• Identification card

Page 37 of 61
 • Permanent Residency
• Educational Qualifications
• Criminal Background Check
• Professional Qualifications
• Confirmation of previous employments

NCA Root CA that issues certificates under this CP may also exercise other measurements for
background check. If the provided information is found to be false, or if the education/professional
background is found unmatched, or if the person has certain criminal convictions, that person shall
not be considered to work for the NCA.

NCA Root CA shall refresh all background checks at least every five years.

5.3.3. Training requirements

NCA that issues certificates under this CP must provide its officers with appropriate training as well as
the requisite on-the-job training needed to perform their job responsibilities related to NCA Root CA
operations with competency and satisfaction. The training programs include the following as relevant:

• Basic cryptography and Public Key Infrastructure (PKI) concepts

• All duties they are expected to perform
• Information Security Awareness
• Use and operation of deployed hardware and software related to NCA operations
• Security Risk Management
• Disaster recovery and business continuity procedures

The NCA Root CA shall maintain records of such training and ensure that personnel entrusted with
trusted roles maintain a skill level that enables them to perform such duties satisfactorily.

The NCA Root CA shall document that each trusted role possesses the skills required by a task before
allowing them to perform that task.

The NCA Root CA shall require all trusted roles to pass an examination provided by the NCA Root CA
on the information verification requirements outlined in these Requirements.

5.3.4. Retraining frequency and requirements

Individuals responsible for trusted roles shall be aware of changes in the NCA Root CA, CSP, or RA
operations, as applicable. At least one annual re-training shall be provided for all the trusted role

Page 38 of 61
personal. Additional training may be considered if there is a change in hardware and software related
to CA operations.

5.3.5. Job rotation frequency and sequence

NCA Root CA shall not perform job rotation. However, it shall ensure that any change in the staff will
not affect the operational effectiveness of the service or the security of the system.

5.3.6. Sanctions for unauthorized actions

Appropriate disciplinary actions shall be applied for unauthorized actions or other violations of
relevant policies and procedures.

5.3.7. Independent contractor requirements

Any contractor or consultant are only permitted to access to NCA Root CA’s secure facilities if they are
escorted and directly supervised by trusted officers at all times.

5.3.8. Documentation supplied to personnel

NCA Root CA that issues certificates under this CP must provide its personnel the requisite
documentation needed to perform their job responsibilities competently and satisfactorily.

5.4. Audit logging procedures

Audit log files shall be generated for all events relating to the security of the NCA Root CA, CSPs, and
RA. Where possible, the security audit logs shall 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, shall be retained and made available during compliance audits.

5.4.1. Types of events recorded

NCA Root CA that issues certificates under this CP must log the following significant events:

• CA Key Life Cycle Management, including: Key generation, backup, storage, recovery, archival,
and destruction
• Cryptographic Module life cycle management events
• CA and Subscriber certificate life cycle management events, including: Certificate
Applications, rekey, and revocation
• Approval or rejection of requests
• Generation and issuance of certificates and CRL
• Security-related events including:

Page 39 of 61
 o Successful and unsuccessful access attempts to CA systems
o Security system actions performed by CA officers
o Security profile changes
o System crashes, hardware failures and other anomalies
o Firewall and router activity
o CA facility visitor entry/exit
Log entries include the following elements:

• Type of event
• Date and time of the event occurred
• Success or Failure where appropriate
• The identity of the entity and/or operator that caused the event
• A message from any source requesting an action by the CA is an auditable event;

5.4.2. Frequency of processing log

NCA Root CA operated under this CP shall examine audit logs at a reasonable frequency and at least
on a monthly basis.

5.4.3. Retention period for audit log

Audit logs are retained for at least 90 days.

5.4.4. Protection of audit log

System configuration and procedures shall be implemented together to ensure that:

• Only authorized people have read access to the logs;

• Only authorized people may archive audit logs; and,
• Audit logs are not modified.
It is acceptable for the system to over-write audit logs after they have been backed up and archived.

5.4.5. Audit log backup procedures

Audit logs stored in an electronic audit log system are backup in a secure manner. Event Records follow
the procedures below:

• Paper-based event records are converted into electronic format before being stored in the
audit log system.
• CA backup audit events specified in 5.4.1 in backup media.

Page 40 of 61
 5.4.6. Audit collection system (internal vs. external)

Audit data is generated and recorded at the machine that the event has occurred and at the audit log
system.

5.4.7. Notification to event-causing subject

Not Applicable.

5.4.8. Vulnerability assessments

CA that issues certificates under this CP must assess security vulnerabilities. The vulnerability
assessments shall be performed quarterly basis and the penetration tests shall be performed annual
basis.

5.5. Records Archival

5.5.1. Types of records archived

CA, CSP, and RA archive records shall 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 NCA
Root CA.

CA archives:

CA systems

• All audit data specified in 5.4.1

• System configuration
• Website

Documentation supporting certificate applications

• Certificates, CRLs, and expired or revoked certificates

• CP and CPS

Certificate lifecycle information

• Forms such as Application Form, Revocation Request Form, Re-key Request Form, and
Certificate Acceptance Form
• Required documents for application
• Internal documents such as procedure manuals and system access approval request

Page 41 of 61
 • Letters or memos used for communication between CA and external parties such as, NCA Root
CA, Subscriber and other CAs.

5.5.2. Retention period for archive

Records shall be retained for at least 10 years, unless there are specific requirements.

5.5.3. Protection of archive

Records archival are stored in secure facilities and can be accessed only by authorized persons.

5.5.4. Archive backup procedures

Records archival are backed up in backup drives on a monthly basis following the below procedures:

• Paper-based event records are converted into electronic format before being stored and
backed up.
• CA backups events records specified in Section 5.5.1 in the backup media.

5.5.5. Requirements for time-stamping of records

Archived records shall be time stamped such that order of events can be determined.

5.5.6. Archive collection system (internal or external)

Archive Collection System is internal to NCA only.

5.5.7. Procedures to obtain & verify archive information

Procedures detailing how to create, verify, package, and transmit archive information shall be
published in the applicable CPS.

5.6. Key changeover

To minimize risk from compromise of a CA’s private signing key, that key may be changed often; from
that time on, only the new key shall 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
shall be retained and protected.

CA’s signing keys shall have a validity period as described in section 6.3.2.

When a CA updates its private signature key and thus generates a new public key, the CA shall notify
all CAs, RAs, and subscribers that rely on the CA’s certificate that it has been changed.

Page 42 of 61
 5.7. Compromise and disaster recovery

5.7.1. Incident and compromise handling procedures

Investigations shall be performed to determine the nature and the degree of the damage in case the
NCA Root CA is suspected to be compromised. If the CA or CSP key is suspected of compromise, the
procedures outlined in Section 5.7.3 shall be followed. Otherwise, the scope of potential damage shall
be assessed in order to determine if the CA or CSP needs to be rebuilt, only some certificates need to
be revoked.

The NCA shall be notified if any of the following cases occur:

• Suspected or detected compromise of an accredited CA system;

• Physical or electronic attempts to penetrate an accredited CA system;
• Denial of service attacks on an accredited CA system; or
• Any incident preventing the accredited CA from issuing a CRL within 24 hours of the time
specified in the next update field of its currently valid CRL. A CA shall reestablish capability to
issue CRL as quickly as possible.

5.7.2. Computing resources, software, and/or data are corrupted

In case of software, hardware or data failure, the corresponding NCA Root CA officers will report such
incidents to the NCA Task Force in order to make decisions and deal with the incident properly. If it is
necessary, a disaster recovery plan may be used to restore NCA Root CA services.

5.7.3. Entity private key compromise procedures

In the case of NCA Root CA compromise, NCA shall notify NCA Task Force and relying parties via public
announcement, and any cross-certified PKIs, of the NCA Root CA compromise so that they can revoke
any cross certificates issued to the NCA Root CA or any CSPs and notify all end entities and Relying
Parties to remove the trusted self-signed certificate from their trust stores.

• Notification shall be made in an authenticated and trusted manner.

• Initiation of notification to NCA Task Force and any cross-certified PKIs shall be made at the
earliest feasible time and shall not exceed 24 hours beyond determination of compromise or
loss unless otherwise required by law enforcement.
• Initiation of notification to relying parties and subscribers will be made after mediations are
in place to ensure continued operation of applications and services.
• If the cause of the compromise can be adequately addressed, and it is determined that the
PKI can be securely re-established, NCA Root CA shall then generate a new root certificate,

Page 43 of 61
 solicit requests and issue new certificates, securely distribute the new root certificate, and re-
establish any cross certificates.

If a CSP key is compromised, all certificates issued to the CSP shall be revoked, if applicable. The CSP
will generate a new key pair and request new certificate(s), if applicable.

• NCA Root CSP shall revoke that CSP’s certificate, and the revocation information shall be
published immediately in the most expedient, authenticated, and trusted manner but within
18 hours after the notification.
• The compromised CSP shall also investigate and report to NCA Task Force what caused the
compromise or loss, and what measures have been taken to preclude recurrence.
• If the cause of the compromise can be adequately addressed and it is determined that the CA
can be securely re-established, then the CA shall be re-established. Upon re-establishment of
the CSP, new subscriber certificates shall be requested and issued again.

When a certificate is revoked because of compromise, suspected compromise, or loss of the private
key, a CRL shall be published at the earliest feasible time by the CA, but in no case more than 6 hours
after notification.

5.7.4. Business continuity capabilities after a disaster

NCA Root CA that issues certificates under this CP shall prepare a disaster recovery plan which have
been tested, verified and continually updated. A full restoration of services will be done within 24
hours in case of disaster.

5.8. CA or RA termination

If there is any circumstance to terminate the services of NCA operating under this CP with the approval
of NCA Task Force, NCA operating under this CP will notify the subscribers and all relying parties. The
action plan is as follow:

• Notify status of the service to affected users.

• Revoke all certificates.
• Long-term store information of CA and subscribers according to the period herein specified.
• Provide ongoing support and answer questions.
• Properly handle key pair and associated hardware.

Page 44 of 61
6. TECHNICAL SECURITY CONTROLS

6.1. Key pair generation and installation

6.1.1. Key pair generation

A cryptographic key management device that meets Federal Information Processing Standard (FIPS)
140-2 Level 3 under multi-person control shall be used to generate a key pair and store the private
key which shall be used to issue certificates under this CP by the NCA Root CA.

NCA Root CA key pair generation must create a verifiable audit trail demonstrating that the security
requirements for procedures were followed. The documentation of the procedure must be detailed
enough to show that appropriate role separation was used. An independent third party shall validate
the execution of the key generation procedures either by witnessing the key generation or by
examining the signed and documented record of the key generation.

Subscriber key pair generation shall be performed by the subscriber.

6.1.2. Private key delivery to subscriber

NCA Root CA and Subscriber (CSPs) must generate the key pair by themselves.

6.1.3. Public key delivery to certificate issuer

The key pair shall be generated by the Subscriber (CSP) themselves. NCA Root CA that issues
certificates under this CP shall provide a channel for subscriber to securely deliver the public key and
the subscriber’s identity to the NCA Root CA. the subscribers are required to submit Certificate Signing
Request in the form of PKCS # 10 standard with application by themselves.

6.1.4. CA public key delivery to relying parties

Relying parties can access NCA Root CA public key in the certificate by the published channel.

6.1.5. Key sizes

Certificates issued under this policy shall contain RSA public keys with the minimum key size of 4,096
bits and should use the SHA-512 hash algorithm when generating digital signatures. NCA Root CA must
not issue certificates signed with SHA-1.

6.1.6. Public key parameters generation and quality checking

NCA Root CA shall generate Key Pairs in accordance with FIPS 186 and shall use reasonable techniques
to validate the suitability of Public Keys presented by Subscribers. Known weak keys shall be tested

Page 45 of 61
for and rejected at the point of submission. NCA and CSPs shall reference Baseline Requirements
Section 6.1.6 on quality checking.

6.1.7. Key usage purposes (as per X.509 v3 key usage field)

The use of a specific key is constrained by the key usage extension in the X.509 certificate. All
certificates shall include a critical key usage extension.

Public keys that are bound into subscriber certificates shall be used for signing or encrypting.

Public key that are bound into certificates shall be used for signing certificates and status information
such as CRLs.

Only NCA Root CA shall issue certificates to CSPs located in Sri Lanka.

6.2. Private key protection and cryptographic module engineering controls

6.2.1. Cryptographic module standards and controls

NCA Root CA that issues certificates under this CP shall use a FIPS 140-2 Level 3 or higher validated
hardware cryptographic module for key management.

Subscribers (CSPs) shall use a FIPS 140-2 Level 3 or higher validated hardware cryptographic module
for all cryptographic operations.

6.2.2. Private key (n out of m) multi-person control

Accessing private key of NCA Root CA under this CP must be performed by at least two trusted role
personnel.

6.2.3. Private key escrow

Under no circumstances shall the private key of NCA Root CA be escrowed by a third party.

6.2.4. Private key backup

NCA Root CA’s private key shall be backed up under the same multiparty control as the original
signature key. At least one copy of the private key shall be stored off-site. All copies of the NCA Root
CA private key shall be accounted for and protected in the same manner as the original. NCA Root CA
that issues certificate under this CP shall backup its private signature key in FIPS 140-2 Level 3 validated
hardware cryptographic module. The NCA Root CA shall state in its CPS the backup procedure.

Page 46 of 61
 6.2.5. Private key archival

NCA Root CA private key beyond the validity period will be kept at least 10 years and stored in
Cryptographic Module with FIPS 140-2 Level 3 standards.

6.2.6. Private key transfer into or from a cryptographic module

CA private keys may be exported from the cryptographic module only to perform CA key backup. At
no time shall the CA private key exist in plaintext outside the cryptographic module.

6.2.7. Private key storage on cryptographic module

NCA Root CA operating under this CP shall store its Private Keys on a cryptographic module which
complies with FIPS 140-2 Level 3 or above standard.

6.2.8. Method of activating private key

Activation of NCA Root CA’s private key operations, perform by authorized persons and requires two-
factor authentication.

6.2.9. Methods of deactivating private key

The cryptographic modules that have been activated shall not be left unattended or otherwise
available to unauthorized access. After use, the cryptographic module shall be deactivated, e.g., via a
manual logout procedure, or automatically after a period of inactivity as defined in the applicable CPS.

6.2.10. Method of destroying private key

NCA Root CA will delete the private keys from Cryptographic Module and its backup by overwriting
the private key or initialize the module with the destroy function of Cryptographic Module.

The event of destroying CA must be recorded into evidence.

6.2.11. Cryptographic Module Rating

Cryptographic Module Rating complies with FIPS 140-2 Level 3 standard.

6.3. Other aspects of key pair management

6.3.1. Public key archival

The public key is archived as part of the certificate archival.

Page 47 of 61
 6.3.2. Certificate operational periods and key pair usage periods

The certificate validity period of the NCA Root CA specified in the certificate. Key pair associated with
the certificate can be used up to the expiry date specified in the certificate. Public key can be used to
verify the digital signature even if the certificate is expired but the digital signature to be verified must
be created before expiry date of the certificate. For the private key, it can be used to decrypt even if
certificate is expired.

The validity period of NCA root certificate is 10 years and validity period of CSP certificates is not more
than 8 years. Certificate operational periods and key pair usage periods shall be assessed by NCA Task
Force at least once a year or as necessary especially in an incident that is believed to significantly
impact trustworthiness of the CA.

6.4. Activation data

6.4.1. Activation data generation and installation

Activation data such as Personal Identification Number (PIN) and passwords for accessing the NCA
Root CA systems are user-selected and protected under multi-person control by each of whom holding
that activation data. NCA Root CA shall use the same data generation mechanism.

6.4.2. Activation data protection

NCA operated under this CP shall protect activation data used to unlock private keys by storing the
data in secure location.

6.4.3. Other aspects of activation data

NCA Root CA activation data must only be held by NCA Root CA personnel in trusted roles.

6.5. Computer security controls

NCA Root CA must implement multi-person control access to private keys and information such as
sensitive details about customer accounts and passwords. Security procedures are in place to prevent
and detect unauthorized access, modification, malicious code or compromise of the NCA Root CA
systems such as firmware and software. Such security controls are subject to compliance assessment
as specified in section 8.

6.5.1. Specific computer security technical requirements

NCA Root CA shall limit the number of applications installed on each computer to minimize security
risks. Operating System and those applications shall be hardened based on the instructions provided

Page 48 of 61
by software manufacturer. In addition, operating system and installed applications shall be regularly
reviewed for security updates to ensure those are free of vulnerabilities.

6.5.2. Computer security rating

No stipulation.

6.6. Life-cycle technical controls

6.6.1. System development controls

NCA Root CA must implement system development controls over the procurement, development and
change of the NCA Root CA system through aspects of its life-cycle. NCARoot CA systems are
implemented and tested in a non-production environment prior to implementation in a production
environment. Change control procedures are in place to control and monitor all revisions and
enhancements to be made to the components of such systems.

6.6.2. Security management controls

The configuration of the NCA Root CA as well as any modifications and upgrades shall be documented
and controlled. There shall be a mechanism for detecting unauthorized modification to the NCA Root
CA software or configuration. A formal configuration management methodology shall be used for
installation and ongoing maintenance of the NCA Root CA system. The NCA Root CA software, when
first loaded, shall 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

NCA Root CA network must equip with firewall with features to block intruders or network activities
that violate policy. Unused network ports and services shall be turned off. It is to ensure that system
is secure.

Normal users allow accessing the certificate services through the network via the website and
directories only. For system management, certification authority officers will use dedicated network
to access and management purpose.

Page 49 of 61
 6.8. Time stamping

The system clock will be set in the time setting device (NTP Server) which shall be accurate to within
three minutes. Any recording time in the system will refer to the same time setting device.

Page 50 of 61
7. CERTIFICATE, CRL AND OCSP PROFILES

7.1. Certificate Profile

NCA issues certificates that are conformed to the ITU-T Recommendation X.509 (11/08) : Information
technology - Open systems interconnection - The Directory: Public-key and attribute certificate
frameworks and ISO/IEC 9594-8:2008 Information technology standard. - Open Systems
Interconnection - The Directory: Public-key and attribute certificate frameworks. This section
describes the attributes of certificates issued by NCA.

7.1.1. Version Number

Certificate issued by CA is in accordance with ITU-T Recommendation X.509 standard ISO / IEC 9594-
8:2008 and designated to be version 3.

7.1.2. Certificate Extensions

NCA Root CA shall issue Certificates in compliance with RFC 5280 and applicable best practice including
compliance to then current CA/B Forum Baseline Requirements sections 7.1.2.1 through 7.1.2.5.
Criticality shall also follow best practice and where possible prevent unnecessary risks to Relying
Parties when applied to name constraints.

7.1.3. Algorithm Object Identifiers

The OIDs of digital signature and encryption of certificate is shown below.

Algorithm Object Identifier

RSAEncryption 1.2.840.113549.1.1.1
SHA512withRSAEncryption 1.2.840.113549.1.1.13
SHA512 2.16.840.1.101.3.4.2.3

7.1.4. Name Forms

The name format of Issuer and Subject are specified in the certificate as reference to the section 3.1.1.

7.1.5. Name Constraints

Not Applicable.

7.1.6. Certificate Policy Object Identifier

NCA Root CA follows Section 7.1.6 of CA/B Forum Baseline Requirements.

Page 51 of 61
 7.1.7. Usage of Policy Constraints Extension

Not Applicable.

7.1.8. Policy Qualifiers Syntax and Semantics

Not Applicable.

7.1.9. Processing Semantics for the Critical Certificate Policies Extension

Not Applicable.

7.2. CRL Profile

7.2.1. Version Number(s)

NCA Root CA and CSPs shall issue version 2 CRLs that conform to RFC 5280.

7.2.2. CRL and CRL Entry Extensions

CRLs have the following extensions: CRL Number and Authority Key Identifier

7.3. OCSP Profile

NCA Root CA shall operate an OCSP service in accordance with RFC 6960.

7.3.1. Version Number(s)

NCA Root CA and CSPs shall support version 1 OCSP requests and responses.

7.3.2. OCSP Extensions

No stipulation.

Page 52 of 61
8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

NCA Root CA have compliance audit mechanism in place to ensure that the requirements of their CPS
are being implemented and enforced.

8.1. Frequency or circumstances of assessments

NCA Root CA shall be subject to a periodic compliance audit in respect of Trust Service Principles and
Criteria for Certification Authorities Version 2.0 or latest at least once a year.

8.2. Identity/ qualifications of assessor

The auditor must demonstrate competence in the field of compliance audits, and must be thoroughly
familiar with the CA’s CPS and this CP. Assessment must be done by WebTrust for CA and WebTrust
for SSL Baseline with Network Security 2.3 or later certified auditors with the understanding of the
certification service business.

8.3. Assessor’s relationship to assessed entity

The compliance assessor either shall be a private firm, which is independent from the entities (NCA
and accredited CSPs) being audited, or it shall be sufficiently organizationally separated from those
entities to provide an unbiased, independent evaluation.

8.4. Topics covered by assessment

The purpose of compliance audit is to verify that a CA and its RAs comply with all the requirements of
the current version of this CP and the CA’s CPS. The scope of assessment shall follow that in the
WebTrust for CA and WebTrust for SSL Baseline with Network Security 2.3 or later.

8.5. Actions taken as a result of deficiency

CA’s officers must plan to improve deficiencies (Non-conformity) based on the assessment results with
explicit operating time. The plan will be submitted to auditors to ensure that sufficient security of the
system is still in place.

8.6. Communication of results

After the assessment is completed, the audit compliance report and identification of corrective
measures will be sent to NCA Task Force within 30 days of completion.

Page 53 of 61
 8.7. Self-Audits

The NCA Root CA shall perform regular internal audits of its operations, personnel, and compliance
with this CP and strictly control its service quality. The NCA Root CA shall perform these self-audits at
least on a quarterly basis.

Page 54 of 61
9. OTHER BUSINESS AND LEGAL MATTERS

9.1. Fees

9.1.1. Certificate issuance and renewal fees

NCA shall charge a fee including re-issuance fee for certificate issued to CSPs.

9.1.2. Certificate access fees

There will not be any fees for accessing the certificates.

9.1.3. Revocation or status information access fees

NCA Root CA and Accredited CSPs may not charge any fees for accessing any revocation status
information.

9.1.4. Fees for other services

NCA Root CA and Accredited CSPs may set any reasonable fees for any other services.

9.1.5. Refund policy

NCA Root CA and Accredited CSPs may, but are not required to, have a documented refund policy.

9.2. Financial responsibility

9.2.1. Insurance coverage

No stipulation.

9.2.2. Other assets

No stipulation.

9.2.3. Insurance or warranty coverage for end-entities

No stipulation.

9.3. Confidentiality of business information

9.3.1. Scope of confidential information

NCA Root CA shall define the scope of confidential information within its CPS.

Page 55 of 61
 9.3.2. Information not within the scope of confidential information

Any information not defined as confidential within the CPS shall be deemed public. Certificate status
information and Certificates themselves are deemed public.

9.3.3. Responsibility to protect confidential information

NCA Root CA shall protect confidential information and enforce protection of confidential information
through training and contracts with employees, agents and contractors.

9.4. Privacy of personal information

9.4.1. Privacy plan

NCA Root CA shall protect personal information in accordance with its privacy policy.

9.4.2. Information treated as private

NCA Root CA shall treat all information received from Applicants that will not ordinarily be placed into
a Certificate as private. This applies both to those Applicants who are successful in being issued a
Certificate and those who are unsuccessful and rejected. NCA Root CA periodically train all NCA staff
as well as anyone who has access to the information about due care and attention that must be
applied.

9.4.3. Information not deemed private

Certificate status information and any Certificate content is deemed not private.

9.4.4. Responsibility to protect private information

NCA Root CA is responsible for securely storing private information and may store information
received in either paper or digital form. Any backup of private information must be encrypted when
transferred to suitable backup media.

9.4.5. Notice and consent to use private information

Personal information obtained from Applicants during the application and enrolment process is
deemed private and permission is required from the Applicant to allow the use of such information.

9.4.6. Disclosure pursuant to judicial or administrative process

NCA Root CA may disclose private information, without notice, when required to do so by law or
regulation.

Page 56 of 61
 9.4.7. Other Information Disclosure Circumstances

No stipulation.

9.5. Intellectual property rights

CA is the only owner of intellectual property rights associated with the certificate, certificate
revocation information, Certificate policy and certificate practice statement. CAs shall not knowingly
violate any intellectual property rights.

9.6. Representations and warranties

9.6.1. CA representations and warranties

NCA Root CA and Accredited CAs represent and warrant that:

• Their CA signing private key is protected and that no unauthorized person has ever had access
to that private key;
• All representations made by the accredited CA in any applicable agreements are true and
accurate, to the best knowledge of the applicable CA; and
• Each Subscriber has been required to represent and warrant that all information supplied by
the Subscriber in connection with, and/or contained in the Certificate is true.
• Only verified information appears in the certificate
• Procedures are implemented in accordance with their CPs.
• The CA operation is maintained in conformance to the stipulations of the CPS.

9.6.2. RA representations and warranties

At a minimum, NCA Root CA shall require RA of NCA Root CA to follow this CP and the relevant CPS
when participating in the issuance and management of Certificates.

9.6.3. Subscriber representations and warranties

A Subscriber shall be required to sign a document (e.g., a subscriber agreement) containing the
requirements listed below.

• Subscriber accurately represents itself in all communications with the CA.

• The private key is properly protected at all times and inaccessible without authorization.
• The CA is promptly notified when the private key is suspected loss or compromise.
• All information displays in the certificate is complete and accurate.

Page 57 of 61
 • The certificate will be used legitimately under laws, related regulations, terms, conditions and
other related service announcements of the CA by authorized persons.

9.6.4. Relying party representations and warranties

In case of relying party representations use the certificate, the relying party shall properly verify
information inside the certificate before use and accepts the fault of single side verification.

9.6.5. Representations and warranties of other participants

No stipulation.

9.7. Disclaimers of warranties

NCA Root CA operating under this policy may not disclaim any responsibilities described in this CP. To
the extent permitted by applicable law and any other related agreements, accredited CSPs may
disclaim all warranties (other than any express warranties contained in such agreements or set forth
in the accredited CSP’s CPS).

9.8. Limitations of liability

CSP is responsible for any damage incurred in the event of damage caused by the use of the service
stems from the willful act or gross negligence of the corresponding CSP. The response to the damage
is under determination of CSP.

NCA Root CA shall make statements in their CPS to the effect that in no event (except for fraud or
willful misconduct) is the CSP liable for:

• Any loss of profits;

• Any loss of data;

• Any indirect, consequential or punitive damages arising from or in connection with the use,
delivery, license, and performance or non-performance of Certificates or Digital Signatures;

• Any transactions or services offered or within the framework of this CP;

• Any other damages except for those due to reliance on the verified information in a
Certificate, except for information featured on, free, test or demo Certificates; and

• Any liability incurred in any case if the error in such verified information is the result of fraud
or willful misconduct of the Applicant.

Page 58 of 61
 9.9. Indemnities

In case of the damage occurs to the CA from the actions of subscribers or relying parties, the
corresponding CA reserves the right to claim damages.

9.10. Term and Termination

9.10.1. Term

The CP becomes effective upon ratification by the NCA Task Force. Amendments to this CP become
effective upon ratification by the NCA Task Force and publication at https://www.nca.gov.lk.

There is no specified term for this CP.

9.10.2. Termination

While this CP may be amended from time to time, it shall remain in force until replaced by a newer
version or explicitly terminated by the NCA Task Force.

9.10.3. Effect of termination and survival

Upon termination of this CP, CSPs are nevertheless bound by its terms for all Certificates issued for
the remainder of the validity periods of such Certificates. The following sections of this CP shall survive
the termination or expiration of this CP.

9.11. Individual notices and communications with participants

CA will communicate to those participants using reliable channel as soon as possible in accordance
with the importance of information.

9.12. Amendments

9.12.1. Procedure for amendment

NCA shall review this CP at any time at the discretion of NCA Task Force. The amendment shall be
performed under laws, regulation or other related service announcements of NCA.

If the NCA Task Force wishes to recommend amendments or corrections to this CP, such modifications
shall be circulated to the CSPs. Comments from the CSPs shall be collected and adjudicated by the
NCA Task Force.

NCA shall use commercially reasonable efforts to immediately notify CSPs of changes.

Page 59 of 61
 9.12.2. Notification mechanism and period

In case there are any significant changes to this CP, NCA will announce on its website within one week
of approval from the NCA Task Force.

9.12.3. Circumstances under which OID must be changed

No Stipulation.

9.13. Dispute resolution provisions

Before resorting to any dispute resolution mechanism, including adjudication or any type of
alternative dispute resolution, a party must notify NCA Root CA of the dispute with a view to seek
dispute resolution.

NCA Root CA shall state in its CPS a dispute resolution clause and procedures to resolve disputes and
claims between NCA Root CA and CSPs.

9.14. Governing law

The laws of the Democratic Socialist Republic of Sri Lanka shall govern this CP.

9.15. Compliance with applicable law

All CAs operating under this CP are required to comply with the laws of the Democratic Socialist
Republic of Sri Lanka.

9.16. Miscellaneous Provisions

9.16.1. Entire agreement

CPS of a CA operating under this CP shall be considered as part of the agreement between CA and the
subscribers.

9.16.2. Assignment

Except where specified by other contracts, no party may assign or delegate this CP or any of its rights
or duties under this CP, without the prior written consent of the other party (such consent not to be
unreasonably withheld), except that NCA may assign and delegate this CP to any party of its choosing.

9.16.3. Severability

If any provision of this CP is held to be invalid by a court of competent jurisdiction, then the remaining
provisions will nevertheless remain in full force and effect.

Page 60 of 61
 9.16.4. Enforcement

Should it be determined that any section of this CP is illegal, unenforceable, or void, then any offending
words in it will be deleted to the extent necessary to make it legal and enforceable while preserving
its intent.

9.16.5. Force majeure

CSPs shall not be liable for any failure or delay in its performance under this CP due to causes that are
beyond their reasonable control, including, but not limited to, act of civil or military authority, fire,
epidemic, flood, earthquake, national emergency riot, war, failure of equipment, failure of
telecommunications lines, lack of Internet access, sabotage, and governmental action.

9.17. Other provisions

No stipulation.

Page 61 of 61