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

Transcription

1 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

2 Amendment history Date Issue Status Changes Author 27/08/ Approved Issue final version MoI Policy Authority 28/09/ Approved Adding Final OID values and hosting URLs MoI Policy Authority 19/10/ Approved Updating OID values MoI Policy Authority page 2 of 51

3 Detailed contents 1 Introduction Overview Document name and Identification PKI Participants Certificate Usage Policy Administration Definitions and Acronyms Publication and Repository Responsibility Repositories Publication of Certificate Information Time or Frequency of Publication Repositories Access Controls on Repositories Identification and Authentication Naming Initial Identity Validation Identification and Authentication for Re-keying requests Certificate Life Cycle Management Certificate Application Certificate Application Processing Certificate Issuance Certificate Acceptance Key Pair and Certificate Usage Certificate Renewal page 3 of 51

4 4.7 Certificate Re-key Certificate Modification Certificate Revocation and Suspension Certificate Status Services End of Subscription Key Escrow and Recovery FACILITY, MANAGEMENT and OPERATIONAL CONTROLS Physical Controls Procedural Controls Personnel Controls Audit Logging Procedures Records Archival Key Changeover Compromise and Disaster Recovery CA or RA Termination TECHNICAL SECURITY CONTROLS Key Pair Generation Private Key Protection and Cryptographic Module Engineering Controls Other Aspects of Key Pair Management Activation Data Computer Security Controls Life Cycle Technical Controls Network Security Controls Time-Stamping page 4 of 51

5 7 CERTIFICATE, CRL PROFILES Certificate Profile CRL Profile COMPLIANCE AUDIT AND OTHER ASSESSMENTS OTHER BUSINESS AND LEGAL MATTERS Fees Financial responsibility Confidentiality of business information Privacy of personal information Intellectual property rights Representations and warranties Disclaimers of warranties Limitations of Liability Indemnities Term and termination Individual notices and communications with participants Amendments Dispute resolution provisions Governing Law Compliance with applicable law Miscellaneous provisions Other provisions page 5 of 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. page 6 of 51

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 Infrastructure CA Identity signing certs Identity encryption certs OCSP certs Corporate signing certs Corporate encryption certs OCSP certs Web certs VPN certs OCSP certs 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

8 The status information must always reflect the current status of the certificates issued by this CA. 1.2 Document name and Identification 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 Identification Alphanumeric OID The Object Identifier of this CPS is OID is 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 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 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

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

10 OCSP certificates: The OA plays the RA role for MOI OCSP responder certificate lifecycle management 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 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 Other Participants There are no other participants for this CA. 1.4 Certificate Usage 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

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 of this policy document. Using certificates for other purposes is explicitly prohibited. 1.5 Policy Administration Organization Administering the Document This document shall be administered by the MoI PA 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: PA@moi.gov.qa Person Determining CPS Suitability for the Policy MoI PA determines the suitability of this CPS according to the most up-to-date MoI CP 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

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 MoI-IO - Ministry of Interior s Immigration Offices page 12 of 51

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 page 13 of 51

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

15 Revocation List (CRL) Profile [ETSI ] ETSI EN V1.1.1 ( ) 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 ] ETSI TS V2.2.1 ( ) Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates page 15 of 51

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 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 Certificates The below Certificates are published to the public repository (MoI Public LDAP) once they are issued CA certificates OCSP certificates TSA certificates 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

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. page 17 of 51

18 3 Identification and Authentication 3.1 Naming 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 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 Anonymity and Pseudonymity of Subscribers This CPS does not permit anonymous subscribers Rules for Interpreting Various Name Forms No stipulation - this section intentionally left blank 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

19 The Subject Alternative Name extension can be used to populate one or more additional names for the same Server Recognition, authentication and role of Trademarks No stipulation - this section intentionally left blank. 3.2 Initial Identity Validation 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 Authentication of Organization Identity Organizations are not certified by this CA 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

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 Validation of Authority No stipulation since only a physical person may be certified Criteria for Interoperation No stipulation. 3.3 Identification and Authentication for Re-keying requests Identification and Authentication for Routine Re-Keying Authentication for re-keying is performed as in initial registration Identification and Authentication for Re-Keying after revocation Identification after revocation must be provided as in initial registration 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

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. page 21 of 51

22 4 Certificate Life Cycle Management 4.1 Certificate Application Who Can Submit a Certificate Application A legitimate sponsor or authorized device/system administrator 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 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 using the subscriber s address known to the RA officer. 4.2 Certificate Application Processing Performing Identification and Authentication Functions As stated in section Approval or Rejection of Certificate Applications The RA officer follows rigorously the certificate enrolment process as described in section 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

23 OCSP and TSA certifications are conducted as part of the MoI s internal processes and shall be approved by the MoI PA Time to Process Certificate Applications No stipulation. 4.3 Certificate Issuance 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 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 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 Conduct Constituting Certificate Acceptance The certificate acceptance is concluded when the certificate is installed on the target IT system/device 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 Notification of Certificate Issuance by the CA to Other Entities No stipulation - this section intentionally left blank page 23 of 51

24 4.5 Key Pair and Certificate Usage 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 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 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

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 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 Who May Request Certification of a New Public Key As per initial certification Processing Certificate Re-keying Requests As per initial certification Notification of New Certificate Issuance to Subscriber As per initial certification Conduct Constituting Acceptance of a Re-keyed Certificate As per initial certification Publication of the Re-keyed Certificate by the CA As per initial certification 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

26 4.9 Certificate Revocation and Suspension 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 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) 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

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 Revocation Request Grace Period There is no revocation grace period. Revocation requests are processed timely/immediately by this CAs Revocation Request Response Time Refer to section 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 CRL Issuance Frequency CRLs are issued as per section 2.3 or this document Maximum Latency for CRLs No stipulation this section intentionally left blank Online Revocation/Status Checking Availability OCSP is supported within this PKI solution and is compliant with RFC 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 Online Revocation Checking Requirements It is at the discretion of the relying party to decide whether using CRL or relying on OCSP Other Forms of Revocation Advertisements Available No stipulation this section intentionally left blank. page 27 of 51

28 Special Requirements - Key Compromise No stipulation this section intentionally left blank Circumstances for Suspension Certificate suspension is not supported by this CA Who Can Request Suspension Not applicable Procedure for Suspension Request Not applicable Certificate Status Services Refer to section of this document. In addition, the following provisions are made 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 Service Availability The repository including the latest CRL should be available 24X7 for at least 99% of the time Optional Features No stipulation this section intentionally left blank End of Subscription No stipulation. See certificate revocation and suspension sections of this CPS Key Escrow and Recovery Key escrow and recovery are not used by this CA. page 28 of 51

29 5 FACILITY, MANAGEMENT and OPERATIONAL CONTROLS 5.1 Physical Controls 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 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 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 Water Exposures The PKI solution must be installed such that it is not in danger of exposure to water 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 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 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

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

31 5.3 Personnel Controls 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 Background Check Procedures Background checks are performed by the Qatar State Secret Service and are not disclosed in this document 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 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 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 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

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

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 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 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 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 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 Audit Collection System (internal vs. external) No stipulation 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 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