Qatar Ministry of Interior - Public Key Infrastructure Infrastructure CA Certification Practice Statement

(1)

Qatar Ministry of Interior - Public Key Infrastructure

Infrastructure CA

Certification Practice Statement

Issue : 1.2

Issue date : 19 October 2014

Status : Approved

(2)

Qatar Ministry of Interior – Infrastructure CA Certification Practice Statement

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

(3)

Detailed contents

1 Introduction ... 6

1.1 Overview ... 6

1.2 Document name and Identification ... 8

1.3 PKI Participants ... 8

1.4 Certificate Usage ... 10

1.5 Policy Administration ... 11

1.6 Definitions and Acronyms ... 11

2 Publication and Repository Responsibility ... 16

2.1 Repositories ... 16

2.2 Publication of Certificate Information ... 16

2.3 Time or Frequency of Publication Repositories ... 16

2.4 Access Controls on Repositories ... 17

3 Identification and Authentication ... 18

3.1 Naming ... 18

3.2 Initial Identity Validation ... 19

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

4 Certificate Life Cycle Management ... 22

4.1 Certificate Application ... 22

4.2 Certificate Application Processing... 22

4.3 Certificate Issuance ... 23

4.4 Certificate Acceptance ... 23

4.5 Key Pair and Certificate Usage ... 24

(4)

4.7 Certificate Re-key ... 25

4.8 Certificate Modification ... 25

4.9 Certificate Revocation and Suspension ... 26

4.10 Certificate Status Services ... 28

4.11 End of Subscription ... 28

4.12 Key Escrow and Recovery ... 28

5 FACILITY, MANAGEMENT and OPERATIONAL CONTROLS ... 29

5.1 Physical Controls ... 29

5.2 Procedural Controls ... 30

5.3 Personnel Controls ... 31

5.4 Audit Logging Procedures ... 32

5.5 Records Archival ... 34

5.6 Key Changeover ... 35

5.7 Compromise and Disaster Recovery ... 35

5.8 CA or RA Termination ... 36

6 TECHNICAL SECURITY CONTROLS ... 37

6.1 Key Pair Generation ... 37

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

6.3 Other Aspects of Key Pair Management ... 40

6.4 Activation Data ... 40

6.5 Computer Security Controls ... 41

6.6 Life Cycle Technical Controls ... 41

6.7 Network Security Controls ... 42

(5)

7 CERTIFICATE, CRL PROFILES ... 43

7.1 Certificate Profile ... 43

7.2 CRL Profile ... 46

8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS ... 48

9 OTHER BUSINESS AND LEGAL MATTERS ... 49

9.1 Fees 49 9.2 Financial responsibility ... 49

9.3 Confidentiality of business information ... 49

9.4 Privacy of personal information ... 49

9.5 Intellectual property rights ... 50

9.6 Representations and warranties ... 50

9.7 Disclaimers of warranties ... 50

9.8 Limitations of Liability ... 50

9.9 Indemnities ... 50

9.10 Term and termination ... 50

9.11 Individual notices and communications with participants ... 50

9.12 Amendments ... 50

9.13 Dispute resolution provisions ... 51

9.14 Governing Law ... 51

9.15 Compliance with applicable law ... 51

9.16 Miscellaneous provisions ... 51

(6)

1 Introduction

1.1 Overview

This Certification Practice Statement (CPS) describes the certification practices that apply to the digital certificates issued by the Infrastructure Certification Authority (CA), which is provided and operated by the Ministry of Interior (MoI) of the State of Qatar. The Infrastructure CA is one of the MoI subordinate CAs that come in the second level of Qatar national PKI (QPKI) hierarchy. These CAs are sometimes referred to as “MoI PKI” in this CPS document.

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

The MoI Subordinate CAs deliver national PKI certification services that enable citizens, residents and corporate organizations to conduct secure electronic transactions. The Infrastructure CA is responsible, mainly for issuing and managing Infrastructure certificates for systems, VPN devices, web sites (SSL) and other infrastructure related certificates. This CA 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 Public Key Infrastructure (PKI) certification services are offered by the MoI in accordance with the applicable Certificate Policy (CP) and this Certification Practice Statement (CPS).

The Infrastructure CA is root-signed by Qatar National Root CA (NR-CA) that is the first level in the Qatar Public Key Infrastructure (QPKI) hierarchy as such Infrastructure CA comes in the second level of Qatar national PKI (QPKI) hierarchy.

This CPS covers the issuance and controls surrounding the following types of certificates and their associated key pairs:

 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

 OCSP certificates - Used by the MoI Online Certificate Status Protocol (OCSP) responder to sign OCSP responses related to certificates issued by this CA

 Certificates issued for Timestamping Authority (TSA) - used to sign the timestamp issued by QPKI Timestamping Authority service.

This CPS is maintained by the MoI and is made available online along the applicable CP via the MoI PKI web portal.

(7)

1.1.1 QPKI hierarchy

The figure below illustrates the hierarchical PKI Operated by the MoI.

The National Root Certification Authority (NR-CA) is the top authority in Qatar with regard to digital certification services offered in the country.

NR-CA issues top level certificates to MoI Subordinate CAs (Citizen and Resident CA, Business and Corporate CA and infrastructure CA). The below figure highlights the Infrastructure CA and its position within the QPKI hierarchy.

CSPs-PMA National Root CA

Citizen & Resident CA

Business and Corporate CA

Business and

Corporate CA Infrastructure CA

Identity encryption

certs

OCSP certs Web certs VPN certs

Identity signing certs Corporate encryption certs OCSP certs Corporate signing certs OCSP certs

1.1.2 Certification services

The certification services offered by this CA are explained in this document as given below  Registration service: It verifies the identity and, if applicable, any specific attribute

of end-entities applying for certificates. The results of this service are passed to the certificate generation service.

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

 Dissemination service: It 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 & Revocation management service: It 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: it provides certificate validity status information

(8)

The status information must always reflect the current status of the certificates issued by this CA.

1.2 Document name and Identification

1.2.1 Document Title

This document is named “Qatar Ministry of Interior - Infrastructure CA CPS” and is referred to in the related documents as “QATAR-MoI- Infrastructure CA CPS”.

1.2.2 Identification Alphanumeric OID

The Object Identifier of this CPS is OID is 2.16.634.1.1.2.2.3.

1.3 PKI Participants

Several parties are involved around the lifecycle management of digital certificates issued by this CA. They include:

 Certification Authorities (CAs)  Policy Authority

 Operational Authority  Registration Authorities  Subscribers

 Relying Parties

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

1.3.1 Certification Authorities

For this CA, the Certification Authority issues

Infrastructure certificates for IT systems,

VPN devices, web sites (SSL) and other infrastructure related certificates

. This includes the following tasks



Issuing and managing certificates



Publishing encryption certificates to a public repository accessed by Relying

Parties



Issuing and publishing CRLs to a public repository accessed by Relying

Parties



Pushing CRLs to the MoI OCSP responder

1.3.2 Policy Authority (PA)

A PKI board is established by the MoI so that it represents the policy and governing body for its PKI. This board is referred to in this CPS document as the “Policy Authority” (PA). It constitutes of appointed individuals with security clearance who are responsible for:

(9)

 Specifying and approving this CA infrastructure

 Specifying and approving the changes required to this CPS and other related documentation

 Defining the review and auditing process that ensures that this CA operations comply with practices listed in this CPS

 Organizing regular audits to be conducted by internationally recognized auditing firms  Deciding and planning actions to be taken as a result of deficiency

 Organizing key ceremonies including allocating members to the key ceremonies  Specifying and maintaining the overall Disaster Recovery and Business Continuity

plan for this CA

1.3.3 Operational Authority (OA)

The Operational Authority (OA) is setup by the MoI to serve as the operational body of the MoI PKI including this CA. A dedicated operations team takes the responsibility for the operation of the PKI within the MoI. The OA comprises individuals with security clearance who operate this CA in accordance with this CPS.

With respect to the actual operation of this CA, several significant roles have been defined as follows:

 CA Master user - is responsible for the configuration and maintenance of hardware and software for the CA; commencement and cessation of CA services; and the initial creation of accounts for PKI Officers.

 CA Security Officer - is responsible for the management of PKI Administrators as well as other PKI Officers and the configuration of the security policies governing the different certificates types issued by this CA.

 CA Administrator - is responsible for the management of the subscriber’s initialization process; the creation, renewal or revocation of certificates and the distribution of tokens (where applicable). PKI administrators can be seen as RA officers.

Procedures has been put in place to ensure that OA personnel associated with PKI roles (e.g. PKI Master User, PKI Officers, and PKI Administrators) are accountable for actions they perform and ensure evidence is available to link any action to the person performing such action.

1.3.4 Registration Authorities (RA)

There are RA organizations setup by that is operating the MoI subordinate CAs - one of which is this CA. The RA represent individuals and systems that are involved in validating the identity of individuals requesting certificates as well as in issuing and managing these certificates.

The below points describe the RAs of this CA:

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

(10)

OCSP certificates: The OA plays the RA role for MOI OCSP responder certificate lifecycle management.

1.3.5 Subscribers

IT systems, such as OCSP responder, Timestamping Authority, Web Servers and infrastructure devices such as VPNs, Routers, Switches and other devices.

Individuals with a formal mandate (authorization) request infrastructure certificates for devices and IT systems. They undergo a dedicated enrolment process through which they provide Certificate Signing Request (CSR) files to a designated MoI RA officer.

The PA is responsible for the subscriber agreement to specify the liabilities and warranties of this CA and the responsibilities and obligations of the individuals applying for infrastructure certificates.

1.3.6 Relying Parties

A Relying Party (RP) is an individual or server-based application (within the state of Qatar) that relies on digital certificates produced by this CA. These individuals or applications interact with applications running on target servers for which this CA issued certificates. An RP validates the digital certificates issued by this CA prior to trusting the applications running on the server.

1.3.7 Other Participants

There are no other participants for this CA.

1.4 Certificate Usage

1.4.1 Appropriate Certificate Use

There are four categories of certificates issued by this CA.They are:

 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

 Timestamping Authority (TSA) certificates - intended for the MOI TSA server  OCSP certificates - intended for MOI OCSP responder to sign OCSP tokens In accordance with its purpose of use, the certificate may be used without limitations in services provided by both public and private organizations.

(11)

1.4.2 Prohibited Certificate Use

Certificates referred to in this CPS 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 CPS should be directed to MoI PKI Policy Authority (PA)

Contact person: Capt. Ahmad Al-Hamar / Dr. Capt Jassim Al-Hamar Address (PO Box): P.O.Box : 6858, Duhail Area, Doha, Qatar Phone: +974-55558343

e-mail: [email protected]

1.5.3 Person Determining CPS Suitability for the Policy

MoI PA determines the suitability of this CPS according to the most up-to-date MoI CP.

1.5.4 CPS Approval Procedures

Approval of this CPS 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 CPS or an update notice. Updates shall supersede any designated or conflicting provisions of the referred version of the CPS.

1.6 Definitions and Acronyms

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.

(12)

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/ 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

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

(13)

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

OA - Operational Authority, the team within the 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) Referred 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

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/ digital signatures verified using that certificate

(14)

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 e-mail address 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

(15)

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

(16)

2 Publication and Repository Responsibility

2.1 Repositories

The MoI operates the repositories for the Subordinate CAs. The core repository is a Lightweight Directory Access Protocol (LDAP) directory server where CA certificates and Certificate Revocation Lists (CRLs) are published. The MoI also has replica of the core LDAP referred to as public LDAP that is published and made available to replying parties. Other than the public LDAP repository, the MoI maintains a PKI web portal where relevant PKI documentation is published for relying parties including MoI PKI CP and this CPS. The URL of this site is www.moi.gov.qa/PKI.

2.2 Publication of Certificate Information

The following certificate information is available on the MoI public LDAP  CA Certificates

 Certificates of the OCSP responder and TSA service  CRLs that contain a list of revoked certificates

This CA publishes both CRL Distribution Points and Uniform CRLs simultaneously.

2.3 Time or Frequency of Publication Repositories

2.3.1 Certificates

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

 CA certificates  OCSP certificates  TSA certificates

2.3.2 CRLs

The following rules apply for the CRLs issued in this CA  At minimum CRLs is refreshed every 24 hours

 The lifetime of CRLs is set to 26 hours (24 hours update period + 2 hours pre-update period)

(17)

2.4 Access Controls on Repositories

Public read-only access to the CP, CPS, certificates and CRLs published.

Access control is implemented on the MoI Public LDAP and PKI portal in order to prevent any unauthorized addition or modification of any published data.

(18)

3 Identification and Authentication

3.1 Naming

3.1.1 Types of Name

The certificates issued by this CA contain X.500 Distinguished Names (DN) in English. This CA is identified in the Issuer’s name field of the Subscriber certificates as shown in the below example:

CN=Infrastructure Certification Authority, O=QECC, C=QA Subscribers

 IT Systems and Infrastructure devices: The DN format is:

cn=<System unique common name>or<device DNS name> or <device IP address> CN = Infrastructure Certification Authority, O = QECC, C = QA

 MoI OCSP Responder: The DN format is:

CN = MOI OCSP, CN = Infrastructure Certification Authority, O = QECC, C = QA  MoI TSA: The DN format is:

CN =

MOI TSA

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

3.1.2 Meaningful names

 Names are meaningful since the CN contains the name of the IT system/ Infrastructure device

 For certificates issued for the MoI OCSP, names indicate the OCSP name (MoI OCSP)

 For certificates issued for MoI TSA service, names indicate the OCSP name (MoI TSA).

 Wild card characters may be included in issued certificates.

3.1.3 Anonymity and Pseudonymity of Subscribers

This CPS does not permit anonymous subscribers.

3.1.4 Rules for Interpreting Various Name Forms

No stipulation - this section intentionally left blank.

3.1.5 Uniqueness of Names

The usage of FQDN names, IP address or unique system common names agreed with MOI OA guarantees the uniqueness of DNs. Devices may have several Alias names which is supported by this CA.

(19)

The Subject Alternative Name extension can be used to populate one or more additional names for the same Server.

3.1.6 Recognition, authentication and role of Trademarks

No stipulation - this section intentionally left blank.

3.2 Initial Identity Validation

3.2.1 Method to Prove Possession of Private Key Meaningful Names

Certificate Signing Requests (CSR) generated by IT system/device contains a Proof-of-Possession (POP) of the private key as part of the PKCS#10 certificate requests submitted to this CA.

3.2.2 Authentication of Organization Identity

Organizations are not certified by this CA.

3.2.3 Authentication of individual identity

This CA issues certificates for IT Systems and Infrastructure devices across the state of Qatar. Applicants applies for these certificates at MoI main site in Doha where the RA team of this CA operates.

RA officers perform a verification of the identity of any applicant for a certificate. In order to establish the accuracy of the applicant identity, the following procedures are adopted

1. The subscriber completes a dedicated certificate application form which can be downloaded from the MoI PKI portal. This form includes data, such as the IT system/device unique name, certificate applicant, etc.

2. The Infrastructure certificate applicant liaises with the OA in order to apply for an infrastructure certificate for IT system/device. The OA identifies the Infrastructure device/IT system for which certificate(s) shall be requested from this CA. These device/IT system could be part of the IT infrastructure, a government or private organization in the state of Qatar.

3. The OA team verifies that the applicant is a legitimate sponsor or authorized device/system administrator of the Infrastructure device/IT system for which certificate(s) shall be requested.

4. The applicant signs the subscriber agreement, in addition to the certificate application form.

5. The OA validates the request by applying the applicant’s hand-written signature on the same form. The form is handed over to the certificate applicant.

6. The applicant submits the certificate application form to the RA officer who will validate the certificate request details before commencing the certificate issuance process.

(20)

3.2.4 Non-verified subscriber information

All subscriber information contained within certificate issued by the MoI CAs is verified by the MoI RA.

3.2.5 Validation of Authority

No stipulation since only a physical person may be certified.

3.2.6 Criteria for Interoperation

No stipulation.

3.3 Identification and Authentication for Re-keying requests

3.3.1 Identification and Authentication for Routine Re-Keying

Authentication for re-keying is performed as in initial registration.

3.3.2 Identification and Authentication for Re-Keying after revocation

Identification after revocation must be provided as in initial registration.

3.3.3 Identification and Authentication for Revocation Request

A revocation request may be submitted by a subscriber to this CA at any time. The subscriber validates to the MoI OA that he acts on behalf of the organization, being the business owner of the IT System/Infrastructure device to which the certificate was issued. A dedicated procedure has been setup by this CA for the revocation of Server certificates. This procedure is summarized as follows:

1. The subscriber completes a dedicated revocation form that he downloads from the MoI PKI portal. This form includes the unique name of the IT System/Infrastructure device, certificate serial number and revocation reason. The form is signed by the subscriber.

2. The subscriber liaises with the OA in order to apply certificate revocation. The OA identifies the Infrastructure device/IT system for which certificate(s) shall be revoked. 3. The OA team verifies that the subscriber is a legitimate sponsor or authorized device/system administrator of the Infrastructure device/IT system for which certificate(s) shall be revoked.

4. The applicant signs the subscriber agreement, in addition to revocation form that includes data such as the IT system/device unique name, certificate applicant, etc. The OA validates the request by applying the applicant’s hand-written signature on the same form. The form is handed over to the certificate applicant.

5. The applicant submits the revocation request form to the RA officer who will validate the request details before commencing the revocation process.

(21)

OCSP certificate revocation is conducted as part of a PKI process internal to the MoI and approved by the MoI PA. This process involves communications with relying parties in order to update them with the OCSP certificate revocation.

(22)

4 Certificate Life Cycle Management

4.1 Certificate Application

4.1.1 Who Can Submit a Certificate Application

A legitimate sponsor or authorized device/system administrator

4.1.2 Enrolment Process and Responsibilities

The certificate enrolment process is described below.

 The OA team receives a certificate application form. He then identifies the applicant as described in section 3.2.3.

 The OA team asks the subscriber to sign the Subscriber Agreement and the certificate application form.

 The applicant submits the certificate application form to the RA officer.

 The RA officer uses a dedicated RA application to enroll the IT system/device into this CA. The IT system/Device’s unique name is used to produce a unique distinguished name identifying the Server within this CA system. This process results in generating a unique secret codes that are delivered to the subscriber.

 The subscriber (or IT system/Device administrator) generates a key pair on the IT system/device. He then creates a CSR file using the received unique secret codes provided in the previous step.

 The CSR file is delivered to the RA officer who uses the RA application to upload and submit the CSR file to this CA. The certificate request is matched to the unique codes produced by this CA when the Server was enrolled. After the successful match, the certificate request is accepted and the certificate is issued and available for upload as a file to the RA officer.

Note: this step can also be conducted by the subscriber himself (or IT system/Device administrator) through the RA application exposed over the web, in this case the below step is omitted since the subscriber will be able to download the certificate directly once issued by the CA.

 The RA officer delivers the certificate to the subscriber. The certificate may be sent via email using the subscriber’s email address known to the RA officer.

4.2 Certificate Application Processing

4.2.1 Performing Identification and Authentication Functions

As stated in section 4.1.

4.2.2 Approval or Rejection of Certificate Applications

The RA officer follows rigorously the certificate enrolment process as described in section 4.1.2 of this CPS document. During this process, the RA officer who accepts the certificate application, shall then enroll the infrastructure device and issue related digital certificate.

(23)

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

4.2.3 Time to Process Certificate Applications

No stipulation.

4.3 Certificate Issuance

4.3.1 CA Actions during Certificate Issuance

Following the approval of the certificate application by the MoI OA, the CSR file is uploaded and submitted to this CA by the RA officer using a dedicated application.

The CA issues the requested certificates in accordance with the specified certificate template and by assigning unique serial numbers to each certificate. The certificate is valid and can be deployed on the target IT system/device.

 For IT system/device certificates: The CSR file is uploaded and submitted to this CA by the RA officer using a dedicated application. The CA then signs the certificate in accordance with the specified certificate template. The certificate is then downloaded by the IT system/device administrator or sent by the RA officer to the subscriber’s email address.

 For OCSP certificates: The OCSP administrator manually delivers the CSR file including the servers PEM or DER encoded public key to the CA administrator. The CA administrator submits the CSR file directly to the CA who will sign and publish an OCSP certificate suitable for verification. The certificate is returned to the OCSP administrator thereafter.

4.3.2 Notification to the Subscriber by the CA of Issuance of Certificate

The Subscriber is implicitly notified by this CAs RA officer when collecting his certificate.

4.4 Certificate Acceptance

4.4.1 Conduct Constituting Certificate Acceptance

The certificate acceptance is concluded when the certificate is installed on the target IT system/device.

4.4.2 Publication of the Certificate by the CA

CA Certificates, OCSP certificates and TSA certificates published by the CA will be published to the public repository (MoI public LDAP) asthey are issued.

(24)

4.5 Key Pair and Certificate Usage

4.5.1 Subscriber Private Key and Certificate Usage

When using a subscriber’s private key and corresponding certificate, a subscriber is obligated to

 Use certificates exclusively for legal activities and in accordance with the certificate usage defined in this CPS

 Comply with the terms of the subscriber agreement

 Not use the private key prior to the CA has issued, and the subscriber accepted, the corresponding certificate

 The subscriber shall discontinue the use of a private key following expiration or revocation of the corresponding certificate unless a subsequent expired or un-revoked certificate corresponding to that private key has been issued

4.5.2 Relying Party Public Key and Certificate Usage

When using a subscriber’s public key and corresponding certificate, a relying party is obligated to:

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

 Check the status of the certificate in accordance with the requirements stated in Section 4.9.6 of this CPS. As part of the validation process, the authenticity of the revocation must be validated as follows:

o In case of using CRLs, the digital signature of the CRLs is validated

o In case of using OCSP, the digital signature of the OCSP response is validated

 Reliance was reasonable and made in good faith in light of all the circumstances that were known or should have been known to the relying party at the time of reliance If a user of this PKI accepts a signed transmission that cannot be validated, the user does so completely at his own risk.

If a user of this PKI sends an encrypted message using a subscriber’s public key that key cannot be validated, the user does so completely at his own risk.

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, however there is a different (longer) validity period.

(25)

4.7 Certificate Re-key

Certificate Re-key is the act of re-issuing a certificate for an existing subscriber such that all the identifying information from the old certificate is duplicated in the new certificate,

however there is a different public key and a different validity period.

Certificate Re-key is supported by this CA. The re-key process (including identity validation, issuance) is done similarly to the initial certification.

4.7.1 Circumstance for Certificate Re-key

The IT system/ device administrator is responsible for renewing their certificates. Certificates need to be renewed prior to expiring, otherwise it will not be validated by relaying parties.

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.7.7 Notification of Certificate Issuance by the CA to Other Entities

4.8 Certificate Modification

Certificate modification is not permitted by this CA outside the context of certificate re-keying which results in the generation of a new certificate with the same identification information.

(26)

4.9 Certificate Revocation and Suspension

4.9.1 Circumstances for Revocation

An individual may request revocation of his certificate at any time and for any reason. An individual is required to request revocation of his certificate in case of

 The known compromise of the subscriber’s private key through the compromise of the physical target Server.

 The damage or loss of the subscriber’s private key (e.g. through the damage of the physical device on which the private key is installed).

 The information within the certificate has changed (such as a new certificate template by adding new X.509 extensions).

This CA revokes the certificate upon:

 Knowing that the information on the certificate is no longer accurate.

 Discovering that the certificate was issued in a manner not materially in accordance with the procedures required by the CPS.

 Determination that the certificate was issued to an entity other than the one named as the subject of the certificate.

 Finding that the certificate was issued without the authorization of the individual named as the subject of such certificate.

 The CA private Key has been compromised which implies that new keys and certificates need to be issued for all Servers that received certificates from this CA.  The Subscriber is known to have committed a serious breach of the Subscriber

agreement

On the other hand, this CPS does not provide provisions for revoking an OCSP/TSA certificate apart from the compromise of the OCSP/TSA key pair which shall be treated by MoI as per its Disaster Recovery and Business Continuity procedures. The following sub-sections focus only on the revocation provisions that apply for individual certificates.

4.9.2 Who Can Request Revocation

The permanent revocation of a Certificate can be requested by  The Subscriber himself.

 The MoI at its own discretion (if for instance a compromise is known for this CA key).

4.9.3 Procedure for Revocation Request

RA procedure for user certificate revocation as follows: 1) RA looks up DN in Entrust RA

(27)

3) Selects “Revoke this certificate” 4) Enter revocation reason and submit

5) The CA produces a new CRL which is published to its LDAP repository

4.9.4 Revocation Request Grace Period

There is no revocation grace period. Revocation requests are processed timely/immediately by this CAs.

4.9.5 Revocation Request Response Time

Refer to section 4.9.4.

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.

Certificates issued by this CA (except OCSP certificates) include the name of the LDAP distribution point and OCSP responder link from where a relying party could get revocation information. It is the relying party’s obligation to process certificates and to retrieve freshest revocation information.

4.9.7 CRL Issuance Frequency

CRLs are issued as per section 2.3 or this document.

4.9.8 Maximum Latency for CRLs

No stipulation – this section intentionally left blank.

4.9.9 Online Revocation/Status Checking Availability

OCSP is supported within this PKI solution and is 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 referred to 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

(28)

4.9.12 Special Requirements - Key Compromise

4.9.13 Circumstances for Suspension

Certificate suspension is not supported by this CA.

4.9.14 Who Can Request Suspension

Not applicable.

4.9.15 Procedure for Suspension Request

Not applicable.

4.10 Certificate Status Services

Refer to section 4.9.6 of this document. In addition, the following provisions are made.

4.10.1 Operational Characteristics

CRLs are published by this CA on a public repository which is available to relying parties. Apart from CRLs distributed at distribution points, the MoI also publishes combined (uniform) CRLs on its public repository (MoI Public LDAP).

MoI OCSP responder exposes 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

4.11 End of Subscription

No stipulation. See certificate revocation and suspension sections of this CPS.

4.12 Key Escrow and Recovery

(29)

5 FACILITY, MANAGEMENT and OPERATIONAL

CONTROLS

5.1 Physical Controls

5.1.1 Site Location and Construction

All critical components of the PKI system are housed within a highly secure enclave within the MoI premises. This PKI system’s location is protected by a physical and logical access control system.

5.1.2 Physical Access

Physical security controls include security guard controlled building access, man traps, biometric IRIS access and CCTV monitoring. These physical controls protect the hardware and software from unauthorized access and must be monitored on a 24*7*365 basis.

5.1.3 Power and Air Conditioning

The secure enclave must 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 must be installed such that it is not in danger of exposure to water.

5.1.5 Fire Prevention and Protection

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

5.1.6 Media Storage

Electronic optical and other media must be stored so as to protect it from accidental damage (water, fire, electromagnetic). Media that contains security audit archive and backup information must be stored in a secure fire-protected safe while within the enclave.

5.1.7 Waste Disposal

All obsolete paper magnetic media, optical media, etc. created within the enclave must be shredded before it is discarded. Reusable magnetic and optical media may be reused indefinably within the enclave.

(30)

5.1.8 Off-site Backup

System backup sufficient to recover from system failure is made daily. Backup copies should be rotated to a secure offsite location.

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

Facilities used for off-site backup and archives have the same level of security as the MoI main site.

5.2 Procedural Controls

All CA personnel are in the employment of or contracted to the MoI.

5.2.1 Trusted Roles

All CA operations are performed with this CA secure facility. Each user's system access is limited to those actions that they are required to perform in fulfilling their responsibilities. This CA’s responsibility has been divided for CA operations into three (3) distinct PKI personnel roles as follows:

 CA operators – responsible for day-to-day operations of the CA system  CA administrators – responsible for RA functions

 Security Officers – responsible for significant changes under strict controls

5.2.2 Number of Persons Required Per Task

No single person is able to perform a critical administrative function alone; technical controls are in place that requires two or more individuals to authorize sensitive tasks.

5.2.3 Identification and Authentication for Each Role

Before exercising the responsibilities of a trusted role:

 The MoI must have confirmed the identity of the employee by carrying out background-checks.

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

 The MoI must deliver necessary credentials that allow them to 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.

(31)

5.3 Personnel Controls

5.3.1 Qualifications, experience and Clearance Requirements

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

 Have satisfactorily completed an appropriate training program.  Have demonstrated the ability to perform their assigned duties.

 Not have any other duties that would conflict with their role in this PKI solution.  Have not been previously relieved of similar duties for negligence.

 Have not been denied a security clearance or had a clearance revoked.  Have 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

Individuals assigned to trusted roles are given the appropriate training to perform their job responsibilities competently and satisfactorily. The training must include operation of the PKI hardware and software, operational, security procedures and policies.

5.3.4 Retraining Frequency and Requirements

The OA provides 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 maintains 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.

5.3.6 Sanctions for Unauthorized Actions

Personnel performing unauthorized actions must be subject to disciplinary actions consistent with the existing MoI HR policy. 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.

(32)

5.3.7 Independent Contractor Requirements

Any contractor, including any subcontractor operating any part of this PKI, must 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 are provided with sufficient documentation to define their duties. They are also supplied with written procedures, technical manuals and other documents needed to perform their job responsibilities.

5.4 Audit Logging Procedures

5.4.1 Types of Event Recorded

All significant events occurring on the servers that support the PKI solution are recorded. All messages issued by the Entrust software, including the Entrust Enrolment Servers are recorded. All messages issued by all HSMs are recorded. Additional audit logs are kept for the intrusion detection system. The logs include, but are not limited to the following events:

 Operating System start-up and shutdown  CA application start-up and shutdown

 Attempts to create, remove, set passwords or change the system privileges of the privileged users (Trusted Roles)

 Changes to CA details/ keys

 Changes to certificate creation policies (e.g. validity period)  Login and logoff attempts, both successes and failures  Unauthorized attempts at network access to the CA system  Unauthorized attempts to access system files

 Generation of a CA’s own keys

 Successful and failed read and write operations on the repository  Failures during the generation of a certificate

 Certificate lifecycle management-related events (e.g., certificate applications, issuance, revocation and renewal)

 Cryptographic lifecycle management-related events (e.g., receipt, use, de-installation and retirement)

 Removing or replacing the cryptographic hardware security module in its assigned secure storage location

 Activation and deactivation of the cryptographic hardware module

 Cloning for disaster recovery or any other purposes, the private keys contained in the cryptographic hardware security module

 Generation of CRLs

(33)

 Hardware errors, equipment failures, power events, fire, smoke or water alarms Automated logs should be used whenever possible. Manual logs are an acceptable alternative.

5.4.2 Frequency of Processing Log

The following requirements apply for the OA staff in processing the generated logs:  Audit logs are reviewed regularly (once in a week at a minimum)

 Identified issues and irregularities shall be investigated and resolved

 Audit logs are periodically archived and purged from the CA system active system

5.4.3 Retention Period for Audit Log

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

5.4.4 Protection of Audit Log

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

5.4.5 Audit Log Backup Procedures

The following rules apply for the backup of this CA audit log:

 Backup media is stored locally in the MoI’s main site in a secure location.

 A second copy of the audit log data and files are stored outside the MoI’s main site in a site that provides physical and environmental security as described in this CPS 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 CA systems are subject to an annual assessment in line with the MoI system assurance policy and this CPS.

(34)

5.5 Records Archival

5.5.1 Types of Records Archived

This PKI archives records in accordance with the procedures described in this CPS as follows:

 Audit logs generated by the PKI CA software in accordance with Section 5.4  Certificate requests and revocation requests

 Records pertaining to identification and authentication information  Physical access logs

 CA personnel changes

 Discrepancy and compromise reports

 Information concerning the destruction of sensitive information  All Certificate Policies and Certification Practice Statements  Compliance Inspection Reports

 CA Certification and Accreditation Reports

 Current User’s Agreements and other information about the Subscriber or Designated Certificate Holder

 All work related communications to or from the OA, PA and auditors

5.5.2 Retention Period for Archive

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

5.5.3 Protection of Archive

The archive media is protected either by physical security or a combination of physical security and cryptographic protection. The OA maintains a list of people authorized to modify or delete the archive and makes the list available to the external auditor.

5.5.4 Archive Backup Procedures

Audit logs are backed up to tape after any change to the CA configuration, before the equipment is shutdown. An archive copy of the logs is maintained at an MoI offsite location under the same controls as for the primary backup.

5.5.5 Requirements for Time-stamping of Records

No stipulation.

5.5.6 Archive Collection System (internal or external)

No stipulation.

(35)

5.5.7 Procedures to Obtain and Verify Archive Information

Personnel accessing archive information will only do so with authorization letter approved by the PA and the OA director.

 An OA team member must sign for receipt of archive information

 Archive information carried between sites must be carried in a sealed container under lock and key

 Receiving personnel must verify that the archive is genuine and sign for receipt  An OA team member makes reasonable endeavor to keep the chain of evidence

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

In any cases of incident about the security of this CA system, the person who detects or suspects such incident should report it immediately to the IT Security Officer. It is the responsibility of the IT Security Officer to investigate, select personnel, either among the users of the system or externals, to perform an audit and take appropriate measures.

5.7.2 Computing Resources, Software/ Data Corruption

In the event of computing resources software/ data being corrupted, the PKI operations must be suspended. An investigation must be conducted by the OA to ascertain the cause and extent of the corruption and its impact on the integrity of the PKI.

The CAs will be restored from the last good backup before the corruption occurred. Affected subscribers will be notified of the corruption, and all certificates issued between the time of corruption and PKI service re-establishment will be revoked and re-issued.

5.7.3 Entity Private Key Compromise Procedures

In the event of the compromise of the CA private digital signature key and prior to its re-generation, this CA will immediately put the Disaster Recovery and Incident Handling procedure into action, which includes:

 Notifying the PA, the RA and OA so that they may activate their own incident handling processes

 Publishing a notice of Key Compromise

(36)

controls instigated before reestablishment of the CA

 Re-establishing this CA operations after approval from the PA

5.7.4 Business Continuity Capabilities after a Disaster

The OA must maintain a Disaster Recovery and Business Continuity Plan that is capable of resuming certificate issuance.

5.8 CA or RA Termination

In the event of this CA ceasing its operations, which is at the discretion of the PA, the MoI will arrange for the retention of the CAs records, including two copies of:

 Certificates

 Confidentiality private Keys  CRLs

 Audit information

In addition, the MoI must arrange for the retention of all CA data (hardware, software and access to passwords) required for ensuring that the MoI CA records are usable at a later stage if required by the PA.

(37)

6 TECHNICAL SECURITY CONTROLS

6.1 Key Pair Generation

6.1.1 CA Key Pair Generation

This CA key pairs are generated within a Safenet Luna SA cryptographic hardware device that is security evaluated to FIPS 140-1 Level 3 using the RSAwithSHA256 algorithm. CA key pair generation is performed by multiple pre-selected trusted individuals from the MoI using Trustworthy Systems and processes that provide for the security and required cryptographic strength for the generated keys.

This CA key pairs are generated in accordance with the requirements of the MoI’s reference key ceremony guide. The activities performed in each key generation ceremony are recorded, dated and signed by all individuals involved.

These records are kept for audit and tracking purposes for a duration of time deemed appropriate by the PA.

6.1.2 Subscriber Key Pair Generation

The Subscriber’s Keys are generated on the target IT system/Device using a corresponding key management utility.

6.1.3 Private Key Delivery to Subscriber

This CA does not generate Subscriber’s (IT system/Device) Private keys.

6.1.4 Public Key Delivery to Certificate Issuer

The public key is delivered to this CA as part of a Certificate Signing Request (CSR) file, which is a signed file, produced by the IT system/Device key management utility. The CSR file is delivered to this CA in either one of the below ways:

 The IT system/Device administrator uploads the CSR file using a dedicated published RA application. The CA then verifies the CSR file against unique secret codes that were generated at the beginning of certificate enrollment.

 The subscriber delivers the CSR to the RA officer.

6.1.5 CA Public Key Delivery to Relying Parties

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

(38)

6.1.6 Key Sizes

This CA key pair is 4096 bit RSA. Subscriber is 2048 bit RSA.

6.1.7 Public Key Parameters Generation and Quality Checking

The MoI Subordinate CAs rely on an off-the-shelf implementation of PKI functionality, including public key parameters generations. In addition, the CA keys are generated by the key generation function of the HSM using FIPS 140-1 compliant hardware random number generator.

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

The Certificate will always contain a KeyUsage bit string in accordance with RFC 5280. 6.1.8.1 Infrastructure CA

CA Signing

CA signing Keys are the only Keys permitted to be used for signing Certificates and CRLs. The Certificate KeyUsage field must be set to :

Key usage:: Bitstring { KeyCertSign (5) cRLSing (6) }

Table 1: This CA Key usage 6.1.8.2 Subscribers

SSL Certificate Infrastructure signing certificates

The Certificate KeyUsage field will be set to: Key usage:: Bitstring {Digital signature, Data Encipherment, Key Encipherment}

The Certificate KeyUsage field will be set to: Key usage:: Bitstring {Digital signature, non-repudiation }

Table 2: Subscriber’s Key usage

6.2 Private Key Protection and Cryptographic Module Engineering

Controls

6.2.1 Cryptographic Module Standards and Controls

The CA generates its key pairs and store their private key within an HSM that is certified according to the rating specified in section 6.2.11.

Subscribers’ private keys are not generated by this CA. This CA only generates digital certificates for its subscriber’s Servers.

(39)

6.2.2 Private Key Multi-Role Control

The OA must implement technical and procedural mechanisms that require the participation of multiple trusted individuals authorized to perform sensitive CA cryptographic operations.

6.2.3 Private Key Escrow

Key escrow is not supported by this CA

6.2.4 Private Key Backup

This CA’s private key is backed on hardware tokens that meet the same level of security as this CA’s HSM. This CA’s key ceremony document specifies the number of backup tokens and procedures around the actual backup.

6.2.5 Private Key Archival

No stipulation.

6.2.6 Private Key Transfer Into or From a HSM

The CA’s private key backup is maintained within the HSM (token-to-token cloning) and at no time, does the private key get copied to disk.

6.2.7 Private Key Storage on Cryptographic Module

No further stipulation other than those stated in 6.2.1.

6.2.8 Method of Activating Private Key

This CA private key is activated under multi-person controls. A PIN entry device attached to the HSM on a separate cable and personnel are required to insert physical keys and PINS to perform sensitive operations. PIN numbers and PIN entry device keys are controlled such that the operation of the CA is not compromised by a single operator.

The actual activation procedure has been documented by the MoI as part of the overall key ceremony procedure

Subscriber’s private keys are not generated by this CA.

6.2.9 Method of Deactivating Private Key

This CA’s private Key is deactivated in the following situations:  The CA software is shut down.

 The CA HSM is manually stopped 

(40)

 The CA HSM is operated outside the range of supported temperatures

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

When private keys are deactivated, they are cleared from memory before the memory is de-allocated.

6.2.10 Method of Destroying Private Key

The MoI relies on HSMs to initialize commands as much as possible for the destruction of CA keys.

Physical destruction of hardware is not required.

6.2.11 Cryptographic Module Rating

The CA must 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 CPS.

6.3.2 Certificate Operational Periods and Key Pair Usage Periods

 The maximum operational period of the CA’s key pair must be set for eight (8) years.

 The maximum operational period for a subscriber’s key pair must be three (3) years.

Key Certificate type Maximum Validity Period

Certification Authority Certificate and associated keys

Recommended 96 months, re-key at 62% lifetime i.e., 60 months Subscribers Certificates and associated

keys

Maximum operational period for a subscriber’s key pair must be three years i.e., 36 months.

6.4 Activation Data

6.4.1 Activation Data Generation and Installation

Activation data is generated by the PKI software and is evaluated in a truly random manner. This data is used to verify the authenticity of certificates generated and signed by this CA before it is installed and activated.