Qatar Ministry of Interior - Public Key Infrastructure Infrastructure CA Certification Practice Statement Issue : 1.2 Issue date : 19 October 2014 Status : Approved page 1 of 51
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 2 of 51
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.6 Certificate Renewal... 24 page 3 of 51
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 6.8 Time-Stamping... 42 page 4 of 51
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 9.17 Other provisions... 51 page 5 of 51
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. page 6 of 51
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 Infrastructure CA Identity signing certs Identity encryption certs OCSP certs Corporate signing certs Corporate encryption certs OCSP certs Web certs VPN 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 to relying parties. This should be based upon certificate suspension/revocation lists. page 7 of 51
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: page 8 of 51
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. page 9 of 51
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. page 10 of 51
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: PA@moi.gov.qa 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. page 11 of 51
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 MoI-IO - Ministry of Interior s Immigration Offices page 12 of 51
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 page 13 of 51
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] [RFC5280] Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework Internet X.509 Public Key Infrastructure Certificate and Certificate page 14 of 51
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 15 of 51
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 preupdate period) page 16 of 51
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. page 17 of 51
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. page 18 of 51
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. page 19 of 51
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. page 20 of 51
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. page 21 of 51
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. page 22 of 51
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) as they are issued. 4.4.3 Notification of Certificate Issuance by the CA to Other Entities No stipulation - this section intentionally left blank page 23 of 51
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 un-expired or unrevoked 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. Certificate Renewal is not be supported by this CA. Only certificate re-key is supported. page 24 of 51
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 As per initial certification 4.7.4 Notification of New Certificate Issuance to Subscriber As per initial certification 4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate As per initial certification 4.7.6 Publication of the Re-keyed Certificate by the CA As per initial certification 4.7.7 Notification of Certificate Issuance by the CA to Other Entities As per initial certification 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. page 25 of 51
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 subsections 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 2) Selects the desired certificate page 26 of 51
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 No stipulation this section intentionally left blank. page 27 of 51
4.9.12 Special Requirements - Key Compromise No stipulation this section intentionally left blank. 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 No stipulation this section intentionally left blank. 4.11 End of Subscription No stipulation. See certificate revocation and suspension sections of this CPS. 4.12 Key Escrow and Recovery Key escrow and recovery are not used by this CA. page 28 of 51
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. page 29 of 51
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. page 30 of 51
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. page 31 of 51
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 Physical access to the enclave page 32 of 51
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. page 33 of 51
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. page 34 of 51
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 regeneration, 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 Revoking all active certificates issued by the CA A full analysis of the circumstances that led to the compromise and correctional page 35 of 51
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. page 36 of 51
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). page 37 of 51
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 The Certificate KeyUsage field will be set to: Infrastructure signing certificates The Certificate KeyUsage field will be set to: Key usage:: Bitstring {Digital signature, Data Encipherment, Key Encipherment} Table 2: Key usage:: Bitstring {Digital signature, nonrepudiation } 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. page 38 of 51
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 There is a power failure within the CA room page 39 of 51
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 deallocated. 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 Certification Authority Certificate and associated keys Subscribers Certificates and associated keys Maximum Validity Period Recommended 96 months, re-key at 62% lifetime i.e., 60 months 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. page 40 of 51
6.4.2 Activation Data Protection Activation data is generated by this CA for every certificate enrollment. 6.4.3 Other Aspects of Activation Data No stipulation - this section intentionally left blank. 6.5 Computer Security Controls The OA follows State Audit Bureau requirements for computer security and audit requirements. 6.5.1 Specific Computer Security Technical Requirements The CA server includes the following security functionality: Access control to CA services and PKI roles Enforced separation of duties for PKI roles Identification and authentication of PKI roles and associated identities Archival of this CA and administrator creation/revocation history Audit of security related events Automatic and regular validation of CA database integrity Recovery mechanisms for Keys, the CA database, the CA application and operating system A hardened CA operating system Network protection, including host intrusion detection system 6.5.2 Computer Security Rating This CA is installed on a Red hat Linux 6.2 Server with any non-required services removed or disabled. All required OS resources are configured and patched in accordance with Red hat guidelines for achieving the common criteria assurance. 6.6 Life Cycle Technical Controls 6.6.1 System Development Controls This CA is installed as a commercial product from Entrust Inc. and is subject to regular patches and service packs received from the company. 6.6.2 Security Management Controls This CA s system is dedicated and tightly controlled with respect to access to it. page 41 of 51
The CA database performs automatic integrity check daily and upon power-up The operating system and CA application version is updated in accordance with vendor software update processes Antivirus is installed on the CA system. 6.6.3 Life Cycle Security Controls No stipulation - this section intentionally left blank. 6.7 Network Security Controls This CA is located within the MoI s most secured network area. This area is protected by Firewalls and Intrusion Prevention Systems. 6.8 Time-Stamping The CAs servers internal clock is synchronized using Network Time Protocol. page 42 of 51
7 CERTIFICATE, CRL PROFILES 7.1 Certificate Profile 7.1.1 Version Number This CA issues X.509 version 3 certificates as defined in RFC 5280. 7.1.2 Certificate Extensions OCSP response signing certificates require the use of the following extensions: KeyUsage (not critical) AuthorityKeyId (not critical) Extended KeyUsage (critical) OCSPNoCheck (not critical) TSA certificates require the use of the following extensions: KeyUsage (not critical) AuthorityKeyId (not critical) Extended KeyUsage (critical) CDP(not critical) SSL certificates extensions as per the norm. 7.1.3 Algorithm Object Identifiers X.509v3 standard OIDs is used. Algorithm must be RSAencryption for the subjectkey and SHA256withRSA encryption for the certificate signature 7.1.4 Name Forms As per the naming conventions and constraints listed in section 3.1 of this CPS 7.1.5 Name Constraints As per the naming conventions and constraints listed in section 3.1 of this CPS 7.1.6 Certificate Policy Object Identifier Policy Identifier for certificates issued by this CA is 2.16.634.1.1.2.1.1. 7.1.7 Usage of Policy Constraints Extension No stipulation. page 43 of 51
7.1.8 Policy Qualifiers Syntax and Semantics No stipulation. 7.1.9 Processing Semantics for Critical Certificate Extensions Critical extensions, when marked, is interpreted by relying parties accordingly 7.1.10 OCSP Response Signing Certificate ASN1 Description The following rules are applied to the OCSP certificate 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 extended Key Usage extension. The certificate will include the extension id-pkix-ocsp-nocheck as a none-critical extension, which indicates that an OCSP relaying 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. 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 {CN=Infrastructure Certification Authority, O=QECC, C=QA} Validity UTC-Time NotBefore: <<creation date>> NotAfter: <<creation date +3 Years>> Subject UTF8 { CN=MOI OCSP, CN=Infrastructure Certification Authority, O=QECC, C=QA} SubjectPublicKeyInfo Sequence AlgorithmIdentifier OID RSAencryption (Parameter = NULL) SubjectPublicKey BitString Public key (256 bytes) + exp. pub. Extensions Sequence AuthorityKeyId OctString <<SHA1 of subjectpublickey of Issuer (Infrastructure CA certificate>> Critical Boolean False KeyUsage BitString C0 : digital signature and non-repudiation Critical Boolean False ExtendedKeyUsage OctString OCSP Signing (1.3.6.1.5.5.7.3.9) Critical Boolean True OCSPNoCheck OctString NULL Critical Boolean False page 44 of 51
SignatureAlgorithm OID Sha-256WithRSAencryption SignatureValue BitString <<signed using the infrastructure private key>> (512 octets) 7.1.11 TSA Signing Certificate Profile This is the complete ASN1 description of the certificate associated to TSA signing private keys. 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 { CN=Infrastructure Certification Authority, O=QECC, C=QA } Validity UTC-Time NotBefore: <<creation date>> NotAfter: <<creation date +3 Years>> Subject UTF8 << CN=MOI TSA, CN=Infrastructure Certification Authority DEV, O=QECC, C=QA >> SubjectPublicKeyInfo Sequence AlgorithmIdentifier OID RSAencryption (Parameter = NULL) SubjectPublicKey BitString Public key (256 bytes) + exp. pub. Extensions Sequence AuthorityKeyId OctString <<SHA1 of subjectpublickey of the Issuer CA (Infrastructure CA)>> Critical Boolean False KeyUsage BitString C0 : digital signature and non-repudiation Critical Boolean False ExtendedKeyUsage OctString Time Stamping (1.3.6.1.5.5.7.3.8) Critical Boolean True CDP Sequence distributionpoint DistributionPoi ntname fullname GeneralNames IA5String LDAP URI where the Partitioned CRL is hosted Name Partitioned CRL directory address Critical Boolean False SignatureAlgorithm OID Sha-256WithRSAencryption SignatureValue BitString <<signed using the infrastructure private key>> (512 octets) page 45 of 51
7.1.12 SSL Certificate Profile The standard SSL certificate profile is used. 7.1.13 VPN Certificate Profile The standard VPN certificate profile is 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. 7.2.2 CRL and CRL Entry Extensions The CRL extensions contain the CRLNumber (a sequential number incremented with each new CRL produced). 7.2.3 CRL ASN1 Description Object Format Certificate Content CertificateList Sequence TbsCertList Sequence Version Integer 1 (Version 2) Signature OID Sha-256WithRSAencryption Issuer UTF8 { 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 Critical Boolean False crlextensions Sequence crlnumber Integer Sequential CRL number Critical Boolean False AuthorityKeyId OctString <<SHA1 of subjectpublickey of the Issuer >> Critical Boolean False SignatureAlgorithm OID Sha-256WithRSAencryption SignatureValue BitString <<signed using the PCA private key>> (512 page 46 of 51
octets) page 47 of 51
8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS The MoI follows the Qatar National Auditing framework. An auditor approved by the national PMA was appointed to audit this CA operations against the policy and procedures of this CPS and related CP and establish compliance to [ETSI 319 411-3]. page 48 of 51
9 OTHER BUSINESS AND LEGAL MATTERS 9.1 Fees 9.1.1 Certificate issuance or renewal fees Fees details will be provided at the time of certificate issuance. 9.1.2 Certificate access fees No fees associated with access to revocation and status information. 9.1.3 Revocation or status information access fees No fees associated with access to revocation and status information. 9.1.4 Fees for other services No stipulation - this section intentionally left blank. 9.1.5 Refund policy PKI fees are not refundable. 9.2 Financial responsibility No stipulation - this section intentionally left blank. 9.3 Confidentiality of business information The MoI keeps the confidentiality of all subscribers information used within the PKI except for those included in Certificates. 9.3.1 Scope of confidential information All the information that is not explicitly mentioned under section 2.2 is deemed as Confidential/Private Information. 9.3.2 Information not within the scope of confidential information All the information that is not explicitly mentioned under section 2.2 is deemed as Confidential/Private Information. 9.3.3 Responsibility to protect confidential information All parties implicated in this PKI are expected to take the necessary measures to protect confidential information. Business Associate Agreements (Ex. Subscriber agreement) further define responsibilities for protecting confidential information. 9.4 Privacy of personal information page 49 of 51
No stipulation - this section intentionally left blank. 9.5 Intellectual property rights No stipulation - this section intentionally left blank. 9.6 Representations and warranties No stipulation - this section intentionally left blank. 9.7 Disclaimers of warranties Nothing contained in this CPS shall be deemed to constitute either this CA, or any of its subcontractors, agents, officers, suppliers, employees, partners, principals, or directors to be a partner, Affiliate, trustee, of any Relying Party or any third party, or to create any fiduciary relationship between this CA and any Relying party, or any third party, for any purpose whatsoever. Nothing in this CPS or any Agreement between a third party and a Relying Party shall confer on any Subscriber, Customer, Relying Party, Registration Authority, Applicant or any third party, any authority to act for, bind, or create or assume any obligation or responsibility, or make any representation on behalf of this CA. 9.8 Limitations of Liability The CA does 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 The MoI has no liability for the improper use of Certificates. The Subscribers are liable for any misrepresentations they may make in any Certificate application or to any third party. The Subscribers and Relying parties shall indemnify the MoI from and against any loss, damage or liability resulting from any breach of this policy or improper use of Certificates and Certificate Revocation List (CRL). 9.10 Term and termination No stipulation - this section intentionally left blank. 9.11 Individual notices and communications with participants No stipulation - this section intentionally left blank. 9.12 Amendments No stipulation - this section intentionally left blank. page 50 of 51
9.13 Dispute resolution provisions No stipulation - this section intentionally left blank. 9.14 Governing Law The CA shall operate within the state of Qatar legal jurisdiction. 9.15 Compliance with applicable law No stipulation - this section intentionally left blank. 9.16 Miscellaneous provisions 9.16.1 Entire agreement No stipulation - this section intentionally left blank. 9.16.2 Assignment No stipulation - this section intentionally left blank. 9.16.3 Severability Should it be determined that one section of this CPS is incorrect or invalid. The other sections of this CPS shall remain in effect until the CPS is updated. The process for updating this CPS is described in section 1.5. 9.16.4 Enforcement (attorneys' fees and waiver of rights) No stipulation - this section intentionally left blank. 9.16.5 Force Majeure No stipulation - this section intentionally left blank. 9.17 Other provisions No stipulation - this section intentionally left blank. page 51 of 51