Qatar Ministry of Interior - Public Key Infrastructure ... · Qatar Ministry of Interior - Public...

of 58

Qatar Ministry of Interior - Public Key Infrastructure

Certificate Policy

Issue : 1.2

Issue date : 19 October 2014

Status : Approved

Qatar Ministry of Interior PKI Certificate Policy

page 2 of 58

Amendment history

Date Issue Status Changes Author

27/08/2014 1.0 Approved Issue final version MoI Policy Authority

28/09/2014 1.1 Approved

Adding Final OID values

and hosting URLs MoI Policy Authority

19/10/2014 1.2 Approved

Updating OID values MoI Policy Authority


page 3 of 58

Detailed contents

1 Introduction .................................................................................................................................................. 6

1.1 Overview ........................................................................................................................................... 6

1.2 Document name and Identification .................................................................................................. 7

1.3 PKI Participants ................................................................................................................................. 8

1.4 Certificate Usage ............................................................................................................................. 11

1.5 Policy Administration ...................................................................................................................... 12

1.6 Definitions, Acronyms and References ........................................................................................... 13

2 Publication and Repository Responsibility ................................................................................................. 17

2.1 Repositories .................................................................................................................................... 17

2.2 Publication of Certificate Information ............................................................................................ 17

2.3 Time or Frequency of Publication Repositories .............................................................................. 17

2.4 Access Controls on Repositories ..................................................................................................... 17

3 Identification and Authentication .............................................................................................................. 19

3.1 Naming ............................................................................................................................................ 19

3.2 Initial Identity Validation ................................................................................................................. 21

3.3 Identification and Authentication for Re-keying requests .............................................................. 23

4 Certificate Life Cycle Management ............................................................................................................ 25

4.1 Certificate Application ..................................................................................................................... 25

4.2 Certificate Application Processing................................................................................................... 26

4.3 Certificate Issuance ......................................................................................................................... 27

4.4 Certificate Acceptance .................................................................................................................... 27

4.5 Key Pair and Certificate Usage ........................................................................................................ 28

4.6 Certificate Renewal ......................................................................................................................... 28

4.7 Certificate Re-key ............................................................................................................................ 29

4.8 Certificate Modification .................................................................................................................. 29


page 4 of 58

4.9 Certificate Revocation and Suspension ........................................................................................... 30

4.10 Certificate Status Services ............................................................................................................... 33

4.11 End of Subscription ......................................................................................................................... 33

4.12 Key Escrow and Recovery ................................................................................................................ 33

5 FACILITY, MANAGEMENT and OPERATIONAL CONTROLS .......................................................................... 34

5.1 Physical Controls ............................................................................................................................. 34

5.2 Procedural Controls ........................................................................................................................ 35

5.3 Personnel Controls .......................................................................................................................... 36

5.4 Audit Logging Procedures ............................................................................................................... 37

5.5 Records Archival .............................................................................................................................. 38

5.6 Key Changeover .............................................................................................................................. 39

5.7 Compromise and Disaster Recovery ............................................................................................... 39

5.8 CA or RA Termination ...................................................................................................................... 40

6 TECHNICAL SECURITY CONTROLS ............................................................................................................... 41

6.1 Key Pair Generation and Installation .............................................................................................. 41

6.2 Private Key Protection and Cryptographic Module Engineering Controls ...................................... 42

6.3 Other Aspects of Key Pair Management ......................................................................................... 44

6.4 Activation Data ................................................................................................................................ 45

6.5 Computer Security Controls ............................................................................................................ 45

6.6 Life Cycle Technical Controls ........................................................................................................... 46

6.7 Network Security Controls .............................................................................................................. 46

6.8 Time-Stamping ................................................................................................................................ 47

7 CERTIFICATE, CRL PROFILES ........................................................................................................................ 48

7.1 Certificate Profile .......................................................................................................................... 48

7.2 CRL Profile .................................................................................................................................... 54

8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS ....................................................................................... 56


page 5 of 58

9 OTHER BUSINESS AND LEGAL MATTERS .................................................................................................... 57

9.1 Fees 57

9.2 Financial responsibility .................................................................................................................... 57

9.3 Confidentiality of business information .......................................................................................... 57

9.4 Privacy of personal information ...................................................................................................... 57

9.5 Intellectual property rights ............................................................................................................. 57

9.6 Representations and warranties ..................................................................................................... 57

9.7 Disclaimers of warranties ................................................................................................................ 57

9.8 Limitations of Liability ..................................................................................................................... 57

9.9 Indemnities ..................................................................................................................................... 57

9.10 Term and termination ..................................................................................................................... 57

9.11 Individual notices and communications with participants ............................................................. 57

9.12 Amendments ................................................................................................................................... 57

9.13 Dispute resolution provisions ......................................................................................................... 58

9.14 Governing Law ................................................................................................................................ 58

9.15 Compliance with applicable law ...................................................................................................... 58

9.16 Miscellaneous provisions ................................................................................................................ 58

9.17 Other provisions .............................................................................................................................. 58


page 6 of 58

1 Introduction

1.1 Overview

This Certificate Policy (CP) defines the requirements applicable to the Ministry of Interior (MoI) Subordinate Certification Authorities (CAs) that come in the second level of Qatar national Public Key Infrastructure (QPKI) hierarchy. The MoI Subordinate CAs are sometimes referenced as MoI PKI in this CP document. These CAs will be set up and operated by the MoI for issuing end-entity certificates (identity certificates, corporate certificates and infrastructure certificates).

The Supreme Council of Information and Communication Technology (ictQATAR) is fulfilling the role of the Policy Management Authority for Certification Services Providers in Qatar (referred to as the CSPs-PMA). Hence, the certification services from the MoI as well as certification services from any CSP willing to operate in the state of Qatar shall be licensed by the CSPs-PMA before starting issue of certificates or providing services related to electronic signatures.

Licensed certification services shall be root-signed by Qatar National Root–Certification Authority (NR-CA) that is the first level in the QPKI hierarchy. In practice, this means that the MoI Subordinate CAs issuing certificates to end-entities being granted a license by the CSPs-PMA will be issued with a certificate signed by the NR-CA.

The MoI Subordinate CAs deliver national Public Key Infrastructure (PKI) certification services that enable citizens, residents and corporate organizations to conduct secure electronic transactions. This PKI and the related certification services are provided and operated by the MoI of the state of Qatar in its quality of a CSP licensed by the CSPs-PMA. The PKI certification services are offered by the MoI in accordance with the present CP and a dedicated Certification Practice Statement (CPS) for each Subordinate CA.

The MoI shall set up a PKI board that will represent the policy and governing body for its PKI. This board is referred to in this CP document as the Policy Authority (PA).

The MoI shall also delegate the operations of its PKI to a trusted and reliable Operational Authority (OA) within its secure facilities. The OA personnel shall be accountable for the actions they perform and controls shall be in place to ensure that evidence is available to link any action to the person performing it.

1.1.1 QPKI Hierarchy

The figure below illustrates the QPKI hierarchy.

The NR-CA is the top authority in Qatar with regard to digital certification services offered in Qatar.

The NR-CA issues top level certificates to CAs operated by CSPs licensed by the Qatar CSPs-PMA. The MoI Subordinate CAs in its quality of a licensed CSP has the following CAs certified by the NR-CA:

- Citizen and Resident CA: Issuing certificates to Qatari citizens and residents

- Business and Corporate CA: Issuing certificates to corporate and business entities


page 7 of 58

- Infrastructure CA: Issuing website and VPN certificates

CSPs-PMANational Root CA

CSPs-PMANational Root CA

Citizen & Resident CA

Citizen & Resident CA

Business and Corporate CA

Business and Corporate CA Infrastructure CA Infrastructure CA

Identity encryption

certs

OCSP certsWeb certs VPN certsIdentity

signing certs

Corporate encryption

certs

OCSP certsCorporate

signing certs

OCSP certs

1.1.2 Certification Services

The certification services offered by the MoI Subordinate CAs are broken down in this document as follows:

Registration service: Verifies the identity and, if applicable, any specific attributes of end-entities applying for certificates. The results of this service are passed to the certificate generation service.

Certificate generation service: Creates and signs end-entity certificates based on the verification conducted by the registration service.

Dissemination service: Disseminates the end-entity certificates and makes them available to relying parties. This service also makes available any public policy and practice information to subscribers and relying parties.

Suspension and Revocation management service: Processes requests and reports relating to revocation to determine the necessary action to be taken. The results of this service are distributed through the certificate validity status service.

Certificate validity status service: Provides certificate validity status information to relying parties. This shall be based upon certificate suspension/revocation lists. The status information shall always reflect the current status of the certificates issued by the MoI Subordinate CAs.

1.2 Document name and Identification

This document is named ‘Qatar Ministry of Interior PKI CP’ and is referenced in related documents as QATAR-MoI-PKI CP.

The Object Identifier (OID) of this document is 2.16.634.1.1.2.1.1.


page 8 of 58

1.3 PKI Participants

The participants in the MoI PKI are as follows:

Certification Authorities

Policy Authority

Operational Authority

Registration Authority (RA)

Local Registration Authority (LRA)

Subscribers

Relying Parties

These participants and their roles are described in the following sections.

1.3.1 Certification Authorities

The table below lists the CAs operated by the MoI and the certificates issued by these CAs.

Certification Authority Supported certificates

Citizen and Resident CA X.509 (V3) end-user certificates for Qatari citizens and residents in addition to Online Certificate Status Protocol (OCSP) response signing certificates for MoI OCSP responder.

Business and Corporate CA X.509 (V3) certificates for business and corporate end-users in addition to OCSP response signing certificates for MoI OCSP responder.

Infrastructure CA X.509 (V3) end-entity certificates for infrastructure servers (SSL and VPN certificates) in addition to OCSP response signing certificates for MoI OCSP responder.

The key responsibilities of the MoI Subordinate CAs are as follows:

Issue and manage certificates

Publish encryption certificates to a public repository accessed by Relying Parties

Issue and publish Certificate Revocation List (CRL) to a public repository accessed by Relying Parties

Push CRLs to the MoI OCSP responder

All certificates issued by the MoI Subordinate CAs shall conform to the rules and requirements as stated in this policy document.

1.3.2 Policy Authority

The MoI shall set up a PA so that it becomes the policy and governing body for its PKI.

The overall responsibility of the PA shall be as follows:

Specifying and approving the MoI Subordinate CAs infrastructure

Specifying and approving the changes required to this CP and other related documentation (such as CPS) as well as authorizing the publication of these


page 9 of 58

documents

Organizing key ceremonies including allocating members to the key ceremonies

Organizing regular audits to be conducted by internationally recognized auditing firms

Specifying and maintaining the overall Disaster Recovery and Business Continuity plan for the MoI Subordinate CAs

The PA shall be represented by individuals with security clearance.

1.3.3 Operations Authority

The MoI PKI shall be operated by the OA that has the overall responsibility of the day-to-day operational tasks. The OA team operates the PKI within the MoI secure facility, where the PKI infrastructure is deployed.

The OA shall be represented by individuals with security-clearance.

1.3.4 Registration Authority

The MoI shall set up an RA organization for its subordinate CAs. The RA shall comprise the individuals and systems involved in validating the identity of individuals requesting certificates as well as in issuing and managing these certificates.

The table below summarizes the RAs of the MoI subordinate CAs.

Certification Authority

RA function

Citizen and Resident CA

- Citizen and resident ID card certificates: The MoI operates

the Qatari National Population Register & ID Card infrastructure.

Citizens and residents visit the dedicated site from where they

apply for ID cards. A dedicated sub-system of the MoI is

referred to as the Post Issuance Personalization (PIP), which

triggers PKI certificates life cycle operations for ID cards. The

PIP plays the function of the RA for the Citizen and resident CA.

- Citizen and resident Virtual ID certificates through Hukoomi

portal: Virtual ID certificates are issued to citizens and residents

through the Qatari National e-Services portal (Hukoomi). The

end users access a dedicated section of Hukoomi after two-

factor authentication with their ID card. They can then undergo a

process through which Virtual ID key pairs and certificates are

issued to him. The Hukoomi portal plays the role of RA for

Virtual ID certificates issuance.

- Citizen and resident Virtual ID certificates through MoI

kiosks: Virtual ID certificates can also be obtained by citizens

and residents through dedicated kiosk machines deployed

within the MoI immigration sites. The end user (citizen or

resident) is authenticated by the kiosk, which then triggers the

issuing of virtual ID key pairs and certificates. The MoI kiosk

system plays the role of RA for Virtual ID certificates issuance.


page 10 of 58

- Citizen and resident Virtual ID certificates through MoI RA:

Virtual ID certificates can also be obtained through a dedicated

face-to-face process with the MoI RA. The MoI OA plays the

role of the RA in this context.

- OCSP certificates: The OA plays the role of RA for MoI OCSP

responder certificate life cycle management.

- The MoI OA team plays the role of RA for certificate revocation

for any of the certificates issued by the Citizen and Resident

CA.


- Business and Corporate certificates through MoI RA:

Corporate and business entities may request key pairs and

certificates from the MoI, which they received on hardware

tokens (e.g. smartcards). The MoI OA plays the role of the RA

for these type of certificates. This includes certificate issuance

and revocation.

- Business and Corporate certificates through LRA: The MoI

OA in its role as an RA for the Business and Corporate CA

registers LRA officers to the system so that these officers could

then generate and manage the digital certificates of their

community of users. See LRA section in this policy document

for further details.

- Business and Corporate virtual certificates through LRA:

Corporate and business entities may receive virtual ID

certificates from the MoI. These certificates are managed by

dedicated LRA acting on behalf of an entity. See the LRA

section of this policy for further details.

- OCSP certificates: The OA plays the role of RA for MoI OCSP

responder certificate life cycle management.

Infrastructure CA Infrastructure certificates through MoI RA: The MoI OA team plays the role of RA for infrastructure certificate management.

OCSP certificates: The OA plays the role of RA for MoI OCSP responder certificate life cycle management.

1.3.5 Local Registration Authority

The MoI offers LRA services to organizations willing to manage the certificates life cycle for their own communities. This service is only offered for the Business and Corporate CA.

The organization willing to use the LRA service shall sign an agreement with the MoI through which it commits to use the LRA service from the MoI in accordance with the Business and Corporate CA CP and CPS documents.

The organization that opts for the LRA service appoints an LRA officer. He will be enrolled to the MoI Business and Corporate CA by the MoI RA as an administrator having the


page 11 of 58

credentials to enroll and manage the subscribers of the organization that the LRA officer represents.

The LRA officer duties shall be as follows:

Collecting and validating the subscribers identity data

Conforming to the rules of this CP and related CPS of the Business and Corporate CA

Issuing and managing certificates of the organization subscribers

1.3.6 Subscribers

Subscribers of the MoI PKI are listed in the below table

Certification Authority Subscribers

Citizen and Resident CA Qatari citizens and residents receiving identity certificates for their own use

Business and Corporate CA Qatari citizens and residents receiving identity certificates and acting on behalf of the corporate of business organization they work for

Infrastructure CA Infrastructure devices such as OCSP responder, Time stamping Authority (TSA), VPN’s, Web Servers, Routers, Switches and other devices

For certificates issued to individuals, the subscriber shall sign a subscriber agreement for the corresponding CA.

For infrastructure certificates, a legitimate sponsor or authorized device administrator shall sign a subscriber agreement for the infrastructure CA.

1.3.7 Relying Parties

A Relying Party is any entity within the state of Qatar that processes a digital certificate issued by the MoI CAs.

1.3.8 Other Participants

There are no other participants for Qatar National PKI.

1.4 Certificate Usage

1.4.1 Appropriate Certificate Use

The certificates issued from the MoI PKI fall in two categories:

Certification Authority Certificate use

Citizen and Resident CA A Qatari citizen or resident who applies for PKI credentials receives two key pairs and related certificate as follows: - Encryption key pair with related encryption certificate

used for:

o Secure email


page 12 of 58

o Document/data encryption

- Signature key pair and related certificate used for:

o Authentication

o Signing digital transactions

The Citizen and Resident CA also issues OCSP certificates intended for the MoI OCSP responder to sign OCSP tokens.

Business and Corporate CA The certificates issued by the Business and Corporate CA have the same use as those issued by the Citizen and Resident CA. A Qatari citizen or resident acting on behalf of an organization applies and receives two key pairs and related certificates and related certificates as follows: - Encryption key pair with related encryption certificate

used for:

o Secure email

o Document/data encryption

- Signature key pair and related certificate used for:

o Authentication

o Signing digital transactions

The Business and Corporate CA also issues OCSP certificates intended for the MoI OCSP responder to sign OCSP tokens.

Infrastructure CA Appropriate certificate usage of this category shall be as follows: - SSL Server Certificates: Used for server authentication

and session data encryption.

- VPN Certificates: Used for device identification and

session data encryption for IPSec-based connections.

- TSA certificates intended for the MoI TSA server.

- OCSP certificates intended for the MoI OCSP

responder to sign OCSP tokens.

1.4.2 Prohibited Certificate Use

Certificates referenced in this CP document shall not be used for purposes other than the ones listed above under section 1.4.1 of this policy document. Using certificates for other purposes is explicitly prohibited.

1.5 Policy Administration

1.5.1 Organization Administering the Document

This document shall be administered by the MoI PA.

1.5.2 Contact Details

Inquiries, suggested changes, or notices regarding this CP should be directed to:


page 13 of 58

MoI PKI Policy Authority

Contact person: Capt. Ahmad Al-Hamar / Dr. Capt Jassim Al-Hamar

Address (PO Box): PO Box: 6858, Duhail Area, Doha, Qatar

Phone: +974-55558343

email: [email protected]

1.5.3 Person Determining CPS Suitability for the Policy

The MoI PA determines the suitability of any CPS for this CP.

1.5.4 CP\CPS Approval Procedures

Approval of this CP and subsequent amendments shall be made by the MoI PA. Amendments shall either be in the form of a document containing an amended form of the CP or an update notice. Updates shall supersede any designated or conflicting provisions of the referenced version of the CP

1.6 Definitions, Acronyms and References

Definitions and Acronyms

The following sections contain the definitions of terms and acronyms. The source of a definition is cited when available.

Activation data — Secret information, other than cryptographic keys, that are required to operate cryptographic modules that need to be protected, for example, a PIN, a password or pass-phrase, or a manually-held key share

CA – Certification Authority

CA certificate – A certificate for one CA’s public key issued by another CA

CCTV – Closed Circuit TV

Certificate Policy (CP) – 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

Certification Practice Statement (CPS) – A statement of the practices which a certification authority employs in issuing, certificates

CRL – Certificate Revocation List

DRP – Disaster Recovery Plan

DN – Distinguished Name


page 14 of 58

FIPS – Federal Information Processing Standards HSM – Hardware Security Module - a device designed to provide cryptographic functions especially the safekeeping of private keys.

HTTP – Hyper Text Transfer Protocol

HVAC – Heating, Ventilation and Air Conditioning

IEC – International Electro-technical Commission

IETF – Internet Engineering Task Force

IPSEC – Internet Protocol Security

ISO – International Standards Organization

Issuer – The name of the CA that signs the certificate

Issuing certification authority (issuing CA) – In the context of a particular certificate, the issuing CA is the CA that issued the certificate

ITU – International Telecommunications Union

KGC – Key Generation Ceremony, the complex procedure for the generation of a CA’s private key

LDAP – Lightweight Directory Access Protocol - a common standard for accessing directories

MoI – Ministry of Interior

MoI-IO – Ministry of Interior’s Immigration Offices.

MoI-IS – Ministry of Interior’s Information Services Department

OA – Operational Authority – The team within MoI-ISD in charge of operating MOI PKI

OID – Object Identifier - A value (distinguishable from all other such values) which is associated with an object. (ITU-T X680) Referenced in many RFCs and used in the ASN.1 encoding of certificates

OSCP – Online Certificate Status Protocol

PA – Policy Authority

PED – PIN Entry Device

PIN – A Personal Identification Number or password used to protect the private information and keys on hardware tokens

PUC – PIN unblock code


page 15 of 58

PKCS # 1 – Public-Key Cryptography Standards (PKCS) #1

PKCS # 7 – Cryptographic Message Syntax

PKCS #10 – Certification Request Syntax Specification

PKCS #12 – Personal Information Exchange Syntax published by RSA Security

PKE – Public Key Encryption

PKI – Public Key Infrastructure

PKIX-CMP – Internet X.509 Public Key Infrastructure - Certificate Management Protocol

Policy qualifier – Policy-dependent information that accompanies a certificate policy identifier in an X.509 certificate

QID – Qatar Identity – The State of Qatar citizen and resident card identity scheme. Each card is assigned a unique number linked to that individual QPKI – Qatar Public Key Infrastructure

RA – Registration Authority

Re-key – Ceasing use of a key pair and then generating a new key pair to replace it

Relying party – A recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate

Renewal – Issuance of a new certificate to the subscriber without changing the subscriber’s public key or any other information in the certificate

Repository – A trustworthy system for storing and retrieving certificates or other information relevant to certificates

RSA – The acronym for the inventors of the RSA algorithm - Ron Rivest, Adi Shamir and Leonard Adleman

SCEP – Simple Certificate Enrolment Protocol

Secret Shares – A set of devices, smart cards, PINs etc. used with MofN control

SHA – Secure Hash Algorithm

S/MIME – Secure Multipurpose Internet Mail Extensions

SSL/TLS – Secure Sockets Layer/Transport Layer Security

Sponsor – An individual or organization, authorized to vouch for another individual in their employment, or an electronic device in their control

subjectAltName – A certificate attribute field that often contains the subject’s email address.


page 16 of 58

Subject – A subject is the entity named in a certificate

Subscriber – A subject who is issued a certificate

Trusted Role – Those individuals who perform a security role that is critical to the operation or integrity of a PKI

UPS – Uninterruptible Power Supply

URI – Universal Resource Identifier, a URL, FTP address, email address, etc. VSC – Virtual Smart Card: Virtual ID credential where the key pair is generated and stored on a highly secure backend system

X.501 – A common standard for directory entry naming (ITU)

X.509 – A public key certificate specification originally developed as part of the X.500 directory specification, often used in public key systems. It is now governed by IETF standards.

References

[RFC3647] Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework

[RFC5280] “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”

[ETSI 319 411-3] ETSI EN 319 411-3 V1.1.1 (2013-01) Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 3: Policy Requirements for Certification Authorities issuing public key certificates

[ETSI 102 042] ETSI TS 102 042 V2.2.1 (2011-12) Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates


page 17 of 58

2 Publication and Repository Responsibility

2.1 Repositories

The MoI shall operate the repositories for the Subordinate CAs. The core repository shall be a Lightweight Directory Access Protocol (LDAP) directory server where CA certificates and CRLs are published. The MoI shall also create a replica of the main LDAP referenced as public LDAP that will be published and made available to relaying parties.

Other than the public LDAP repository, the MoI shall maintains a PKI web portal where relevant PKI documentation is published for relying parties including CP and CPS.

2.2 Publication of Certificate Information

The following certificate information shall be published and made available on the MoI public LDAP:

Encryption public key certificates issued by each Subordinate CA

MoI CA certificates

MoI OCSP and TSA certificates

CRLs

2.3 Time or Frequency of Publication Repositories

2.3.1 Certificates

The below Certificates shall be published to the public repository (MoI Public LDAP) once they are issued:

CA, TSA and OCSP certificates

Encryption Certificates

2.3.2 CRL’s

The following rules shall apply for the CRL issued by the MoI Subordinate CAs managed by this policy document:

At minimum, CRLs shall be refreshed every 24 hours.

CRLs lifetime shall be set to 26 hours (24 hours update period + 2 hours pre-update period).

2.4 Access Controls on Repositories

Public read-only access to the CP, CPS, certificates and CRLs published to the repository shall be available.


page 18 of 58

Access controls shall be implemented on the repository to prevent any unauthorized addition or modification of any published data.


page 19 of 58

3 Identification and Authentication

3.1 Naming

3.1.1 Types of Name

The certificates issued by the MoI CAs under this CP shall contain X.500 Distinguished Names (DN) in English. The table below summarizes the DNs of the certificates issued by the MoI CAs under this CP:

Certification Authority Distinguished Name


CA DN: cn=Citizen and Resident Certification Authority, o=QECC, c=QA

Qatari Citizens - ID card certificates: cn=<person name> <person QID>, ou=citizens, o = QECC, c = QA.

Qatari Citizens - Virtual ID (VSC) certificates: cn=<person name> <person QID>, ou= VSC_citizens, O = QECC, C = QA

Qatari residents – ID card certificates: cn=<person name> <person QID>, ou=residents, o = QECC, c = QA

Qatari residents – Virtual ID (VSC) certificates: cn=<person name> <person QID>, ou=VSC_residents, o = QECC, c = QA

MoI OCSP Responder certificates: cn = MoI OCSP, cn = Citizen and Resident Certification Authority, o = QECC, c = QA


CA DN: cn=Business and Corporate Certification Authority, o=QECC, c=QA

Certificates issued for business (private) companies through MoI RA: cn=<individual unique name| organization unique registration number>, ou = corporates, o = QECC, c = QA

Certificates issued for corporate (non-private) organizations through MoI RA: cn=<individual unique name| organization meaningful unique name >, ou = corporates, o = QECC, c = QA

Certificates issues to business (private) companies through LRA: cn=<individual unique name>, ou=< organization unique registration number >, ou = corporates, o = QECC, c = QA

Certificates issues to corporate (non-private) organization through LRA: cn=<individual unique name>, ou=< organization


page 20 of 58

meaningful unique name >, ou = corporates, o = QECC, c = QA

Virtual ID certificates issued to business (private) companies through LRA: cn=<individual unique name>, ou=< organization unique registration number >, ou = VSC_corporates, o = QECC, c = QA

Virtual ID certificates issued to corporate (non-private) organization through LRA: cn=<individual unique name>, ou=< organization meaningful unique name >, ou = VSC_corporates, o = QECC, c = QA

Infrastructure CA

CA DN: cn=Infrastructure Certification Authority, O=QECC, C=QA

Infrastructure devices: cn=<System unique common name>or<device DNS name> or <device IP address>, cn = Infrastructure Certification Authority, o = QECC, c = QA

MoI OCSP Responder certificates: cn = MoI OCSP, cn = Infrastructure Certification Authority, o = QECC, c = QA

TSA certificates: cn = MoI TSA, cn = Infrastructure Certification Authority, o = QECC, o = QA

3.1.2 Meaningful Names

Names are meaningful since the CN contains the name of the subscriber.

All end-entity certificates issued by the MoI CAs shall be meaningful and shall contain the subject’s legal name in English as well as the subject’s unique National Identity Number (IDN) for certificates issued for citizens and residents.

OCSP and TSA certificates names shall indicate the service name operated by the MoI.

Infrastructure certificates issued by the MoI Infrastructure CA shall include the name of the device.

3.1.3 Anonymity and Pseudonymity of Subscribers

This policy does not permit anonymous subscribers.

3.1.4 Rules for Interpreting Various Name Forms

No stipulation


page 21 of 58

3.1.5 Uniqueness of Names

The MoI shall enforce the controls necessary to guarantee that subject Distinguished Name (DN) are unique. The table below summarizes the minimum controls enforced for each CA.

Certification Authority Distinguished Name


Certificates issued by the Citizen and Resident CA shall include a unique identifier in the form of the Qatar Identification (QID) in the name.


Business (private) entities: The unique company registration number shall be used as part of the certificate DN to uniquely identify the company.

Corporate entities (non-private such as government entities): A convention for a meaningful representing uniquely the individual and the entity he works for shall be enforced by the MoI.

Infrastructure CA

Certificates issued by the Infrastructure CA shall uniquely identify the device. Options could be to use the registered DNS name or IP address or the system common name agreed with the MoI OA.

3.1.6 Recognition, authentication and role of Trademarks

No stipulation

3.2 Initial Identity Validation

3.2.1 Method to Prove Possession of Private Key

The MoI RAs (or LRAs) shall enforce that a Proof-of-Possession of private key is submitted as part of certificate requests. A possible implementation would be to rely on certificate requests to be processed by MoI CAs and containing a Proof-of-Possession (e.g. PKCS#10, PKIX-CMP).

3.2.2 Authentication of Organization Identity

Not applicable to MoI PKI

3.2.3 Authentication of individual identity

The table below describes the rules that apply for authentication of certificate applicants:

Certification Authority Method of authentication of individual identity


Qatari citizens/residents applying for ID card certificates: A citizen or resident who applies for ID card certificates shall have his identify validated


page 22 of 58

in face-to-face by the MoI officers at the MoI user sites.

Qatari residents/citizen applying for virtual ID (VSC) certificates: A Qatari citizen or resident shall be authenticated with a strong two-factor authentication while applying for virtual ID certificates through either Hukoomi portal or dedicated MoI kiosks. Supported two-factor authentication methods include biometric and ID card authentication.


Certificates issued for corporate and business entities through MoI RA: Any applicant for corporate or business certificates through the MoI RA shall undergo the identity validation steps:

o Appear in person before the MoI RA and bring paper work related to the certificate application and providing evidence on the link between the applicant and the organization.

o The MoI RA validates the association between the applicant and the organization.

Certificates (including virtual ID certificates) issued for corporate and business entities through an LRA: The LRA of the organization shall validate the identity of the applicant and confirm if he is authorized to receive PKI credentials from the organization.

Infrastructure CA

For any issued infrastructure certificate, the MoI RA shall validate the identity of the certificate applicant that need to appear before the RA.

3.2.4 Non-verified subscriber information

All subscriber information contained within certificate issued by the MoI CAs shall be verified by the RAs or LRAs.

3.2.5 Validation of Authority

No stipulation

3.2.6 Criteria for Interoperation

No stipulation


page 23 of 58

3.3 Identification and Authentication for Re-keying requests

3.3.1 Identification and Authentication for Routine Re-Keying

Identification and authentication for Routine Re-Key shall be same as the ones applied during initial certification.

3.3.2 Identification and Authentication for Re-Key after revocation

Identification and authentication for Routine Re-Key shall be same as the ones applied during initial certification.

3.3.3 Identification and Authentication for Revocation Request

The table below summarizes the methods that shall be enforced for identification and authentication for revocation requests:

Certification Authority Method of identification and authentication of revocation of revocation requests


The MoI RA is the single channel for the revocation of ID card or virtual ID certificates.

ID card certificates revocation: For ID card certificates revocation, the MoI RA shall receive the revocation request through a secure process with an MoI user site officer. This process is typically an ID card renewal process where the old card and its related certificates are revoked.

Virtual ID certificates revocation: For the revocation of his virtual ID card certificates, the Qatari citizen or resident shall appear before an officer at the MoI user site. His identity shall be validated by the MoI officer who collects his signature on a dedicated manual form.


Revocation of Business and Corporate certificates through MoI RA: Any request for certificate revocation that involve the authorized applicant from the organization to appear in person before the MoI RA and request revocation. The identity of the applicant is validated by the MoI RA as part of this process.

Revocation of Business and Corporate certificates (including virtual ID certificates) through an LRA: The LRA of the organization shall validate the identity of the applicant for a revocation request through a dedicated organization process.


page 24 of 58

Infrastructure CA

The MoI RA is the single channel for the revocation of infrastructure certificates. The RA shall validate the validation request and the identity of the revocation request applicant.

OCSP and TSA certificate revocation shall be conducted as part of the MoI internal processes and shall be approved by the MoI PA.


page 25 of 58

4 Certificate Life Cycle Management

4.1 Certificate Application

4.1.1 Who Can Submit a Certificate Application

Please refer to the applicable CPSs.

4.1.2 Enrolment Process and Responsibilities

Please refer to the applicable CPSs for further details.

Certification Authority Enrolment process and responsibilities


Qatari citizens/residents applying for ID card certificates: A citizen or resident who applies for ID card certificates shall have his identify validated in face-to-face by MoI officers at the MoI user sites. The individual can then initiate a certificate enrolment process at dedicated MoI kiosks deployed within the MoI user sites.

Qatari residents/citizen applying for virtual ID (VSC) certificates: A Qatari citizen or resident shall be authenticated with a strong two-factor authentication while applying for virtual ID certificates through either Hukoomi portal or dedicated MoI kiosks. Supported two-factor authentication methods include biometric and ID card authentication. After successful authentication, the individual is enrolled to the CA through a dedicated technical process triggered by either Hukoomi or by the MoI kiosk.


Certificates issued for corporate and business entities through MoI RA: Any applicant for corporate or business certificates through the MoI RA shall undergo the following enrolment process:

o Identity validation process by the MoI RA o The MoI RA validates the association

between the applicant and the organization o The MoI RA enrolls the applicant to the PKI

and issues related digital certificates.

Certificates (including virtual ID certificates) issued for corporate and business entities through an LRA: The LRA of the organization shall validate the identity of the applicant and confirm if he is authorized to receive the PKI credentials from the organization. The LRA shall then enroll the individual to the PKI and issue related key and certificates for him.


page 26 of 58

Infrastructure CA

For any issued infrastructure certificate, the MoI RA shall validate the identity of the certificate applicant who needs to appear before the RA. The MoI RA shall then enroll the infrastructure device and issue related digital certificate.

4.2 Certificate Application Processing

4.2.1 Performing Identification and Authentication Functions

Refer to section 3.2 of this CP. For further details, please refer to the related MoI subordinate CA CPS.

4.2.2 Approval or Rejection of Certificate Applications

For further details, please refer to the related MoI subordinate CA CPS.

Certification Authority Acceptance/rejection of certificate applications


Qatari citizens/residents applying for ID card certificates: A citizen or resident with a valid ID card visits an MoI user site where an officer validates his identity and verifies his eligibility for PKI credentials. The MoI officer shall then approve or reject the certificate application. The individual can then complete the certificate application at a dedicated kiosk.

Qatari residents/citizen applying for virtual ID (VSC) certificates: A Qatari citizen or resident with a valid ID card and ID card certificates shall be authenticated with a strong two-factor authentication while applying for virtual ID certificates through either Hukoomi portal or dedicated MoI kiosks. A successful authentication shall trigger the acceptance of virtual ID certificate issuance process.


Certificates issued for corporate and business entities through MoI RA: Any applicant for corporate or business certificates through the MoI RA shall undergo the following enrolment process:

o Identity validation process by the MoI RA o The MoI RA validates the association

between the applicant and the organization o If all verifications are successful, the MoI

RA accepts the certificate application and issues the required PKI credentials and related certificates

Certificates (including virtual ID certificates)


page 27 of 58

issued for corporate and business entities through an LRA: The LRA of the organization shall validate the identity of the applicant and confirm if he is authorized to receive PKI credentials from the organization. If all verifications by LRA are successful, the LRA accepts the certificate application. He enrolls the individual to the PKI and issues related PKI credentials and certificates.

Infrastructure CA

For any issued infrastructure certificate, the MoI RA shall validate the identity of the certificate applicant who needs to appear before the RA. The MoI RA then accepts the certificate application, shall then enroll the infrastructure device and issue related digital certificate.

OCSP and TSA certificate certifications shall be conducted as part of the MoI internal processes and shall be approved by the MoI PA.

4.2.3 Time to Process Certificate Applications

No stipulation

4.3 Certificate Issuance

An MoI Subordinate CA shall process a certificate issuance request as follows:

Verify the certificate request originated from a valid RA

Issue the required digital certificates that contain the information provided in the certificate request

If applicable, publish the issued certificates on the MoI public repository

Refer to the applicable MoI subordinate CA CPS.

4.3.1 CA Actions during Certificate Issuance


4.3.2 Notification to Subscriber by the CA of Issuance of Certificate


4.4 Certificate Acceptance

4.4.1 Conduct Constituting Certificate Acceptance

For any individual or infrastructure certificate issued by an MoI subordinate, the certificate applicant shall sign a dedicated subscriber agreement. It shall be possible for the applicant


page 28 of 58

to verify that the issued certificates contain the required data. Please refer to the applicable MoI subordinate CA CPS for further details.

OCSP and TSA certificate certifications shall be conducted as part of the MoI internal processes and shall be approved by the MoI PA.

4.4.2 Publication of the Certificate by the CA

Only encryption certificates issued by the MoI subordinate CAs shall be published to the MoI public repository.

TSA and OCSP certificates published by the related MoI CAs.

4.4.3 Notification of Certificate Issuance by the CA to Other Entities

No stipulation

4.5 Key Pair and Certificate Usage

4.5.1 Subscriber Private Key and Certificate Usage

When using a subscriber’s private keys and corresponding certificates, a subscriber shall adhere to the following obligations:

Use certificates only for their intended usage as per this CP and related CPS

The subscriber shall discontinue using a private key following expiration or revocation of the corresponding certificate

4.5.2 Relying on Party Public Key and Certificate Usage

When using a subscriber’s public key and corresponding certificate, a relying party shall adhere to the following obligations:

Ensure that the key is appropriate for the intended use as set forth in this CP and that such use is consistent with the applicable certificate content including, but not limited to, the key usage, extended key usage and certificate policies extension fields

Check the status of the certificate against the appropriate and current CRLs.

4.6 Certificate Renewal

Certificate Renewal is the act of issuing a new certificate when all the identifying information and the public key from the old certificate are duplicated in the new certificate, but there is a different (longer) validity period.

Certificate Renewal shall not be supported by the MoI. Only certificate re-key is supported within the MoI PKI.


page 29 of 58

4.7 Certificate Re-key

Certificate Re-key involves re-issuing a certificate for an existing subscriber such that identifying information from the old certificate is duplicated in the new certificate, with a different public key and validity period.

Re-key is an operation supported by the MoI PKI and the provisions of this CP. The re-key process (including identity validation, issuance) shall be similar to the initial certification.

Re-key for OCSP and TSA certificates shall happen as part of a dedicated MoI process approved by the PA.

4.7.1 Circumstance for Certificate Re-key

Certificate re-key may happen while the certificate is still active, after it has expired or after a revocation. The re-key operation shall invalidate any existing active certificates of the same type.

4.7.2 Who May Request Certification of a New Public Key

As per initial certification

4.7.3 Processing Certificate Re-keying Requests


4.7.4 Notification of New Certificate Issuance to Subscriber


4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate


4.7.6 Publication of the Re-keyed Certificate by the CA




4.8 Certificate Modification

This CP does not provide provisions for certificate modification outside the context of certificate re-key, which results in the generation of a new certificate with the same identification information. Refer to section 4.7 of this CP for further details.


page 30 of 58

4.8.1 Circumstance for Certificate Modification

Note applicable beyond the normal certificate re-key operation

4.8.2 Who May Request Certificate Modification


4.8.3 Processing Certificate Modification Requests


4.8.4 Notification of New Certificate Issuance to Subscriber


4.8.5 Conduct Constituting Acceptance of Modified Certificate


4.8.6 Publication of the Modified Certificate by the CA

Not applicable beyond the normal certificate re-key operation


Not applicable beyond the normal certificate re-key operation

4.9 Certificate Revocation and Suspension

4.9.1 Circumstances for Revocation

Certification Authority Circumstances for revocation


The MoI RA is the single channel for the revocation of ID card or virtual ID certificates.

ID card certificates revocation: ID card certificates life cycle is tied to the life cycle of the container ID card. When the ID card holder applies for a new card and the old card has not expired yet, this shall result in the revocation of the digital certificates of the old ID card.

Virtual ID certificates revocation: An individual holding virtual ID certificates may request the revocation of his certificates if he has reasons to believe that his Virtual ID credentials have been compromised. The MoI RA may also revoke virtual ID certificates under specific circumstance, such as when the individual undergoes a criminal investigation.


page 31 of 58


Circumstances of revocation of corporate and business certificates through MoI RA: The authorized organization representative may approach the MoI RA for certificate revocation under the following circumstances:

The organization discovers or has reason to

believe that there has been a compromise of

the corresponding private keys

The organization no longer requires the keys

and certificates

The information in the certificates issued by the

MoI is no longer valid and requires to be

changed

Circumstance for revocation of corporate and business certificates (including virtual ID certificates) through an LRA: The LRA of the organization shall revoke digital certificates corresponding to his organization when required by the organization internal processes

Infrastructure CA

The MoI RA is the single channel for the revocation of infrastructure certificates. An infrastructure certificate may be revoked under the following circumstance:

The system\device no longer requires the

certificate

The information on the certificate is no longer

accurate and a new certificate with updated data is

required

This CP does not provide provisions for revoking an OCSP/TSA certificate apart from the compromise of the OCSP/TSA key pair which shall be considered by the MoI as per its Disaster Recovery and Business Continuity procedures. The following sub-sections focus only on the revocation provisions that apply for individual and infrastructure certificates issued by the MoI CAs.

4.9.2 Who Can Request Revocation

Refer to section 4.9.1. For further details, refer to the applicable MoI subordinate CA CPS.

4.9.3 Procedure for Revocation Request



page 32 of 58

4.9.4 Revocation Request Grace Period

There shall be no revocation grace period. Revocation requests shall be processed timely/immediately by the related RA.

4.9.5 Revocation Request Response Time

Refer to section 4.9.4 of this CP.

4.9.6 Revocation Checking Requirement for Relying Parties

This PKI offers revocation information to relying parties through CRLs published on a publicly available LDAP or through its OCSP responder. Relying parties shall use any of these methods while processing a certificate issued by the MoI CAs.

4.9.7 CRL Issuance Frequency

CRLs are issued as per section 2.3 of this CP.

4.9.8 Maximum Latency for CRLs

No stipulation

4.9.9 Online Revocation/Status Checking Availability

The MoI PKI offers an OCSP responder compliant with RFC 2560. OCSP information is available immediately to relying party applications.

The actual OCSP URL to be queried by relying party organizations is referenced in the certificates issued by this PKI.

4.9.10 Online Revocation Checking Requirements

It is at the discretion of the relying party to decide whether using CRL or relying on OCSP.

4.9.11 Other Forms of Revocation Advertisements Available

No stipulation

4.9.12 Special Requirements - Key Compromise

No stipulation

4.9.13 Circumstances for Suspension

Certificate suspension is not supported by the MoI Subordinate CAs.

4.9.14 Who Can Request Suspension

Not applicable


page 33 of 58

4.9.15 Procedure for Suspension Request

Not applicable

4.10 Certificate Status Services

Refer to section 4.9.6 of this CP.

4.10.1 Operational Characteristics

CRLs shall be published by the Subordinate CAs on a public repository which is available to relying parties through LDAP protocol queries.

The MoI OCSP responder shall expose an HTTP interface accessible to relying parties.

4.10.2 Service Availability

The repository including the latest CRL should be available 24X7 for at least 99% of the time.

4.10.3 Optional Features

No stipulation

4.11 End of Subscription

No stipulation

4.12 Key Escrow and Recovery

4.12.1 Key Escrow and Recovery Policy and Practices

Key escrow is not supported by the MoI PKI.

The MoI CAs shall allow recovery of subscriber’s encryption key whenever the key is generated by the CA. Details on the private key recovery shall be specified in the applicable CPSs.

4.12.2 Session Key Encapsulation and Recovery Policy and Practices

No stipulation


page 34 of 58

5 FACILITY, MANAGEMENT and OPERATIONAL CONTROLS

5.1 Physical Controls

5.1.1 Site Location and Construction

All critical components of the PKI solution are housed within a highly secure enclave within a MoI building. Access controls are in place to protect the PKI solution.

5.1.2 Physical Access

Physical security controls include security guard-controlled building access, man traps, biometric IRIS access and Closed Circuit TV (CCTV) monitoring. These physicals controls protect the hardware and software from unauthorized access and shall be monitored on a 24*7*365 basis.

5.1.3 Power and Air Conditioning

The secure enclave shall be furnished with an Uninterruptible Power Supply (UPS) heating ventilating and air conditioning (HVAC) sufficient to maintain the computer equipment within the manufacturers recommended range of operating temperatures and humidity.

5.1.4 Water Exposures

The PKI solution shall be installed such that it is not in danger of exposure to water.

5.1.5 Fire Prevention and Protection

The enclave shall be protected from fire, heat, and smoke detection equipment monitored on a 24*7*365. Fire suppression equipment shall be installed within the enclave.

5.1.6 Media Storage

Electronic optical and other media shall be stored so that they are protected from accidental damage (water, fire, electromagnetic radiation). Media that contains security audit archive and backup information shall be stored in a secure fire-proof safe while within the enclave.

5.1.7 Waste Disposal

All obsolete paper magnetic media, optical media, etc. created within the enclave shall be shredded before discarding. Reusable magnetic and optical media may be reused indefinably within the enclave.

5.1.8 Offsite Backup

System backups, sufficient to recover from system failure, shall be made daily. Backup copies should be transferred to a secure offsite location.


page 35 of 58

Backup media shall be stored in a location separate from the MoI main site in accordance with the MoI PKI Disaster Recovery plan and Procedures.

Facilities used for offsite backup and archives shall have the same level of security as the MoI’s main site.

5.2 Procedural Controls

For details on the procedural controls, refer to the applicable CPSs. The following provisions are made in this CP.

5.2.1 Trusted Roles

At a minimum, the following roles shall be defined for MoI Subordinate CAs:

Security Officers: Responsible for the CA configuration according to this CP and corresponding CPS.

CA Administrators: Responsible for RA functionality including user’s certificate definition, policies, search base definition, groups creation, etc.

Security Operators: Responsible for the day-to-day operations of CA.

5.2.2 Number of Persons Required Per Task

The MoI shall maintain and enforce rigorous control procedures to ensure the segregation of duties based on job responsibility in order to prevent a single trusted personnel to perform sensitive operations alone.

The most sensitive tasks, such as access to and management of CA cryptographic hardware security module (HSM) shall require the involvement of two or more persons.

5.2.3 Identification and Authentication for Each Role

Before exercising the responsibilities of a trusted role:

The MoI shall have confirmed the identity of the employee by carrying out background checks

The MoI shall issue an access card to Administrators who need to access equipment located in the secure enclave

The MoI shall Deliver the necessary credentials that allow Administrators conduct their functions

5.2.4 Roles Requiring Separation of Duties

No individual may serve in more than one trusted role. For instance, an individual playing the role of a Security Officer cannot play the role of a CA administrator.


page 36 of 58

5.3 Personnel Controls

All CA personnel shall be in the employment of or contracted to the MoI. The terms and conditions of contracting/employment shall include requirements on the part of such personnel not to disclose sensitive CA security-relevant information or private information. The MoI PMA shall ensure that it will not assign duties to personnel that may cause a conflict of interest with their CA or RA duties.

5.3.1 Qualifications Experience and Clearance Requirements

Individuals selected for a trusted role shall have demonstrated trustworthiness and integrity. All individuals shall be Qatari citizens or residents and holding an appropriate Government security clearance. Personnel operating the CA equipment shall satisfy the following requirements:

Satisfactorily completed an appropriate training program

Demonstrated the ability to perform their assigned duties

Not have any other duties that would conflict with their role in this PKI solution

Not been previously relieved of similar duties for negligence

Not been denied a security clearance or had a clearance revoked

Not been convicted of a serious crime

5.3.2 Background Check Procedures

Background checks are performed by the Qatar State Secret Service and are not disclosed in this document.

5.3.3 Training Requirements

All CA personnel shall be appropriately trained to perform their duties. Such training will address relevant topics, such as security requirements, operational responsibilities and associated procedures.

The training shall include minimum operations of the PKI (including CA hardware and software), operational and security procedures, this CP and the applicable CPS’s.

5.3.4 Retraining Frequency and Requirements

The MoI shall provide refresher training and updates to its personnel to the extent and frequency required to ensure that such personnel maintain the required level of proficiency to perform their job responsibilities competently and satisfactorily.

5.3.5 Job Rotation Frequency and Sequence

The MoI shall establish a job rotation schedule for its OA team staff, consistent with the need to provide continuity of the PKI service and avoid dependence on a few key staff.


page 37 of 58

5.3.6 Sanctions for Unauthorized Actions

Personnel performing unauthorized actions shall be subject to disciplinary actions consistent with existing MoI HR policies. In addition, the OA Director has the authority to temporarily suspend personnel from performing functions if deemed necessary for the integrity or security of the PKI solution.

5.3.7 Independent Contractor Requirements

Any contractor or subcontractor operating any part of this PKI shall be subject to the personnel controls described in the preceding sections and to those requirements normally imposed by the MoI for similar services.

5.3.8 Documentation Supplied to Personnel

Individuals shall be given sufficient documentation to define their duties. They shall also be supplied with written procedures, technical manuals and other documentation needed to perform their job responsibilities.

5.4 Audit Logging Procedures

For details on the audit logging procedures, refer to the applicable CPSs. The following provisions are made in this CP.

5.4.1 Types of Event Recorded

All significant events occurring on the Subordinate CAs shall be recorded.

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

5.4.2 Frequency of Processing Log

The following requirements shall apply for the OA staff in processing the generated logs:

Audit logs shall be reviewed regularly (at a minimum of once a week)

Identified issues and irregularities shall be investigated and resolved

Audit logs shall be periodically archived and purged from the CA system active system

5.4.3 Retention Period for Audit Log

The audit log files shall be retained online (i.e., on the CA system) for three months, after which they may be archived.

5.4.4 Protection of Audit Log

Audit logs shall be protected by a combination of physical and procedural security controls. The CA shall generate a message authentication code for each audit log file it keeps.


page 38 of 58

5.4.5 Audit Log Backup Procedures

The following rules apply for the backup of the Subordinate CAs audit log:

Backup media shall be stored locally in the MoI’s main site in a secure location.

A second copy of the audit log data and files shall be stored outside the MoI’s main site, in a site that shall provide physical and environmental security as described in this CP for the MoI’s main site.

5.4.6 Audit Collection System (internal vs. external)

No stipulation

5.4.7 Notification to Event-causing Subject

Where an event is logged by the audit collection system, no notice is required to be given to the individual, organization, device or application that caused the event.

5.4.8 Vulnerability Assessments

The Subordinate CAs systems are subject to an annual assessment in line with the MoI system assurance policy and this CP.

5.5 Records Archival

5.5.1 Types of Records Archived

The MoI shall guarantee that the following data managed by its PKI is archived. Data archiving shall occur in accordance with the procedures described in the Subordinate CAs CPSs:

Certificate life cycle operations including certificate requests, revocation requests, re-key requests, etc.

All certificates and CRLs as issued or published by the Subordinate CAs.

Audit logs

PKI system configuration data

This CP document and all applicable CPSs including modifications and amendments to these documents

5.5.2 Retention Period for Archive

Archived records shall be retained for at least 15 years. Applications necessary to read these archives shall be maintained for the retention period.

5.5.3 Protection of Archive

The archived data shall be protected against unauthorized viewing, modification, deletion, or tampering. The media holding the archive data and the applications required to process the archive data shall be maintained and protected as per the rules specified in this CP and applicable CPSs.


page 39 of 58

5.5.4 Archive Backup Procedures

In addition to the primary archive, a second copy of the archived records shall be made and sent to a secure offsite storage facility in accordance with the procedures described in the CPS. Discrepancy and compromise reports and correspondence shall be copied upon receipt and sent to a secure offsite storage facility. Original copies shall be stored locally in a secure location.

5.5.5 Requirements for Time-stamping of Records

The precise time of archiving all events and records listed in section 5.5.1 shall be recorded with Time-Stamp.

5.5.6 Archive Collection System (internal or external)

Only authorized and authenticated staff is allowed to handle archive material.

5.5.7 Procedures to Obtain and Verify Archive Information

Only authorized trusted OA personnel shall obtain access to the archive.

At least once per quarter, the latest archive records are retrieved and verified to ensure that no damage or loss of data has occurred. If damage has occurred to the data then the backup archive is retrieved and becomes the new master archive and a new backup is produced.

5.6 Key Changeover

The CA Keys will be changed before the Certificate expires through the generation of a new CA key pair and the certification of its public key by NR-CA.

5.7 Compromise and Disaster Recovery

5.7.1 Incident and Compromise Handling Procedures

The MoI shall establish a business continuity plan for its PKI. The plan shall handle incidents and Key compromise situations.

5.7.2 Computing Resources, Software and/or Data Corruption

The MoI shall establish procedure and processes to handle the corruption or loss of computing resources, software and/or data for the PKI. These procedures may be part of the PKI disaster recovery plan.

The procedures shall cover how the MoI PKI may be restored to the last good backup before the corruption occurred.

Disaster recovery infrastructure and procedures shall be fully tested at least once a year with witnessing of more than one member of the PMA.


page 40 of 58

5.7.3 Entity Private Key Compromise Procedures

In the event of a key compromise of a CA, which is part of the MoI PKI, the following actions shall be taken by the OA and PMA:

• All active certificates issued by the CA shall be revoked. Organizations holding entity and Infrastructure certificates shall be notified.

• A new CA key pair shall be generated and certificate produced by the NR-CA.

• A CA compromise notice shall be published toward relevant relying parties.

• After the PMA and OA have identified the compromise scenario and established proper remedies, issuing certificates for existing and new entities may start. This shall happen according to the certificate management procedures listed in this CP document.

The MoI shall document a key compromise scenario for its CAs keys covering all the above operations. CA compromise scenarios and impact may be documented as part of the PKI disaster recovery and business continuity plan.

5.7.4 Business Continuity Capabilities after a Disaster

The OA shall maintain a Disaster Recovery and Business Continuity Plan that is capable of resuming certificate issuance. This plain is referenced in this document as “PKI disaster recovery and business continuity plan”.

5.8 CA or RA Termination

If the MoI determines that termination of its PKI and CA services are deemed necessary, the OA shall commence such termination. The OA shall arrange for the retention of archived data as specified in section 5.5 of this CP.


page 41 of 58

6 TECHNICAL SECURITY CONTROLS

6.1 Key Pair Generation and Installation

The requirements for generating and installing the CAs’ and subscribers’ key pairs are stated in the following sections.

6.1.1 Key Pair Generation 6.1.1.1 CA Key Pair Generation

The Subordinate CAs keys shall be generated as part of a key ceremony produced by the PMA and executed by the OA under the supervision of the PMA.

CA key pairs shall be generated within the memory of an HSM certified to the level required by this CA operation (at minimum FIPS 140-1 Level 3).

6.1.1.2 Subscriber Key Pair Generation


This CA generates only encryption keys for its subscribers; those keys shall be generated securely within the CA infrastructure and stored in encrypted format within the CA database. Other keys types shall be generated within cryptographic hardware as much as possible. Business and Corporate CA

This CA generates only encryption keys for its subscribers; those keys shall be generated securely within the CA infrastructure and stored in encrypted format within the CA database. Other keys types shall be generated within cryptographic hardware as much as possible. Infrastructure CA

This CA does not deal with subscriber key generation. These shall be generated within cryptographic hardware as much as possible.

6.1.2 Private Key Delivery to Subscriber


This CA shall deliver the subscriber’s decryption key (Private key) to RA applications as part of a certificate management communications based on PKIX CMP protocol. Business and Corporate CA

This CA shall deliver the subscriber’s decryption key (Private key) to RA applications as part of a certificate management communications based on PKIX CMP protocol. Infrastructure CA

Not applicable. This CA does not create subscriber key pairs.

6.1.3 Public Key Delivery to Certificate Issuer

For individual’s certificates: Public keys shall be delivered to RA applications as part of a certificate management communications based on PKIX CMP protocol.


page 42 of 58

For infrastructure, TSA and OCSP certificates: Public Keys shall be delivered thorough device relevant protocols like SCEP protocol or through media\email exchange if the device does not support certificate management protocols.

6.1.4 CA Public Key Delivery to Relying Parties

The CA should make its certificates available to subscribers and relying parties by publishing them in a public repository (MoI Public LDAP).

6.1.5 Key Sizes

The Citizen and Resident CA key pair shall be at least 2048 bit RSA.

The Business and Corporate CA key pair shall be at least 4096 bit RSA.

The Infrastructure CA key pair shall be at least 4096 bit RSA.

Subscriber keys shall be at least 2048 bit RSA except the keys being stored in the Qatari ID card where the key size shall be 1024 bit.

6.1.6 Public Key Parameters Generation and Quality Checking

The MoI Subordinate CAs shall relay on off-the-shelf implementation of key PKI functionality including public key parameters generations (in accordance with standards, such as PKCS#10).

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

Certificates issued by the MoI CAs should always contain a Key Usage bit string in accordance with RFC 5280. For smart card certificates, the digitalSignature key usage and keyEncipherment key usage shall never be expressed in the same certificate.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic Module Standards and Controls

The MoI Subordinate CAs shall generate their key pairs and store their private key within a HSM that is certified according to the rating specified in 6.2.11.

Individuals’ private keys shall be generated within a smart card or a similar PKI token that is certified according to the rating specified in 6.2.11.

Virtual Smart Card (VSC) key pairs shall be stored in an encrypted format using a master key. The master key shall be stored in a HSM that is certified according to the rating specified in 6.2.11.

Infrastructure devices shall generate their own key pairs commensurate with the degree of risk.


page 43 of 58

6.2.2 Private Key Multi-Role Control

The MoI shall implement technical and procedural mechanisms that implement the principles of dual control and split knowledge. These principles guarantee the participation of multiple trusted individual for performing sensitive operations with CAs cryptographic hardware.

6.2.3 Private Key Escrow

Key escrow is not supported by the MoI PKI.

The OA shall never escrow any signature key. However, it shall escrow private encryption keys except the keys generated by the VSC. The private encryption key shall be:

Initially generated by the CA

Escrowed in an encrypted database under the sole control of the OA

Recovered under procedures that require an RA Officer to set the key recovery state and the individual to recover the key as described in 4.12.

Recoverable under dual control through a MoI administrative process to respond to subpoenas or lawful requests to decrypt messages or files without the key holders consent.

6.2.4 Private Key Backup

The CAs private keys shall be backed up within a backup tokens that meet the same certification level as the CA HSM and as described in section 6.2.1. The creation of key backups on backup tokens shall be conducted using the principles of dual controls and split knowledge involving at least two OA officers.

At least one backup of the CAs keys shall be taken. This backup shall be stored in a locked safe at the Disaster Recovery Site.

6.2.5 Private Key Archival

The MoI CAs shall allow archival of subscriber’s encryption key whenever the key is generated by the CA, in which case a complete history of private keys and certificates issued shall be maintained by the CA.

Details on the private key archival shall be specified in the applicable CPSs.

6.2.6 Private Key Transfer Into or From a HSM

The CA key pairs shall only be transferred to another hardware cryptographic token of the same specification as described in 6.2.11 by direct token-to-token copy via trusted path under MofN multi-person control.

At no time should the CA private key be copied to disk or other media forms during this operation.

6.2.7 Private Key Storage on Cryptographic Module

No further stipulation other than those stated in 6.2.1.


page 44 of 58

6.2.8 Method of Activating Private Key

Private keys for the Subordinate CAs are activated by a minimum of two privileged users using the principles of dual control and split knowledge. The activation procedure shall use a PIN entry device attached to the CA HSM.

Subscriber’s private keys are not generated and managed by the MoI CAs.

6.2.9 Method of Deactivating Private Key

Private keys for the Subordinate CAs shall be deactivated in situations such as:

There is a power failure within the CA room

The CA HSM is operated outside the range of supported temperatures

The HSM detects a security breach and deletes all key material within its internal memory

When private keys are deactivated, they shall be cleared from memory before the memory is de-allocated and shall be kept in encrypted form only. Any disk space where keys were stored shall be over-written before the space is released to the operating system.

Subscriber’s private keys deactivate is managed by the MoI Subordinate CAs.

6.2.10 Method of Destroying Private Key

The MoI shall rely on the HSM’s initialize commands as much as possible for the destruction of CA keys. Private keys stored on backup tokens shall also be destroyed using HSM dedicated commands.

Physical destruction of hardware is not required.

6.2.11 Cryptographic Module Rating

The CA shall use an HSM certified to FIPS 140-1 Level 3 or ISO 15408 Common Criteria (CC) EAL 4+ or above.

6.3 Other Aspects of Key Pair Management

6.3.1 Public Key Archival

Refer to section 5.5 of this CP.

6.3.2 Certificate Operational Periods and Key Pair Usage Periods

The maximum operational period of the CA’s key pair shall be set for eight years.

The maximum operational period for a subscriber’s key pair shall be five years.


page 45 of 58

6.4 Activation Data

6.4.1 Activation Data Generation and Installation 6.4.1.1 CA Key Generation

The Subordinate CAs activation data correspond to PIN and Passwords that are used to activate HSMs hosting CA keys. CA keys and their activation data shall be generated in accordance with the requirements of section (Secret Shares) used to protect security tokens containing the CA’s private key and shall be generated in accordance with the requirements of Section 6.2 of this CP.

During the Key Generation ceremony of an MoI Subordinate CAs, trusted individuals (key custodians) shall receive their activation data. These shall be managed according to section 6.2 of this CP.

6.4.1.2 Subscribers keys

Any of Subordinate CAs shall register its subscribers prior to them issuing digital certificate. The enrolment of a subscriber shall result in activation data randomly generated by the CA. This activation data shall be delivered securely to the subscriber that will use it to apply for digital certificates.

6.4.2 Activation Data Protection

Activation data for CA subscribers shall be generated randomly. Any activation data shall be bound to one subscriber only and shall have a limited lifetime. Activation data shall be transmitted via one of the following means:

For individual’s certificates: Automated process through the secure exchange of activation data between the Subordinate CAs and RA applications. For infrastructure, TSA and OCSP certificates: Out of the bound means at the discretion of the OA guaranteeing that only the legitimate subscriber organization representative receives the activation data.

6.4.3 Other Aspects of Activation Data

No stipulation

6.5 Computer Security Controls

The MoI Subordinate CAs shall perform all CA and RA functions using Trustworthy systems that meet the MoI security and audits requirements.

6.5.1 Specific Computer Security Technical Requirements

The MoI Subordinate CAs shall be operated according to the following security controls:

Physical access control to the CA servers shall be enforced.

Separation of duties and dual controls for CA sensitive operations


page 46 of 58

Identification and authentication of PKI roles and their associated identities

Archival of CAs history and audit data

Audit of security related events

Automatic and regular validation of the CAs database integrity

Recovery mechanisms for keys and CA systems

Hardening CA servers operating system according to best practices and PKI vendor requirements

6.5.2 Computer Security Rating

No stipulation – this section intentionally left blank.

6.6 Life Cycle Technical Controls

6.6.1 System Development Controls

Applications shall be tested, developed and implemented in accordance with industry best practice development and change management standards.

Purchased hardware or software shall be shipped or delivered in a sealed or shrink-wrapped container and be installed by trained personnel.

6.6.2 Security Management Controls

The hardware and software used to setup the MoI PKI shall be dedicated to performing only CA-related tasks. There shall be no other applications, hardware devices, network connections or component software, which are not part of the MoI PKI and installed on CA hardware.

The MoI Subordinate CAs and RAs functionality shall be scanned for malicious code on first use and periodically afterward.

Upon installation, and at least once a week, the integrity of the MoI Subordinate CAs databases shall be validated.

6.6.3 Life Cycle Security Controls


6.7 Network Security Controls

Network security controls shall be implemented in order to secure the MoI PKI perimeter (security enclave). The following security controls shall be implemented:

A network of firewall (internal, external) and filtering routers shall be put in place to protect network access to the CA components.


page 47 of 58

The firewall and routers network shall limit network services allowed to and from the MoI PKI equipment only to those required for MoI CAs to operate and execute their core PKI functions.

Any unused ports on PKI hardware shall be turned off.

6.8 Time-Stamping

The CAs servers’ internal clock shall be synchronized using Network Time Protocol.


page 48 of 58

7 CERTIFICATE, CRL PROFILES

7.1 Certificate Profile

7.1.1 Version Number

The MoI Subordinate CAs shall issue X.509 version 3 certificates as defined in RFC 5280.

7.1.2 Certificate Extensions

Individuals’ certificates require the use of the following extensions:

KeyUsage (not critical)

AuthorityKeyId (not critical)

AuthorityInformationAccess (not critical)

CP (not critical)

CDP (not critical)

OCSP response signing certificates require the use of the following extensions:



Extended KeyUsage (critical)

OCSPNoCheck (not critical)

TSA response signing certificates require the use of the following extensions:



Extended KeyUsage (critical)

CDP(not critical) SSL certificates extensions as per the norm.

7.1.3 Algorithm Object Identifiers

X.509v3 standard OIDs shall be used. Algorithm shall be RSA encryption for the subject key and SHA256 with RSA encryption for the certificate signature.

7.1.4 Name Forms

As per the naming conventions and constraints listed in section 3.1 of this CP

7.1.5 Name Constraints

As per the naming conventions and constraints listed in section 3.1 of this CP

7.1.6 Certificate Policy Object Identifier

Refer to the ASN1 definitions described in the below subsections.

7.1.7 Usage of Policy Constraints Extension


page 49 of 58

No stipulation

7.1.8 Policy Qualifiers Syntax and Semantics

No stipulation

7.1.9 Processing Semantics for Critical Certificate Extensions

Critical extensions, when marked, shall be interpreted by relying parties correctly.

7.1.10 Subscriber’s Encryption Certificate ASN1 Description

This is the complete ASN1 description of the certificate associated with the Encryption key of the subscriber.

Object Format Certificate Content

Certificate Sequence

TbsCertificate Sequence

Version Integer 2 (Version 3)

SerialNumber Integer Generated Unique by the CA

Signature OID Sha-256WithRSAencryption

Issuer UTF8 For Citizens and Residents Certificates:

{ CN= Citizen and Resident Certification Authority, O = QECC, C = QA}

For Corporate Certificates:

{ CN= Business and Corporate Certification Authority, O = QECC, C = QA }

Validity UTC-Time NotBefore: <<creation date>>

NotAfter: <<creation date + n years>>

n: 5 years for citizen, 3 years for residents

Subject PRINTABLE STRING

For Citizens:

{ CN= [Full Name] QID,OU=Citizens , O = QECC, C = QA}

For Residents:

{ CN= [Full Name] QID,OU= Residents, O = QECC, C = QA}

For Corporate certificates:

[To be defined by each corporate]

SubjectPublicKeyInfo Sequence


page 50 of 58

AlgorithmIdentifier OID RSAencryption (Parameter = NULL)

SubjectPublicKey BitString Public key (256 bytes) + exp. pub.

Extensions Sequence

AuthorityKeyId OctString <<SHA1 of subjectPublicKey of Issuer (Citizen and Resident CA certificate>>

Critical Boolean False

KeyUsage BitString ‘20’: Key Encipherment


AIA Sequence

accessMethod OID Certification Authority Issuer (1.3.6.1.5.5.7.48.2)

accessLocation IA5String http://www.moi.gov.qa/pki/[CA Cert file name].crt

accessMethod OID OCSP(1.3.6.1.5.5.7.48.1)

accessLocation IA5String https://qpki.moi.gov.qa/adss/ocsp

Certificate policy Sequence

PolicyInformation Sequence

policyIdentifier OID For Citizens Certificates: 2.16.634.1.4.2.1.2 For Residents Certificates: 2.16.634.1.4.2.1.3 For Corporate Certificates: 2.16.634.1.4.2.1.4

policyIdentifier OID 2.16.634.1.1.2.1.1


CDP Sequence

distributionPoint DistributionPointName

fullName GeneralNames

IA5String LDAP URI where the Partitioned CRL is hosted

Name Partitioned CRL directory address


SignatureAlgorithm OID Sha-256WithRSAencryption

SignatureValue BitString <<signed using the PCA private key>> (512 octets)

7.1.11 Subscriber’s Signing Certificate ASN1 Description

This is the complete ASN1 description of the certificate associated to the signing key of the subscriber.





http://www.moi.gov.qa/pki/%5bCA


page 51 of 58



Issuer UTF8 For Citizens and Residents Certificates:

{ CN= Citizen and Resident Certification Authority, O = QECC, C = QA}

For Corporate Certificates:

{ CN= Business and Corporate Certification Authority, O = QECC, C = QA }


NotAfter: <<creation date + n years>>

n: 5 years for citizen, 3 years for residents

Subject PRINTABLE STRING

For Citizens:

{ CN= [Full Name] QID,OU=Citizens , O = QECC, C = QA}

For Residents:

{ CN= [Full Name] QID,OU= Residents, O = QECC, C = QA}

For Corporates:

[Subject DN to be defined by each corporate]




Extensions Sequence



KeyUsage BitString ‘80’: digital signature


AIA Sequence

accessMethod OID Certification Authority Issuer (1.3.6.1.5.5.7.48.2)

accessLocation IA5String http://www.moi.gov.qa/pki/[CA Cert file name].crt

accessMethod OID OCSP(1.3.6.1.5.5.7.48.1)

accessLocation IA5String https://qpki.moi.gov.qa/adss/ocsp

Certificate policy Sequence

PolicyInformation Sequence

policyIdentifier OID For Citizens Certificates:

http://www.moi.gov.qa/pki/%5bCA


page 52 of 58

2.16.634.1.4.2.1.2 For Residents Certificates: 2.16.634.1.4.2.1.3 For Corporate Certificates: 2.16.634.1.4.2.1.4

policyIdentifier OID 2.16.634.1.1.2.1.1


CDP Sequence








7.1.12 OCSP Response Signing Certificate ASN1 Description

As per OCSP standard (RFC 2560), the following rules are applied on the OCSP profile:

The OCSP response signing authority is designated to the MoI OCSP responder. Therefore, the OCSP certificate contains the id-kp-OCSPSigning OID in the extendedKeyUsage extension.

The certificate will include the extension id-pkix-ocsp-nocheck as a non-critical extension, which indicates that an OCSP relying party can trust an OCSP response signing certificate for its lifetime.

This is the complete ASN1 description of the certificate associated to the OCSP response signing private key.







Issuer UTF8 For Citizen and Resident CA:

{ CN=Citizen and Resident Certification Authority, O=QECC, C=QA}

For Business and Corporate CA:

{CN=Business and Corporate Certification Authority, O=QECC, C=QA}


page 53 of 58

For Infrastructure CA:

{CN=Infrastructure Certification Authority, O=QECC, C=QA}


NotAfter: <<creation date +3 Years>>

Subject UTF8 For Citizen and Resident CA:

{ CN=MoI OCSP, CN=Citizen and Resident Certification Authority, O=QECC, C=QA}


{ CN=MoI OCSP, CN=Business and Corporate Certification Authority, O=QECC, C=QA}


{ CN=MoI OCSP, CN=Infrastructure Certification Authority, O=QECC, C=QA}




Extensions Sequence



KeyUsage BitString ‘C0’: digital signature and non-repudiation


ExtendedKeyUsage OctString OCSP Signing (1.3.6.1.5.5.7.3.9)

Critical Boolean True

OCSPNoCheck OctString NULL



SignatureValue BitString <<signed using the infrastructure private key>> (512 octets)

7.1.13 TSA Signing Certificate Profile

This is the complete ASN1 description of the certificate associated to TSA signing private keys.






page 54 of 58



Issuer UTF8 { CN=Infrastructure Certification Authority, O=QECC, C=QA }


NotAfter: <<creation date +3 Years>>

Subject UTF8 << CN=MoI TSA, CN=Infrastructure Certification Authority DEV, O=QECC, C=QA >>




Extensions Sequence

AuthorityKeyId OctString <<SHA1 of subjectPublicKey of the Issuer CA (Infrastructure CA)>>


KeyUsage BitString ‘C0’: digital signature and non-repudiation


ExtendedKeyUsage OctString Time Stamping (1.3.6.1.5.5.7.3.8)

Critical Boolean True

CDP Sequence







SignatureValue BitString <<signed using the infrastructure private key>> (512 octets)

7.1.14 SSL Certificate Profile

The standard SSL certificate profile shall be used.

7.1.15 VPN Certificate Profile

The standard VPN certificate profile shall be used.

7.2 CRL Profile

The version field in the certificate states 1, indicating X.509v2 CRL.

7.2.1 Version Number(s)

The version field in the certificate states 1, indicating X.509v2 CRL.


page 55 of 58

7.2.2 CRL and CRL Entry Extensions

The CRL extensions shall contain the CRLNumber (a sequential number incremented with each new CRL produced).

7.2.3 CRL ASN1 Description


CertificateList Sequence

TbsCertList Sequence



Issuer UTF8 For Citizen and Resident CA:

{ CN=Citizen and Resident Certification Authority, O=QECC, C=QA}


{CN=Business and Corporate Certification Authority, O=QECC, C=QA}


{CN=Infrastructure Certification Authority, O=QECC, C=QA}

thisUpdate UTC-Time <<date / time of CRL emission>>

nextUpdate UTC-Time ThisUpdate + 1 day + 2 hours

revokedCertificates Sequence

CertificateSerial Integer

revocationDate UTC-Time

crlEntryExtensions Sequence

cRLReason OctString Enumerated CRLReason as specified in the RFC 5280


crlExtensions Sequence

crlNumber Integer Sequential CRL number


AuthorityKeyId OctString <<SHA1 of subjectPublicKey of the Issuer >>





page 56 of 58

8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS

At a minimum, yearly audits shall be conducted by an auditing firm, referred to as “auditor” selected by the PA. The auditor audits the operations of this CA against the policy and procedures of this CPS and related CP. The audit framework shall comply with [ETSI 319 411-3].


page 57 of 58

9 OTHER BUSINESS AND LEGAL MATTERS

9.1 Fees

Please refer to the applicable CPSs.

9.2 Financial responsibility


9.3 Confidentiality of business information

No stipulation – this section intentionally left blank

9.4 Privacy of personal information


9.5 Intellectual property rights


9.6 Representations and warranties


9.7 Disclaimers of warranties


9.8 Limitations of Liability

The CA shall not offer any guarantees or warranties or enter into agreements that could be the subject of performance penalties that could lead to legal action on behalf of subscribers or relying parties.

9.9 Indemnities


9.10 Term and termination


9.11 Individual notices and communications with participants


9.12 Amendments



page 58 of 58

9.13 Dispute resolution provisions


9.14 Governing Law

The CA shall operate within the state of Qatar legal jurisdiction.

9.15 Compliance with applicable law


9.16 Miscellaneous provisions


9.17 Other provisions


Qatar Ministry of Interior - Public Key Infrastructure ... · Qatar Ministry of Interior - Public...

Documents

Transcript of Qatar Ministry of Interior - Public Key Infrastructure ... · Qatar Ministry of Interior - Public...